How does CORS actually protect against security issues?

Question

After reading a lot of documents from MDN and CodeAcademy I still do not fully understand what the CORS handshake actually protects against.

I understand that the mechanism shall protect the browser from requesting resources that are located at a different origin without further controls.

Furthermore, as far as I understand the specification, the access control decision is fully evaluated by the server that is target of the CORS request. For example, if the server replies with the "Access-Control-Allow-Origin" header set (e.g. to "*") the browser will be allowed to handle the response.

Here are two scenarios that raise my questions:

• If I was an evil server developer, I would reply with "Access-Control-Allow-Origin" set to * always, which allows the browser to handle the response.
• If I was an evil person and wanted to access the resources no matter what, I would use a (custom) web client that does not implement the CORS mechanism.

With this both scenarios mentioned, I wonder what CORS really protect against. And I wonder if it would be more safe to reject requests from prohibited origins and send an adequate HTTP status (e.g. 403 Forbidden) within the response.

Probably I am missing something but I'd be grateful for any hint in the right direction.

Luxuriant

developer.mozilla.org/en-US/docs/Web/HTTP/CORS – Rasure

Answer 1

In response to your points:

1. CORS is concerned with preventing cross-origin access. In this scenario, say you're accessing goodserver.com, they will be serving you the content, and they are therefore the origin in the jargon. Presumably then they're not going to serve you anything that talks to evilserver.com. Note that CORS is therefore not trying to prevent cross site scripting - in which an attacker somehow puts code on your origin that does talk to evilserver.com.

2. CORS is implemented in your browser, so as an evil person, you'd need to write a browser and persuade people to download and run it. However you're right that if you write a native app, or use HTML forms you'd not benefit from CORS security.

Your question does highlight though where the CORS system relies on trust and that's worth bearing in mind.

You might find this helpful, as they walk through the process:

https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/

Joshi

Thanks for the answer. What I do not understand is, why as a server/service developer I should provide a response at all and leave the evaluation of it to the browser. I'd say if I do not support a specific origin I wouldn't provide any data but an empy HTTP resonse with an error code. – Luxuriant

Answer 2

(I wasn't able to comprehend the other answer, so here's my take.)

Your browser tries to protect the world from itself - against sending evil Ajax requests made by an evil JS code on your behalf.

Attack example

You open evilsite.com and it serves you an evil JS code. It tells your browser to send an evil API request to your LAN devices (router, printer, etc.), or perhaps harass public servers (try passwords, configure, send spam, ddos, etc.)

Your browser notices this is a cross-site Ajax request, and trying to be nice (CORS), it rather first asks the target server (e.g. your router), if it is supposed to receive requests from strangers (the evilsite.com). Your router probably will NOT respond with Access-Control-Allow-Origin: * to the probe, so your browser stops the evil JS from sending the actual evil Ajax.

The 'probe' used to ask is usually a OPTIONS / HTTP/1.1 request. (see image)

Good example

You open goodpub.com and it serves you JS code. It tells your browser to use a public transport API server, to offer you directions to the pub. Your web server will once again, politely ask the API server, if it's OK to receive requests from strangers. This time, it will say yes (and send Access-Control-Allow-Origin: * header in response to the probe). Your browser will then trust the JS code not to be too evil, and proceed with sending the actual Ajax request.

CORS does NOT protect

• servers from evil browsers (or any evil clients in general)
• users from talking to evil servers
• users from running evil JS code
• servers which allow public Ajax requests
• servers from seemingly good JS code DDOS-ing them with "valid" requests, etc.
• your local API servers with CORS set to * from anyone on the internet, who manages to make users on your local network download & run an evil JS

Poacher