CORS was designed to mitigate e.g. the following attack:

* You are logged at with service X, which uses a Cookie to store your authentication code.

* Service X offers an endpoint to change your password, as well as an endpoint to retrieve your user account.

* You visit malicious website Y, which uses JS to send requests to the "change password" and "view profile" endpoints of service X (which without CORS would be accepted as the browser sends your authentication cookie with them), getting your profile information and changing your password, thereby taking over your account.

With CORS, for requests from third-party domains the browser first sends an "OPTION" pre-flight request to service X, which would then respond with a set of CORS headers from which the browser can determine if the given domain you're on (Y) is allowed to send requests to the service. If not, the request (e.g. GET, POST, PUT, DELETE) is not even sent. CORS therefore protects the user from malicious websites while still allowing requests from specific third-party domains (as there are legitimate use cases for sending API requests to a third-party website).

Note that CORS does not protect you from user-triggered requests (e.g. actively submitting an HTML form), for which you need CSRF tokens if you use cookies for authentication (which are sent automatically with each request).

Aha - I think this answers something that has always confused me.

If I create a micro-service and want to protect it, CORS doesn't help me very much. I still need some sort of authentication mechanism (perhaps provided in a cookie) to say, "yes - this request is permitted."

CORS helps protect that authentication mechanism within a browser.

Is that about right?

Yup! CORS is meant to protect a service's users, not the service itself. Services should always authenticate/distrust user input/etc; no client-side technology makes that unnecessary.

If you need CSRF tokens for forms, etc, then what does CORS give you above CSRF tokens?

CSRF tokens are usually only used for state-altering requests (POST, GET etc.), though one could use them for GET requests as well. The reason people don't do use CSRF for GET is that there's usually no risk involved when calling a GET endpoint from your browser, as it's not supposed to change the state of a resource in any way. And since an HTML form submission or included link will take the user directly to your API, there's no way for the attacker to extract the information afterwards (which is of course given if the attacker can make the request asynchronously via Javascript).

You can also use the "Referer" and "Origin" headers to defend your API against form submission from third-party websites without using any CSRF tokens (as browsers will include the URL/domain of the site from which the form was submitted), though there were numerous cases where browsers or e-mail clients didn't set these headers correctly, so if you really want to be sure the only way is to use a CSRF token. You can put that token e.g. in a JS-readable cookie, which will not be accessible on third-party websites but which you can read out via JS on your domain and then include in the POST/PUT/... request. If you want to run your code from different domains as well you will have to provide an endpoint from which users can get the CSRF token though (as Cookies from your API domain will not be readable there). You will then need to restrict that endpoint using CORS, as otherwise an attacker will be able to get a valid token and e.g. inject that into an HTML form which he/she can then submit.

So CORS and CSRF do different things, but for API-based apps that should be able to run on multiple (non-sibling) domains you need both mechanisms to ensure security (and CSRF needs CORS in that case to function).

But what if one website wanted user data from another website. Couldn't b.com make a GET request to a.com(assuming the user is on b.com now, and was on a.com previously, with a cookie), using the cookie for a.com in the browser and get the user's info from a.com, then send that to b.com? All without the user or a.com knowing?

You meant "POST, PUT, etc"

Yes, GET doesn't make any sense there.

CSRF tokens are a popular mitigation against CSRF, where CSRF is a "vulnerability" that arises in part when a user is tricked into asking its user-agent to make a request the user didn't actually intend.

This is particularly likely to happen in web browsers because they support hyperlinks or image tags to arbitrary destinations (which turn into GET requests), and support form auto-submission to arbitrary targets (which turn into POST requests). The request will often inherit the user's legitimate authentication posture on the target site, because all cookies and headers are also sent, riding on the user's existing session. Despite all this unpleasantness, a web browser adheres to the 'same-origin policy', which prevents the response from CSRF attack to be made known to the originating site. Given the predominance of interactive user-agents that support the same-origin policy, it's not very likely to be tricked into a CRSF with a user-agent that doesn't adhere to the same-origin policy.

CORS isn't a security feature per se, it's a mechanism to selectively relax the same-origin policy to obtain a response from a different source, if that source consents.

I've always found it interesting how there's a difference between actions the user initiated and those the user did not. You'd think that would be very challenging to enforce, given how flexible browser scripting is nowadays, but it seems to Just Work.

There isn't, though. It really is just the same origin policy at work (or, if you mean more abstractly, the website flagging them differently; you can still construct it into a curl call that will be indistinguishable, barring something like a varying CSRF token that requires the page to be loaded, but again, that can still be faked by loading the page, grabbing the token, and using it in the resulting cURL call).

But preventing PUT/POST/DELETE from other origins prevents other origins from making requests on the user's behalf. It also prevents the user from making those requests. It either has to be a GET (which is itself a security hole, but one necessary to the basic utility of the web and which -should- be okay provided people do indeed make GETs idempotent; it has been leveraged into JSON-P, a terrible unsafe hack, though), or it has to use CORS to preflight it.

Once you have CORS in place, it's still indeterminate as to whether the action was user initiated or not. It's just that a request originating from origin (X) has been allowed.

That's not entirely correct, as you can still create a form on page Y and have it submit a POST request to site X even if CORS is enabled, as CORS does only govern asynchronously triggered requests. So you still need CSRF to fully protect against malicious form submissions from third-party domains.

Well, yes. POSTs of the right MIME type also work, not just GETs, due to, again, the way the web worked prior to AJAX and APIs and all that lovely goodness requiring some rethinking the web's security model (back when we had 'submit' forms and that was it).

So, technically accurate WRT where the same origin policy applies, but not really relevant to the parent's base statement that you can differentiate between what is and is not user triggered (since you can send a payload in code with the same MIME type and etc so that it looks identical to what a form would send).

Well, there are a number of reasons, but let me give you one of the more important ones:

If a browser were allowed to make cross-origin requests without restrictions, any site could take advantage of a user’s active session on any other site to perform unapproved actions on that user’s behalf. Without CORS, for instance, if you came to my site with an active Facebook session, I could get information about your account (by making cross-origin requests to Facebook) that I wouldn’t otherwise have access to. Or, if I were feeling a bit more nefarious, I could change information — possibly your password and gain control of your account.

The possibIlities for bad actors to do these types of things is also part of the reason CORS requests don’t include most headers by default, and you have to be very explicit about which headers to expose.

Yeah, this aspect of CORS is almost never properly explained.

First off, it's not about the authentication cookie. It would be simple enough for browsers to just omit cookies in cross-domain requests.

Here's an example of a real issue:

1. You have a network-attached storage device on your LAN.

2. Because the device is not accessible from the public internet, you have decided not to enable authentication. Anyone on the local network can issue requests.

3. You visit a malicious website.

4. That website's JS makes network requests to your device.

Basically, when you run JS in your browser, it's using your computer's network context. That context may have privileges that not everyone has (e.g. authentication based on source IP). You don't want random JS code to have those privileges.

Browsers, by consensus, adhere to a security approach called 'same-origin policy', which limits the situations that data from one context can be read by another context. CORS is a targeted way of relaxing some of those restrictions, so that you can obtain data from another context if the source endpoint consents.

Of course there are other HTTP clients. Anyone can write one, and they're probably not going to adhere to the same-origin policy. CORS, therefore, isn't really a security feature in the same vein as, say, CSRF-prevention tokens; rather, it's a language to communicate to a 'same-origin policy'-compliant user-agent to allow some cross-origin data sharing, lessening the need to pipe everything through script tags (JSONP) or one's own proxy.

CORS allows you to whitelist what domains you accept certain requests from. This is a good thing.

One thing I never understood really is why a webpage is able to load scripts from a different domain. That will I suppose remain a mystery to me forever. Imagine how many fewer ads and junk we might see.

this is a cool feature but the actual whitelist has to be held internally, in responding to an OPTIONS request, you can respond with * or concrete domain name. you can't return something like "www.example.com, www.foo.com" .

if you want to whitelist multiple domains you have to resolve this server side and check the requesting domain against your list of accepted domains.

this took me a little while to figure out.

Right - it is a good safety feature. Also worth noting that responding with a wildcard will not allow you to set cookies in the browser when using `withCredentials` in the client and `access-control-allow-credentials` on the server. You've got to return a specific origin (one that is a match in your whitelist)

Because those requests will contain authorization? Like cookies? Am I missing something?

It's to protect against malicious sites, not malicious clients.

CORS prevents your browser from being an unwitting attack vector by an evil website.

My impression is that people wanted to make use of API's from third parties which would have been prevented by the same origin policies. CORS allowed them to relax that policy for the API's and services they wanted to use w/o totally removing the security against cross site scripting that the same origin policy provides. Having to proxy all requests through a server would have defeated the purpose of the new breed of paid APIs who's end goal seems to be to allow you to build a complex web site w/o having to wade into the details of maintaining the backed servers you would have traditionally needed and all the complexity that entails at scale.

Along with the other responses here, also check out the very brief OWASP documentation on CORS at this link. [1] Searching that site for CORS would also be helpful.

[1]: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#C...