Cross-origin resource sharing (CORS) is a standard cross-origin solution provided by HTML5 to allow web application servers to control cross-origin access. This way, the security of data transmission across origins is ensured.

Usage notes

  • You can configure up to 10 CORS rules for a bucket.
  • When Object Storage Service (OSS) receives a cross-origin request or an OPTIONS request that is destined for a bucket, OSS reads the CORS rules that are configured for the bucket and attempts to match the rules one after another. If OSS finds the first match, OSS returns corresponding headers. If the request fails to match the CORS rules, OSS does not include CORS headers in the response.
  • To implement CORS after Alibaba Cloud CDN is activated, you must configure CORS rules in the CDN console. For more information, see Alibaba Cloud Content Delivery Network how to configure cross-origin resource sharing by using HTTP headers (CORS).


  1. Log on to the OSS console.
  2. In the left-side navigation pane, click Buckets. On the Buckets page, click the name of the bucket that you want to manage.
  3. In the left-side navigation pane, choose Access Control > Cross-Origin Resource Sharing (CORS). In the Cross-Origin Resource Sharing (CORS) section, click Configure.
  4. Click Create Rule. In the Create Rule panel, configure the parameters. The following table describes the parameters.
    Parameter Required Description
    Sources Yes The sources from which you want to allow cross-origin requests. When you configure the sources, take note of the following rules:
    • You can configure multiple rules for sources. Separate multiple rules with line feeds.
    • The domain names must include the protocol name, such as HTTP or HTTPS.
    • You can use an asterisk (*) as the wildcard character. Each source can contain up to one asterisk (*).
    • If a domain name does not use the default port, the domain name must contain the port number. Example:
    The following examples show how to configure domain names:
    • To match a specified domain name, enter the full domain name. Example:
    • To match second-level domain names, use an asterisk (*) as the wildcard character in the domain name. Example: https://*
    • To match all domain names, enter only an asterisk (*) as the wildcard character.
    Allowed Methods Yes The methods that cross-origin requests are allowed to use.
    Allowed Headers No The response headers for the allowed cross-origin requests. When you configure the headers, take note of the following rules:
    • This parameter is in the key:value format and not case-sensitive. Example: content-type:text/plain.
    • You can configure multiple response headers. Separate multiple response headers with line feeds.
    • Each rule can contain up to one asterisk (*) as the wildcard character. Set this parameter to an asterisk (*) if you do not have special requirements.
    Exposed Headers No The response headers for allowed access requests from applications, such as an XMLHttpRequest object in JavaScript. Exposed headers cannot contain asterisks (*).

    We recommend that you set the following common exposed headers:

    • x-oss-request-id

      If you encounter an issue, contact technical support and provide the request ID to locate and resolve the issue.

    • ETag

      You can use the ETag value of an object to check whether the object content is modified.

    Cache Timeout (Seconds) No The period of time in which the browser can cache the response to an OPTIONS preflight request for specific resources. Unit: seconds.
    Vary: Origin No Specifies whether to return the Vary: Origin header.

    If both CORS and non-CORS requests are sent to OSS, or if the Origin header has multiple possible values, we recommend that you select the Vary: Origin header to avoid errors in the local cache.

    Notice If Vary: Origin is selected, visits through the browser or the CDN back-to-origin requests may increase.

    For more information about the parameters, see PutBucketCors.

  5. Click OK.