CORS-它是客户端的东西,服务器端的东西,还是传输级的东西?

我正在努力理解 CORS。根据我的理解,它允许您限制哪些域可以访问服务器上的资源。然而,这似乎并不是故事的全部。例如,我有一个没有启用 CORS 的 Web 服务。我无法通过 jQuery 从我的 Web 应用程序访问这个 Web 服务(该应用程序在 localhost 上运行)。但是,我可以从 Postman 访问 Web 服务。所以,我有点困惑。是否有一些额外的客户端工作涉及 CORS?

71222 次浏览

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.

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.