To summarize:

  • CSRF is an attack where a page in a different window/tab of the browser sends nonconsensual request to an authenticated web app, that can typically be prevented from server-side by checking the Referer, Origin header of the request or including anti-CSRF token in request header or body.

  • CORS is variously defined in different sources, that might roughly be summarized as: a mechanism that host-of-origin-B indicates to the browser how or whether a host-of-origin-A content should access its resources.

Cross-origin-related attacks and party responsible for defence

  1. Nonconsensual "state-changing" requests: The server.

Be it a treacherous form submission, XHR/fetch request from a "second-origin" page, the server need to recognize and reject them.

  1. Cross-origin data (credential, privacy) leaking: The browser.

Be it a media tag (img, video, audio), XHR/fetch request, the browser must isolate those data from the access of "second-origin" pages.

  1. Q1: anythine else?

Purpose of CORS in cross-origin settings

To let browsers make informed decisions on how:

  1. To make concensual "state-changing" possible cross-origin.

Q2: Is there an real-world example of concensual cross-origin "state-changing" user action?

  1. To allow "creative" ways of collecting and using of digital assets hosted at "second-origin" host(s) by the script.


Q3: CORS doesn't help browser protect users from malicious digital asset hosts determined to steal data from users? But honest origin servers can prevent them from submitting CSRF requests?


Bit of a rambling question, so bit of a rambling answer also.

CSRF can also be defended by including a custom header on XHR requests, and with same site cookies.

CORS is not variously defined; it is a W3C standard. What sometimes causes confusion is that CORS is not really a security mechanism.

Cross-origin data leaking is an area of active research and requires defences both built-in to the browser, and in both server-side and client-side application code.

Q1) The main other cross-origin attack is cross-site scripting. Defences needed in both server-side and client-side application code. Clickjacking is another one. There are probably some more although I can't think just now.

Q2) I've found most uses of CORS are for reads. Some REST APIs have permissive CORS settings but require a security token in requests. This lets third-party domains access the API, once the user has authorized them, e.g using OAuth.

Q3) That's right, CORS is not a security mechanism and doesn't in itself defend against anything. It does sometimes stop people using insecure alternatives like JSONP so it can help security.

Not the answer you're looking for? Browse other questions tagged or ask your own question.