DEV Community

Understanding CORS

Martin Splitt on November 12, 2019

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...

Read full post

Robert Linder • Nov 12 '19

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...

Martin Splitt • Nov 13 '19

Good point, thanks for your input! Added it to the example in that section :)

Andrei Luca • Nov 19 '19 • Edited

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.

Martin Splitt • Nov 21 '19

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..