Cross-domain resource sharing (CORS) can relax the same origin policy of browsers, allowing different websites and different servers to communicate through browsers.

The same-origin policy

The same origin policy is a very important concept in browser security, and a large number of client-side scripts support the same origin policy, such as JavaScript. The same-origin policy allows scripts running on a page to have unlimited access to any of the methods and attributes of other scripts on the same site (same-origin).

Most methods and properties are disabled when scripts from different web pages (non-homologous) attempt to access each other. This mechanism is very important for modern Web applications because they rely extensively on HTTP cookies to maintain user permissions. The server uses cookies to determine whether the client is legitimate and can send confidential information.

Browsers strictly segregates websites from two different sources to ensure data integrity and confidentiality.

Definition of “homology” :

  • The domain name
  • agreement
  • The TCP port number

As long as the above three values are the same, we consider the two resources to be homologous. In order to better explain the concept, the following table will use “www.example.com/dir/page.ht…” This URL is used as an example to show different results under the same origin policy

The figure below shows what happens when a malicious script makes a request if CORS is not enabled

Cross-domain Resource Sharing (CORS)

The same-origin policy for large applications have too many restrictions, such as how much is the domain name Now there are A lot of technology to ease restrictions on the same-origin policy, there is A kind of technology is cross-domain resource sharing (CORS) CORS is A kind of mechanism, this mechanism by adding in the HTTP header fields, under normal circumstances, A tells the browser web application, You have permission to access application B.

This allows the same description to define “homologous” and “cross-source” operations.

The standard definition of CORS is to allow clients to access resources across domains by setting HTTP header fields.

Once authenticated and authorized by the server, it is the browser’s responsibility to support these HTTP header fields and ensure that restrictions are properly applied. The main header fields include: “access-Control-allow-Origin”

Access-Control-Allow-Origin: https://example.com
Copy the code

The “source” listed in this header field can send cross-domain requests to the server as a visitor and can read the returned text, which is prevented by the same origin policy.

By default, when the “access-Control-allow-credentials” header is not set, browsers send requests with no user identity data (cookie or HTTP identity data), so they do not reveal user privacy information. The following diagram shows a simple CORS request flow:

Identity data

The server also notifies the client whether to send the user’s identity data (cookies or other identity data). If the access-Control-allow-credentials field in the HTTP header is set to true, the client identity data will be sent to the target server

Pre-publish request

Because the request modifies the data (usually by means other than GET), the browser sends a “probe” request before sending these complex requests

The purpose of CORS precheck is to verify whether the CORS protocol is understood. The OPTION request precheck contains the following three fields

  • “Access – Control – Request – Method”
  • “Access – Control – Request – Headers”
  • “Origin”

These fields are automatically sent to the server by the browser. So, under normal circumstances, front-end developers do not need to specify such requests themselves.

If the server allows the request to be sent, the browser sends the required HTTP packets.

Allow multiple sources

The protocol suggests that you can simply separate multiple sources with Spaces, for example:

Access-Control-Allow-Origin: https://example1.com https://example2.com
Copy the code

However, without browser support for this syntax, it is usually not possible to trust all subdomains with wildcards, such as:

Access-Control-Allow-Origin: *.example1.com
Copy the code

Currently, only wildcards are supported to match domain names, such as the following:

Access-Control-Allow-Origin: *
Copy the code

Configuring the browser this way will report an error because the server must specify a single domain and cannot use wildcards when responding to requests with credentials. Simply using wildcards effectively disables the access-Control-allow-credentials field.

The result of these restrictions and behaviors is that many CORS implementations generate “AccessControl-Allow-Origin” values based on the value of the “Origin” header field

Other related header fields

There are also some header fields for CORS, one of which is “Vary”

According to the CORS implementation standard, Vary: Origin is used when “access-Control-Allow-Origin” is generated dynamically.

This header field indicates to the client that the content returned by the server will change depending on the value of Origin in the request. If this header is not set, it may be exploited by certain attacks under certain circumstances, as described in the next section

Focus on public account: Code structure, focus on high-quality technical articles original sharing and exchange, refuse hydrology, advertorials.

What does Cross-domain resource Sharing (CORS) solve?