This is a cross-posting from my blog
TL;DR
The browser enforces the Same-origin policy to avoid getting responses from websites that d...
For further actions, you may consider blocking this person and/or reporting abuse
In the "Allowing multiple origins" example,
Vary: Origin
should be set in the response to avoid incorrect content being served (if content may differ depending on the requesting origin). See fetch.spec.whatwg.org/#cors-protoc...Good point, thanks for your input! Added it to the example in that section :)
Do we need
CSRF
protection ifCORS
is disabled (now allowed from other domains) ?For me it seems logic that is no need for
CSRF
protection ifCORS
is disabled, but couldn't find any exact answer.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?
You should protect against CSRF on any inputs that can change state imo.
CSRF
isCross-site request forgery
CORS
isCross-origin resource sharing
If 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.
Thanks for writing this. Bookmarked.