Do we need CSRF protection if CORS is disabled (now allowed from other domains) ?
For me it seems logic that is no need for CSRF protection if CORS is disabled, but couldn't find any exact answer.
From humble beginnings at an MSP, I've adventured through life as a sysadmin, into an engineer, and finally landed as a developer focused on fixing problems with automation.
From humble beginnings at an MSP, I've adventured through life as a sysadmin, into an engineer, and finally landed as a developer focused on fixing problems with automation.
Note that without CORS headers the request is still happening, you just don't have access to the response. Unless you have some server-side mechanism to detect requests from other origins, you could still run the risk of CSRF. I'm with @theincorrigible1
that you should protect against CSRF on any inputs that can change state.
Here's a potential example:
Say your router is at 192.168.0.1 and there's a form to change the admin password with a POST request, e.g. POST to 192.168.0.1/settings with a body like "password=abc123".
If some website now makes such a request, it won't see the response from the router (that's what CORS prevents), but the request would happen and possibly change your router password..
Do we need
CSRFprotection ifCORSis disabled (now allowed from other domains) ?For me it seems logic that is no need for
CSRFprotection ifCORSis disabled, but couldn't find any exact answer.You should protect against CSRF on any inputs that can change state imo.
CSRFisCross-site request forgeryCORSisCross-origin resource sharingIf no one from another origin is able to make requests to your site (CORS disabled),
then CSRF is redundant imo.
But that's not what CORS does. Re-read the warning in the article.
Note that without CORS headers the request is still happening, you just don't have access to the response. Unless you have some server-side mechanism to detect requests from other origins, you could still run the risk of CSRF. I'm with @theincorrigible1 that you should protect against CSRF on any inputs that can change state.
Here's a potential example:
Now I get it.
But can the attacker make a simple request, and get a CSRF token,
then make second request with that token included?