Configure cross-origin resource sharing (CORS)

Security best practices

Follow the principle of least privilege.

• Configure Origin (AllowedOrigin) precisely: Avoid setting * for Sources unless your bucket is fully public. Specify exact domains, such as https://www.example.com.

• Restrict Allowed Methods: Expose only the HTTP methods your application needs. For read-only sites, configure only GET and HEAD.

• Specify Allowed Headers explicitly: For authenticated requests (with Authorization header), do not use *. List all required request headers explicitly.

Performance best practices

• Optimize the preflight cache: A reasonable MaxAgeSeconds value, such as 86400 seconds (24 hours), significantly reduces preflight requests, lowering latency and cost.

• Evaluate the impact of Vary: Origin: Enabling Vary: Origin solves cache poisoning issues but increases CDN caching complexity. This may lower cache hit ratio and increase back-to-origin traffic (additional cost and latency). Enable only after evaluating your traffic patterns.

CDN acceleration

If your bucket is accelerated by Alibaba Cloud CDN and accessed via a CDN domain, cross-origin requests will first reach a CDN Point of Presence (PoP). You must configure CORS rules in the CDN console, not in the OSS console. The CORS configuration in OSS only applies to requests made directly to the OSS origin domain. For details, see Configure cross-origin resource sharing (CORS).

Error: No 'Access-Control-Allow-Origin' header is present on the requested resource.

This error typically means the browser has cached an old response without CORS headers, or no CORS rule matches the incoming request.

Clear your browser cache and retest. If the error persists, verify your CORS rules:

1. Log on to the OSS console.

2. Click Buckets, then click the name of the destination bucket.

3. In the navigation pane on the left, choose Content Security > CORS.

4. On the CORS page, click Create Rule.

5. In the Create CORS Rule panel, set Origin to *, select all Allowed Methods, set Allowed Headers to *, set Exposed Headers to ETag and x-oss-request-id, set Cache Timeout (Seconds) to 0, select Vary: Origin, and click OK.

6. If the issue persists, log on to any server and run the following command to view the cross-origin request headers.

   curl -v -o output_file.txt -H 'Origin:[$URL2]' '[$URL1]'

   Note

   • [URL1] is the URL of the requested OSS resource.

   • [URL2] is the origin address you configured in the CORS rule.

   The system displays an output similar to the following.

   

   • If the response includes a matching CORS header, the issue is likely browser or network caching. An earlier non-CORS request may have been cached locally, and a subsequent cross-origin request fetched this cached response instead of getting a fresh one from the server. Try the following solutions:

     • Press Ctrl+F5 in your browser to clear the cache, then test if the issue persists.

     • Set Cached-Seconds to 0 in the CORS rule. This forces every request to re-fetch CORS authorization from the server.

       Note

       You can set the cache-controlof an object to no-cache when you upload it. For objects that are already uploaded, you can ossutil to change this setting. For more information, see set-meta (Manage object metadata).

     • Use CDN to accelerate OSS, ensuring all CDN-served requests include CORS headers.

   • If the response contains two CORS headers or a header that does not match your OSS configuration, the issue is likely caused by using CDN to accelerate OSS:

     1. Log on to the CDN console and temporarily disable CDN acceleration for the domain name to confirm that the cross-origin issue is resolved.

     2. After confirmation, click the specific domain name, then navigate to Cache Configuration > Node HTTP Response Header.

     3. Set custom HTTP response headers as needed.

7. If the CORS issue is still not resolved, see Common errors and solutions for OSS CORS for further troubleshooting.

Error: The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin.

The server returned an Access-Control-Allow-Origin header, but its value does not match the request's Origin. This is often a caching problem — a browser or CDN caches the response for one domain and serves it to another.

Enable the Vary: Origin option in your CORS rule to prevent cache conflicts between different websites, or clear your browser cache before retrying.

Error: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

This error occurs because the frontend sent a credentialed request (Access-Control-Allow-Credentials is True), but Access-Control-Allow-Origin is set to *. Browsers prohibit this combination to prevent any site from accessing sensitive data like cookies or Authorization tokens.

• If you need credentials, change Sources from * to a specific domain (e.g., https://example.com).

• If you do not need credentials, set xhr.withCredentials to false in your frontend code and ensure Access-Control-Allow-Credentials is false on the server.

How to improve slow cross-origin loading from OSS?

Cross-origin loading speed depends on network latency between the client and the OSS bucket. A cross-origin request includes an Origin header. For long-distance access (for example, China (Hong Kong) to Chinese mainland), use a Transfer Acceleration endpoint to optimize the network path.