I have one doubt, if the request origin header is is not matching to Allow-Origin-Request-Header value , why it is giving 200 ok as an respose. It shall give 401 if the both side thing is not matching .
Request origin: Evil.com
Response header :
200 ok
Allow-origin-access-control: legitimate .com
Because CORS is handled by the browser. The server will never block any requests because of CORS. It's not its responsibility.
The server will always answer with a 200, but add some headers telling the browser "you're only allowed to accept this if the request was done from this domain", and the browser will block the request (and add a lovely warning in the console) if it doesn't match.
Once again, CORS is not meant to prevent malicious user agents from accessing a resource, it's only meant to prevent trusted user agents (browsers) from being tricked into impersonating the user by malicious websites. This means that asking the server to do the check and respond with a 403 would not be more effective, and since you can't expect every backend developer to implement the check correctly you'd still need the browser to check 200 responses and block them if needed.
Thanks Nicolas for the quick reply, in my case if the response is giving a lot of data than possibility of CSRF is there.
Speaking with server , browser is not only one way to communicate , if i send the request from a server to server with changed origin , if it gives data back to as an response than CSRF can be done. ..Right ??
Correct me if i am wrong .
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
hi Nicolas,
Great article, you almost saved my life :P
I have one doubt, if the request origin header is is not matching to Allow-Origin-Request-Header value , why it is giving 200 ok as an respose. It shall give 401 if the both side thing is not matching .
Request origin: Evil.com
Response header :
200 ok
Allow-origin-access-control: legitimate .com
why 200 ok, why not 401 ??
Because CORS is handled by the browser. The server will never block any requests because of CORS. It's not its responsibility.
The server will always answer with a 200, but add some headers telling the browser "you're only allowed to accept this if the request was done from this domain", and the browser will block the request (and add a lovely warning in the console) if it doesn't match.
Once again, CORS is not meant to prevent malicious user agents from accessing a resource, it's only meant to prevent trusted user agents (browsers) from being tricked into impersonating the user by malicious websites. This means that asking the server to do the check and respond with a 403 would not be more effective, and since you can't expect every backend developer to implement the check correctly you'd still need the browser to check 200 responses and block them if needed.
Hope that helps !
Thanks Nicolas for the quick reply, in my case if the response is giving a lot of data than possibility of CSRF is there.
Speaking with server , browser is not only one way to communicate , if i send the request from a server to server with changed origin , if it gives data back to as an response than CSRF can be done. ..Right ??
Correct me if i am wrong .