- Release Notes
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Instance Selection
- Service Management
- API Creation
- API Management
- API Calling
- Release and Access
- Custom Domain Name and Certificate
- Usage Plan
- VPC Upstreams
- Authentication and Security
- Log Analysis
- Access Monitoring
- API Documentation
- Application Management
- Permission Management
- Precautions
- Private IP Ranges and Public VIPs of API Gateway Regions
- Plugin Usage
- Best Practice
- Development Guide
- API Documentation
- Legacy Features
- FAQs
- Service Level Agreement
- Contact Us
- Glossary
- Release Notes
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Instance Selection
- Service Management
- API Creation
- API Management
- API Calling
- Release and Access
- Custom Domain Name and Certificate
- Usage Plan
- VPC Upstreams
- Authentication and Security
- Log Analysis
- Access Monitoring
- API Documentation
- Application Management
- Permission Management
- Precautions
- Private IP Ranges and Public VIPs of API Gateway Regions
- Plugin Usage
- Best Practice
- Development Guide
- API Documentation
- Legacy Features
- FAQs
- Service Level Agreement
- Contact Us
- Glossary
Overview
Cross-Origin Resource Sharing (CORS) is a W3C standard. It allows web application servers to perform cross-origin access control, so that cross-origin data transfer can be conducted securely. Currently, API Gateway supports configuring CORS rules to allow or deny corresponding cross-origin requests as needed.
If the default CORS configuration of API Gateway cannot meet your needs, you can configure custom complex CORS rules through the CORS plugin and bind them to APIs for taking effect.
Directions
Step 1. Create a plugin
- Log in to the API Gateway console.
- On the left sidebar, click Plugin to enter the plugin list page.
- Click Create in the top-left corner of the page and select Cross-Origin Resource Sharing (CORS) as the plugin type to create a CORS plugin.
| Parameter | Required | Description |
|---|---|---|
| Origin | Yes | Specify the origins of allowed cross-origin requests; You can specify multiple origins and separate them by commas; You can configure *, which means that all domain names are allowed; Be careful not to omit the protocol name http or https. If the port is not the default port 80, you also need to include the port. |
| Method | Yes | GET, PUT, POST, DELETE, and HEAD methods are supported. You can enumerate one or more allowed CORS request methods. |
| Allow-Headers | No | Specify the custom HTTP request headers that can be used for subsequent OPTIONS requests; You can specify multiple headers and separate them by commas; You can configure *, which means that all header are allowed; If you leave this parameter empty, all headers will be denied. |
| Expose-Headers | No | Specify the headers that can be exposed to the XMLHttpRequest object; You can specify multiple headers and separate them by commas; You can configure *, which means that all header are allowed; If you leave this parameter empty, all headers will be denied. |
| Allow Cookies | No | Specify whether to allow cookies. |
| Max-Age | Yes | Set the validity period of the result obtained by OPTIONS. The value must be a positive integer, such as 600. |
Step 2. Bind an API and make the plugin effective
- Select the just created plugin in the list and click Bind API in the Operation column.
- In the Bind API pop-up window, select the service, environment, and the API that needs to be bound to the plugin.
- Click OK to bind the plugin to the API. At this time, the configuration of the plugin has taken effect for the API.
Notes
Currently, there are two places in API Gateway where you can set CORS rules:
- Create API > frontend configuration > CORS is supported: enable the CORS is supported configuration item when creating an API, and API Gateway will add
Access-Control-Allow-Origin : *in the response header by default. - The CORS plugin as described in this document. For more information, see Directions.
The CORS plugin has a higher priority than the CORS is supported configuration item. When the former is bound to an API, the latter of the API will not take effect.
Yes
No
Was this page helpful?