Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
If we trust browsers that they satisfy Same Origin Policy without bugs, would we still need CSRF-tokens?
Assuming server doesn't have CORS enabled: As far as I know we are not allowed to do POST requests cross-origin, then why is there a CSRF token?
If server has CORS enabled: (assuming both GET and POST, because I don't see the point of CORSing POST but not GET)
We could GET the page, read the token and POST a correct request.
If we trust browsers that they satisfy Same Origin Policy without bugs, would we still need CSRF-tokens?
Yes, we will. Due to the fact that there are other requests that don't fall under SOP like form submit, loading scripts..etc
Assuming server doesn't have CORS enabled: As far as I know we are not allowed to do POST requests cross-origin, then why is there a CSRF token?
Even when CORS is disabled, the browser will complete XHR POST requests, the attacker won't be able to access the response, but the request will be completed and a he will successfully accomplish the CSRF attack.
This, however, will fail in case of PUT , PATCH and DELETE requests since the browser will first issue an OPTIONS request to the request endpoint to verify the request.
If server has CORS enabled: (assuming both GET and POST, because I don't see the point of CORSing POST but not GET) We could GET the page, read the token and POST a correct request.
This would be a vulnerability with the server itself. CORS should not be open to all remote hosts, only the ones you own (trust).
