Several of my Spring Security based projects expose a RESTful API that support the full range of HTTP verbs: GET, POST, PUT, PATCH, DELETE, etc. For those projects only using GET and POST, everything works as expected. When using PUT, however, I encounter CSRF protection issues that usually lead me to disable CSRF protection.
My primary question is, "Why does Spring Security treat PUT and POST differently?"
My secondary question is, "Is disabling CSRF protection a real issue given that my projects are truly stateless, use no cookies and require a valid OAuth2 bearer token?"
I also have a secondary level of protection verifying that the bearer of the OAuth2 token is authorized to perform the requested action.
I suspect that PATCH and DELETE would encounter the same issue with CSRF protections in Spring Security but have not developed test-cases to validate my suspicions. We usually develop the PUT use-case before developing the others.
FWIW, this issue appears in Spring Security 4 and 5. I have some of both in my projects.