CORS (cross-domain resource sharing) is a security mechanism used to control the sharing of resources between different domains. By configuring the appropriate response header, the server can allow or restrict access to resources by external domains. This article will introduce in detail three core response headers in the CORS mechanism:Access-Control-Allow-Origin
、Access-Control-Allow-Methods
andAccess-Control-Allow-Headers
, and combine practical cases to explore their role and configuration methods in cross-domain requests.
1. What is CORS
1. CORS Overview
CORS, full name Cross-Origin Resource Sharing, is designed to solve the limitations of the same-origin policy of the browser. The same-origin policy only allows resources to be requested from the same domain name, protocol, and port, preventing cross-site scripting attacks (XSS). However, in actual development, scenarios such as front-end separation and third-party API requests require cross-domain resource sharing. CORS allows the server to tell the browser which domains can access resources, as well as the request methods and header information allowed by adding specific fields to the response header.
2. CORS workflow
CORS requests are divided into two types: simple requests and preflight requests. Simple requests such as GET and POST, only have specific headers; pre-flight requests are issued by the browser.OPTIONS
Request, ask the server in advance whether it allows some complex requests (such as PUT, DELETE). The server tells the browser the permissions for cross-domain access by setting the CORS response header.
2. Three important response headers in CORS
1. Access-Control-Allow-Origin
Access-Control-Allow-Origin
It is the most important response header in CORS, responsible for specifying which domain names are allowed to access the server's resources.
1.1 The function of the response header
When the browser initiates a cross-domain request, the server needs to include in the responseAccess-Control-Allow-Origin
to indicate the source of allowed access. The browser will determine whether the source of the current request is allowed based on this header.
1.2 The value of the head
-
Specific domain name:For example
Access-Control-Allow-Origin:
, means onlyThis domain can access this resource.
-
Wildcard
\*
: means that all domains are allowed to access resources, that is, no restrictions are imposed. But it should be noted that when using wildcards, credentials (such as cookies and HTTP authentication information) are not allowed.
1.3 Configuration Example
Access-Control-Allow-Origin:
In this configuration, onlyDomain names can access server resources across domains, and any other domain names will be denied.
1.4 Security considerations
use*
Although it is convenient to allow access to all domains, it has security risks and may lead to sensitive data leakage. When handling requests involving authentication information, you should avoid using wildcard characters and explicitly specify the allowed domain names instead.
2. Access-Control-Allow-Methods
Access-Control-Allow-Methods
The response header is used to specify the HTTP method the server allows the client to use in cross-domain requests.
2.1 The function of the response header
When the client initiates cross-domain requests, especiallyOPTIONS
When preflighting a request, the browser will ask the server whether to allow specific HTTP methods (such as GET, POST, PUT, DELETE). Server passAccess-Control-Allow-Methods
To clearly inform the client of what methods can be used.
2.2 The value of the head
The header can contain one or more HTTP methods, and common values include:
-
GET
: Allows to obtain resources. -
POST
: Allows submission of data to the server. -
PUT
: Allows update of resources. -
DELETE
: Allows deletion of resources. -
OPTIONS
: The default method for preflight requests.
For example:
Access-Control-Allow-Methods: GET, POST, PUT
Indicates that the server allows clients to use GET, POST, and PUT methods for cross-domain requests.
2.3 Configuration Example
Access-Control-Allow-Methods: GET, POST, DELETE
In this configuration, the client can use the GET, POST, and DELETE methods to make cross-domain requests, and any other method (such as PUT) will be rejected by the server.
2.4 FAQ
If the client tries to use an unauthorized method (such as PATCH), the request will be intercepted by the browser and a cross-domain error is displayed. Therefore, it is important to make sure that all the methods that need support are listed in the response header.
3. Access-Control-Allow-Headers
Access-Control-Allow-Headers
Response headers are used to specify the custom headers that the server allows clients to use in cross-domain requests.
3.1 The function of the response header
Clients can add custom headers to cross-domain requests (such asX-Custom-Header
), but these heads will not be allowed by default. passAccess-Control-Allow-Headers
, the server can specify which custom headers can be used.
3.2 The value of the head
The head can contain multiple custom heads, or allow for a specific standard head. Common values include:
-
Content-Type
: Specify the requested content type. -
Authorization
: The head used to carry authentication information. -
X-Requested-With
: Usually used in AJAX requests to identify the XMLHttpRequest object.
For example:
Access-Control-Allow-Headers: Content-Type, Authorization
Indicates that the server allowsContent-Type
andAuthorization
Cross-domain requests at the head.
3.3 Configuration Example
Access-Control-Allow-Headers: X-Custom-Header, Authorization
In this configuration, the client can useX-Custom-Header
andAuthorization
The header makes cross-domain requests.
3.4 The role of pre-flight request
When the client adds custom headers in the preflight request, the server must explicitly allow these headers in the response, otherwise the request will be blocked by the browser.
3.5 Limitations of custom headers
For security reasons, the browser will block potentially dangerous custom headers by default, such asX-HTTP-Method-Override
. If you need to use these heads, you mustAccess-Control-Allow-Headers
It is clearly listed in .
3. Practical application scenarios of CORS response header
1. Applications for front-end separation
In a front-end and back-end architecture, the front-end usually runs under one domain name, while the back-end API is deployed in a different domain name. In this case, the correct configuration of the CORS response header is crucial. For example:
Access-Control-Allow-Origin: Access-Control-Allow-Methods: GET, POST Access-Control-Allow-Headers: Content-Type, Authorization
This configuration allows front-endSell cross-domain requests to the backend and use the GET and POST methods.
2. Calls to third-party APIs
When an application needs to call a third-party API such as Google Maps or Stripe, you must make sure that the target API is configured with the correct CORS response header. For example, the Google Maps API allows wildcards*
come widely supports cross-domain access, but does not allow carrying credentials.
3. Request to carry credentials
If the request needs to include cookies or other authentication information, it must be setAccess-Control-Allow-Origin
For specific domain names and addAccess-Control-Allow-Credentials
Head:
Access-Control-Allow-Origin: Access-Control-Allow-Credentials: true
4. Summary
By correct understanding and useAccess-Control-Allow-Origin
、Access-Control-Allow-Methods
andAccess-Control-Allow-Headers
These three core CORS response headers allow developers to effectively control cross-domain resource sharing to ensure the security and flexibility of the system. In scenarios where front-end separation and third-party API calls, CORS configuration is particularly important. Setting these response headers rationally can not only improve the user experience, but also prevent potential cross-domain attacks. Hope this article helps you better understand and configure CORS response headers.
This is the end of this article about the three important response headers of CORS in a deep understanding. For more related CORS response headers, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!