Configure CORS for CDN with HTTP response headers-CDN(CDN)-阿里云帮助中心

What is cross-origin resource sharing?

Cross-origin resource sharing (CORS) is a standard mechanism that allows a web page to access resources from a different origin (domain, protocol, or port) than its own. It provides a secure way to enable cross-origin data transfers. For more information, see Cross-Origin Resource Sharing (CORS).

Note

Q: What happens if CORS is not enabled on CDN by default?

By default, CDN does not enable cross-origin resource sharing (CORS). Without this configuration, browsers enforce the same-origin policy and block cross-origin requests, which prevents other websites from loading your resources.

Why configure cross-origin resource sharing?

Due to security restrictions, browsers typically follow the same-origin policy, which restricts requests to load and access resources from different domains, subdomains, protocols, or ports. For example, example.com cannot access resources on example.org. By configuring cross-origin resource sharing (CORS), you can set relevant response headers on the CDN server. If a request includes headers that meet the allowed rules, the server returns the corresponding HTTP response headers, which allows cross-origin resources to be loaded and accessed.

How it works

CORS configured on the origin server

With CORS configured on CDN

Usage notes

If you use an OSS bucket as the origin server, the CORS configuration in the CDN console overrides the CORS configuration in the OSS console. For more information about how to configure CORS in the OSS console, see Set CORS rules.
If you use an on-premises server or an ECS instance as the origin server, we recommend that you separate static and dynamic content and use CDN to accelerate the delivery of static files. The CORS feature configured in the CDN console applies only to static files.

Enable cross-origin resource sharing

Log on to the CDN console.
In the left navigation pane, click Domain Names.
On the Domains page, find the domain that you want to manage and click Actions in the Manage column.

Click Cache, select the Modify Outgoing Response Header tab, and set the allowed sources and methods for cross-origin requests.

Set the origin for cross-origin requests

Click Customize, configure the parameters as described in the following table, and then click OK.

Parameter	Description	Example
Operation	Set this parameter to Add to enable the CORS validation feature.	Add
Response Header	You must set `Access-Control-Allow-Origin` to use the cross-origin validation feature.	Access-Control-Allow-Origin
Header Value	If CORS validation is disabled: You can specify only a wildcard or a single origin. Wildcard ``: Allows any origin to access the resource. Single origin: Allows resources to be accessed only from a specific origin (domain name). If CORS validation is enabled:* You can specify a wildcard, a single origin, multiple origins, or a wildcard domain. Wildcard ``: Allows any source to access the resource. Single origin: Allows resources to be accessed only from a specific origin (domain name). Multiple specified origins:* Configure multiple specific origins (domain names), separated by a comma `,`, to allow these origins to access the resource. Wildcard domain: Specify a wildcard domain to allow access from all origins that match the pattern.	`` `http://www.aliyun.com` `https://aliyun.com,http://www.aliyun.com` `http://.aliyun.com`
Allow Duplicates	Yes: Headers from the origin server are preserved, and the new, identically named header is also added to the response. No: The new header replaces any identically named header from the origin server. Important The Allow Duplicates and CORS Validation settings are mutually exclusive. If you set Allow Duplicates to Yes, CORS validation is disabled.	No
CORS	CORS can be configured only when Operation is set to Add, and Response Header is set to "Access-Control-Allow-Origin". CORS can be set to Disable or Enable. The default value is Disable. Disable: CDN POPs do not validate the `Origin` header in incoming requests and always return the configured `Access-Control-Allow-Origin` value. Enable: CDN POPs validate cross-origin requests based on the following rules and respond with the `Access-Control-Allow-Origin` value accordingly. Response Header: If Response Header is set to ``, the POP always returns `Access-Control-Allow-Origin:`, regardless of whether the user request contains an `Origin` header or its value. Response Header: Response Header is set to one or more specific origins, separated by commas (`,`). If the `Origin` header value in the user request exactly matches one of the configured origins, the POP responds with that origin as the `Access-Control-Allow-Origin` header value. If no match is found, the POP does not add the CORS header to the response. Response Header: If Response Header is set to a wildcard domain, the POP checks if the `Origin` header in the request matches the wildcard pattern. If you set Enable to Header Value and the domain name in the Header Value field contains a hyphen (`-`), you must escape it by replacing `-` with `%-`. Example: Original header value: `http://doc.aliyun-example.com`. Escaped header value: `http://doc.aliyun%-example.com`.	Enable

Set the methods for cross-origin requests

Click Customize, configure the parameters as described in the following table, and then click OK.

Parameter	Description	Example
Operation	Set this parameter to Add.	Add
Response Header	Must be set to `Access-Control-Allow-Methods`	Access-Control-Allow-Methods
Header Value	Supports the `GET, POST, and PUT` request methods. If you need to add `GET, POST, and PUT` at the same time, separate them with a comma `,`.	`GET`
Allow Duplicates	Yes: Headers from the origin server are preserved, and the new, identically named header is also added to the response. No: The new header replaces any identically named header from the origin server.	No

Note

Q: After adding a CORS response header, will it apply to previously cached static resources?

No. CDN caches the entire HTTP response, including headers. To apply a new CORS header to already-cached content, you must purge the URLs for those resources. Otherwise, users will continue to receive the outdated response from the cache.

Configuration examples

Example 1

If the response header value for CORS is set to one or more specific origins separated by commas (,):

If the Origin header value in the user's request exactly matches one of the specified origins, the CDN POP responds with the corresponding CORS header.
If no exact match is found, the CORS header is not included in the response.

On CDN/, set: Access-Control-Allow-Origin: http://example.com,https://aliyundoc.com.

The Origin header of the user request is http://example.com, and the CDN Point of Presence (POP) responds with Access-Control-Allow-Origin: http://example.com.
The Origin header in the user request is https://aliyundoc.com, and the CDN node responds with Access-Control-Allow-Origin: https://aliyundoc.com.
The CDN node will not respond to a user request with the Origin header http://aliyundoc.com (due to a protocol mismatch: the user request uses HTTP, while the CDN is configured for HTTPS).
If the Origin header of a request is http://aliyun.com, the CDN POP will not respond (domain mismatch).

Example 2

If the response header value for CORS is set to a wildcard domain, the POP checks if the Origin value in the request header matches the wildcard pattern.

On CDN/, set: Access-Control-Allow-Origin: http://*.aliyundoc.com.

The user request contains the Origin header http://demo.aliyundoc.com, and the CDN POP responds with Access-Control-Allow-Origin: http://demo.aliyundoc.com.
If the Origin header of a request is http://demo.example.com, the CDN POP will not respond because the domain name does not match.
The CDN node does not respond to a user request with the Origin header https://demo.aliyundoc.com because the request uses the HTTPS protocol, but the CDN is configured with the HTTP protocol.

Note

Q: How can I use curl to verify that the Access-Control-Allow-Origin header from CDN is working?

Send a GET request with an Origin header using curl -svo /dev/null and inspect the verbose output for response headers. If the Access-Control-Allow-Origin header appears in the response with the expected value (e.g., * or your specified domain), your CORS configuration is working. If the header is missing, review your custom response header rules in the CDN console and your origin server's CORS settings.

curl -svo /dev/null https://img.anleme.cc/agent/dl1.jpg -H 'origin:https://am.anleme.cc'

FAQ

Why does a cross-origin error still occur after I configure the Access-Control-Allow-Origin response header, and the header is missing from the response?

Note

Q: Does the CDN CORS configuration support multiple wildcard domains separated by commas?

No. When CORS validation is enabled on CDN, you can configure only a single wildcard domain. Alternatively, you can list multiple exact domains (non-wildcard) separated by commas. You cannot specify a comma-separated list of multiple wildcard domains, such as https://*.iflyvoice.cn,https://*.xxx.com.

Note

Q: Why do font files accessed through a CDN-accelerated domain trigger a CORS issue, while video files do not?

This behavior is determined by the resource type and the browser's security policy. By default, video files (such as MP4 or WebM) loaded via a <video> tag are not subject to CORS restrictions unless the crossorigin attribute is explicitly added. In contrast, font files (such as .ttf or .woff) are always subject to mandatory CORS validation by the browser, regardless of how they are loaded. Therefore, even if both resource types are hosted on the same domain, font requests will fail without a valid CORS policy, whereas video requests often succeed. This difference stems from standard browser security policies for different content types.

Note

Q: How can I verify that my CDN CORS configuration is effective?

You can use the following methods for verification:

Test again to see if the cross-origin error persists.
Use the curl -svo /dev/null command to send a GET request with a specific Origin header and check the response headers in the verbose output. For example:
curl -svo /dev/null https://img.anleme.cc/agent/dl1.jpg -H 'origin:https://am.anleme.cc'
Provide the test domain to technical support for assistance.

Note

Q: When accelerating an OSS bucket with CDN, how can I pass through the CORS configuration from the origin OSS?

To enable pass-through of the CORS configuration from an OSS origin server, the initial request to the CDN must include an Origin header. This allows the CDN to fetch from origin and cache the Access-Control-Allow-Origin response header. However, this caching mechanism can cause CORS issues for subsequent requests that have a different Origin or no Origin header. The recommended best practice is to configure CORS headers directly in the CDN console using the Modify Outgoing Request Header feature in Cache Settings, instead of relying on pass-through.

Note

Q: If multiple CDN domains are associated with the same OSS bucket, can I configure the CORS rule just once in OSS and have it automatically inherited by all CDN domains?

No. Because CDN POPs cache response headers and this behavior is affected by whether the initial request contains an Origin header, relying on a pass-through configuration from OSS can cause intermittent CORS errors. The best practice is to add CORS headers using the Modify Outgoing Request Header feature to ensure correct and stable behavior.