How does Access-Control-Allow-Origin header Work ?

access control allow headers

CORS and Access-Control-Allow-Origin response headers

CORS By using a set of HTTP headers to provide a controllable relaxation of the same-origin policy, browsers allow access to responses to cross-domain requests based on these headers.

CORS related headers

Origin: Refers to the request originator domain.

Access-Control-Request-Headers: Used for pre-check requests, telling the server which custom header fields will be in the actual request.

Access-Control-Request-Method: Used to preflight a request to tell the server which method the actual request will be used.

Access-Control-Allow-Origin: Refers to which domains the requested resource is allowed to be shared. . Access-Control-Allow-Credentials: Refers to whether to allow the browser to send a request containing credentials.

Access-Control-Allow-Headers: Refers to the custom request header allowed by the actual request.

Access-Control-Allow-Methods: Refers to the request method allowed by the actual request.

Access-Control-Expose-Headers: Refers to the fields in the response header that js is allowed to obtain.

Access-Control-Max-Age: Refers to the number of seconds in which the result of the pre-check request is valid.

Implement simple CORS

CORS Specification defines the first exchange of content between the web server and browser, which Access-Control-Allow-Origin is the most important.
When the site launches a cross-domain resource request, the browser will automatically add the Origin header, then the server returns an Access-Control-Allow-Origin response header.

strict-origin-when-cross-origin

	const express = require('express');
const app = express();

app.post('/info', (req, res) => {
  res.setHeader('access-control-allow-origin', req.headers.origin || '*');
  console.log('post info');
  res.end('post');
});

access control allow origin

Browser side

	fetch('http://123.456.789.111:8888/', {
  method: 'post',
  headers: {
    some: 'some',
  },
});

The origin for the example.com site launched cross-domain requests as follows.

	GET /data HTTP/1.1
Host: robust-website.com
Origin: https://example.com

allow access control origin

Server response

	HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com

The browser will allow the example.com website code to access the response because the Access-Control-Allow-Origin matches the Origin.

Access-Control-Allow-Origin allows multiple domains, or null, or wildcard character *.
But no browser supports multiple origins, and there are restrictions on the use of wildcards.

Cross-domain resource request with credentials

The default behaviour of cross-domain resource requests is that the request does not carry credentials such as cookies and Authorization headers.
However, for cross-domain requests with credentials, the server can allow the browser to read the response by setting the Access-Control-Allow-Credentials: true response header.

For example, a website uses JavaScript to control the sending of cookies when making a request.

	GET /data HTTP/1.1
Host: robust-website.com
...
Origin: https://example.com
Cookie: JSESSIONID=<value>

The response is:

	HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

Then the browser will allow the requesting website to read the response because Access-Control-Allow-Credentials is set to true. Otherwise, the browser will not allow access to the response.

Use wildcards to relax CORS

The Access-Control-Allow-Origin header supports the use of wildcard characters *, such as

	Access-Control-Allow-Origin: *

Wildcards cannot be used with other values.

	Access-Control-Allow-Origin: https://*.example.com

Fortunately, based on security considerations, the use of wildcards is restricted. You cannot use wildcards and cross-domain transmission with credentials at the same time. Therefore, the following forms of server response are not allowed

	Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Because this is very dangerous, it is equivalent to disclosing all the authenticated content on the target website to everyone.

PreCheck

To protect the legacy resources from the extension request allowed by CORS, preflight is also part of the CORS specification.

In some cases, when a cross-domain request includes a non-standard HTTP method or header, the browser will initiate a request with the method OPTIONS before making the cross-domain request.

For example, the preflight request using the PUT method and the Special-Request-Header custom request header is:

	OPTIONS /data HTTP/1.1
Host: <website name>
...
Origin: https://example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Special-Request-Header

The server may respond.

	HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Special-Request-Header
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240

The meaning of this response

–Access-Control-Allow-Origin allowed request domain.
–Access-Control-Allow-Methods Allowed request methods.
–Access-Control-Allow-Headers Allowed request headers.
–Access-Control-Allow-Credentials allows requests with credentials.
–Access-Control-Max-Age sets the maximum caching time of the preflight response through caching to reduce the extra HTTP request round trip overhead added by the preflight request.

References

Mozilla