Secure against CSRF by accident

Question

I have an interesting application for secure testing.

The POST endpoint is accepting only content-type application/json, any other content results in an 500 error. The application lacks a CSRF token or other techniques against CSRF.

The 'trick' with text/plain and additional equal sign didn't work, still 500.

The Access-Control-Allow-Origin header is wildcard *, not dynamically generated, and an Access-Control-Allow-Credentials header is not present - so no option for XHR call.

Does that mean, that somehow, they managed to be secure against CSRF?

Answer 1

Without talking to the developers I can't say for sure whether it was an accident or not, but "all state-changing actions require application/json, no exceptions, and we don't have a completely broken CORS configuration" is a perfectly valid approach to CSRF protection. You can also get the same effect by requiring literally any custom header - it can be the fixed string X-CSRF: no if you want - as that will also trigger a CORS preflight before the browser will send the real request.

Checking the Origin header alone is not sufficient to mitigate CSRF; some browsers send it on all cross-origin requests but some don't (if the request was made by submitting an HTML form, or otherwise not a CORS request). However, checking for things that can only be sent via CORS (custom headers, content types not allowed in HTML forms, etc.) and then checking the Origin header (or just disallowing CORS preflights in general) works fine.