CORS - Is it a client-side thing, a server-side thing, or a transport level thing? [duplicate]

This question already has answers here: How does the 'Access-Control-Allow-Origin' header work? (18 answers) 开发者_高级运维 Closed 6 years ago.

I am trying to understand CORS. From my understanding, it empowers you to limit which domains can access a resource on your server. However, this doesn't seem like the full story. For example, I have a web service without CORS enabled. I cannot hit this web service from my web application via jQuery (the app is running on localhost). However, I can hit the web service from Postman. So, I'm a bit confused. Is there some extra client side work that involves CORS?

---

The server is responsible for reporting the allowed origins. The web browser is responsible for enforcing that requests are only sent from allowed domains.

CORS is applied to requests when an Origin header is included in the request. This includes requests made from JavaScript and POST requests. It's not applied all resources. The origin is the protocol, host and port that is making the request. Requests made by JavaScript use the origin that loaded the JavaScript, not the origin that it was loaded from.

When CORS is not enabled a browser will rely on the same origin policy. The same origin policy is only applied to scripts. The browser will only allow scripts to be loaded from same origin as the loaded page. The same origin policy is assumed when not origins are explicitly allowed.

An HTTP client other than a browser won't use either the same origin policy or CORS. Requests made from these other HTTP clients don't have an origin. Unless the Postman desktop app emulates a browser it will be able to make requests to any URL.

CORS and the same origin policy are needed because a browser does not implicitly trust the websites it visits to make requests to other websites. They don't protect the origin site, they protect the site receiving the cross origin requests. This is why the allowed origins are up to the targeted server.

Without these policies a simple script that repeatedly loads a website could be distributed by ad networks or script injection and then any browser loading the script would contribute to a denial of service attack on the website. With CORS and the same origin policy a browser will limit the impact of this script.

Another important protection CORS provides is to protect against Cross-site request forgery. It prevents a site from making some types of requests to another site. These requests would be made using any previously created tokens, such as session tokens.

CORS by example:

A web browser loads a page from www.example.com. The page includes a script that makes a request to www.example.org. The origin of the request is www.example.com. The browser either makes the request or sends an OPTIONS request first (the preflight request). When the server at www.example.org receives a request from an origin other than www.example.org it responds with a response header Access-Control-Allow-Origin which tells the browser the origins allowed to make requests. It may also respond with other headers like Access-Control-Allow-Methods and Access-Control-Allow-Headers that can restrict the types of allowed requests. When the browser is told what origins are allowed it will block future requests from disallowed origins.

---

It's a bit of both actually. Your browser will prevent CORS requests unless the origin of the request (i.e the referrer URL domain) is in a white list on the destination, or the destination approves all requests regardless of origin.

In both cases, the required header (Access-Control-Allow-Origin) is added which tells the browser that it's ok to send the request to the destination.

This ensures that people with malicious intent cannot send requests to another domain without the the user knowing about it.