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 anAccess-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, ornull
, 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.