Why aren't more of my controllers failing due to skip_forgery_protection not being used?

Question

I'm upgrading a rails app from 5.2 to 6.1. Previous I was using 5.1 defaults, now I'm up to 6.1 defaults.

In rails 5.2, forgery protection became a default. So, when I went all the way up to 6.1 a few things started breaking.

I added skip_forgery_protection to my graphql controller and that fixed all my failing tests. No tests accessing other controllers (which are definitely not implementing the forgery system in the frontend) failed, nor did other things I tried manually.

One theory I had is forgery_protection only applies to POST, PUT, PATCH, and DELETE, but I found zero discussion or mention of this online and it doesn't seem to be what I'm observing (although I admit I haven't been thorough about testing that theory yet).

Everything inherits from the same ApplicationController

What could be going on?

Answer 1

I'm not sure I understand your question correctly.

But, if you are asking why forgery_protection only applies to POST, PUT, PATCH, and DELETE then the doc says,

Turn on request forgery protection. Bear in mind that GET and HEAD requests are not checked.

And from wikipedia,

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Because of this assumption, many existing CSRF prevention mechanisms in web frameworks will not cover GET requests, but rather apply the protection only to HTTP methods that are intended to be state-changing.