Make it harder to have routes vulnerable to CSRF

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Requiring the flag to be set could work, we'd need to deprecate not having it set first, and probably require it in Drupal 13 because there are a lot more routes out there than entity queries.

I added a runtime deprecation and a test.
But now of course a lot of tests trigger the deprecation.

This does feel a bit heavy handed because the vast majority of GET requests do not require this as far as I can tell, so we're making a lot of busy work.

Can we detect writes to config or content entities via events or hooks, and if they were triggered by an HTTP GET request, ensure that it was protected via CSRF? If there is a case where this can happen where CSRF is not required, maybe we can just ensure the route has the CSRF check flag specified, even if it's set to false?

I think it would be hard to detect which routes need to be protected against CSRF.
POST requests can also be vulnerable (but only when cookies use SameSite=None which is not recommended).
And modifying config or content are not the only actions that need to be protected, for example a route that triggers an external API call could also be vulnerable.

We can probably identify a few more patterns that we can exclude other than just form, such as entity view and so on.

Looking at the test fails, most have a few but many are repeating very often. If we fix a few of, e.g. system, user and entity routes them then we might get a better picture of how big the impact really is.

Considering recent contrib security issues, I think it's worth exploring this bit. I think the entity query access change was at least as impactful. this is mostly about a single file per module and easier to identify than those entity queries.