Help Center/ Object Storage Service/ User Guide/ Data Security/ Configuring CORS to Allow Cross-Origin Access to OBS
Updated on 2026-09-23 GMT+08:00
View PDF
Share

Configuring CORS to Allow Cross-Origin Access to OBS

OBS provides cross-origin resource sharing (CORS) in HTML5 to enable cross-origin access.

You can create CORS rules or replicate existing CORS rules from another bucket.

Scenarios

In a typical web page request, the browser's same-origin policy (SOP) allows a page to access resources only when the protocol, domain name, and port are the same. Scripts and content from different origins (different protocols, domain names, or ports) cannot interact. In other words, due to the same-origin policy, JavaScript running in one domain cannot operate objects in another domain. OBS supports cross-origin resource sharing (CORS), allowing OBS resources to be accessed across origins.

CORS is a browser-standard mechanism defined by the World Wide Web Consortium (W3C). It defines a way for web client applications in one origin to interact with resources in another origin.

OBS supports CORS. OBS resources can be accessed across origins.

OBS supports static website hosting. Static websites stored in OBS can respond to website requests from another origin only when CORS is configured for the bucket where the website files are stored.

CORS:
  • Enables you to access OBS resources without using a proxy when using JavaScript and HTML5 to develop web applications.
  • Enables you to directly upload files to OBS with the dragging function of HTML5, view the progress, or update contents directly from web applications.
  • Enables external web pages, style sheets, or HTML5 applications hosted in different origins to share web fonts or images stored in OBS.

The CORS configuration takes effect within two minutes.

By default, OBS allows all domains to access the root domain through cross-origin requests, which may expose clients to security risks.

To avoid these risks, you can create a custom crossdomain.xml file in your bucket and add Security.loadPolicyFile("https://bucket.obs.ap-southeast-1.myhuaweicloud.com/crossdomain.xml") in your flash code. Replace bucket.obs.ap-southeast-1.myhuaweicloud.com with the actual domain name of your bucket.

How It Works

If two web pages use the same protocol, domain name (or IP address), and port, they are considered to be from the same origin. If any of these three elements is different, the web pages are considered to be from different origins. To better understand cross-origin rules, see Table 1.

Table 1 Same-origin check examples

Current Page

Requested Resource

Cross-Origin

Access Result

Cause

https://support.huaweicloud.com/dir/test.html

https://support.huaweicloud.com/dir/other.html

No

Succeeded

Same-origin (same protocol, domain name, and port)

https://support.huaweicloud.com/dir/test.html

https://support.huaweicloud.com/dir/inner/other.html

No

Succeeded

Same-origin (same protocol, domain name, and port)

https://support.huaweicloud.com/dir/test.html

http://support.huaweicloud.com/dir/test.html

Yes

Failed

Different protocols

https://support.huaweicloud.com/dir/test.html

https://support.huaweicloud.com:81/dir/test.html

Yes

Failed

Different ports

https://support.huaweicloud.com/dir/test.html

https://help.huaweicloud.com/dir/test.html

Yes

Failed

Different domain names

When a web page requests an OBS resource, the browser checks whether OBS explicitly allows cross-origin access because the web page and OBS use different domain names.

  • If no CORS rule is configured for OBS, the browser rejects the request and reports an error.
  • If CORS rules are configured for OBS, you can specify which cross-origin requests are allowed. When the CORS rules of the web page and OBS match, OBS returns headers such as Access-Control-Allow-Origin in the response. The browser allows the web page to access OBS resources only after receiving the response.

Constraints

A bucket can have a maximum of 100 CORS rules configured.

Important Notes

A CORS rule takes effect within two minutes after being configured.

Creating a CORS Rule

You can use OBS Console, APIs, or SDKs to create CORS rules. You cannot use OBS Browser+ or obsutil to do so.

Using OBS Console

  1. In the navigation pane of OBS Console, choose Buckets.
  2. In the bucket list, click the desired bucket. The Objects page is displayed.
  3. In the navigation pane, choose Data Security > CORS Rules.
  4. Click Create. The Create CORS Rule dialog box is displayed. See Figure 1 for details.

    Figure 1 Creating a CORS rule

  5. In the Create CORS Rule dialog box, set the parameters.

    If CDN acceleration is enabled for the bucket, HTTP headers must be configured on CDN. For details, see HTTP Header Settings.

    Table 2 CORS rule parameters

    Parameter

    Mandatory

    Description

    Allowed Origin

    Yes

    Specifies the origins (websites) from which requests can access the OBS bucket.

    Format: Protocol://Domain name:Port, where Port is optional.

    • Settings and constraints:
      • You can enter multiple allowed origins and separate them with line breaks.
      • You can contain only one wildcard (*) at most in each line.

        Invalid origin: https://*.example.* or https://*.

      • If you enter an asterisk (*) as the allowed origin, any cross-origin request is allowed.
    • Example: 
      http://rds.example.com
https://*.vbs.example.com
http://localhost:*

    Allowed Method

    Yes

    Specifies the cross-origin request methods allowed for buckets and objects.

    You can select multiple methods.

    Allowed methods include:

    • GET: Allows all retrieval operations for OBS buckets and objects, such as fetching object content, viewing bucket capacity, reading bucket policies, and obtaining object ACLs.
    • POST: Allows all update operations for OBS buckets and objects, such as updating bucket policies, bucket ACLs, and object ACLs.
    • PUT: Allows all setting operations for OBS buckets and objects, such as setting bucket policies, bucket ACLs, and object ACLs.
    • Delete: Allows all deletion operations for OBS buckets and objects, such as deleting bucket policies, objects, and buckets.
    • HEAD: Allows requests to obtain information for OBS buckets and objects without fetching the full body content, such as obtaining bucket metadata.

    Allowed Header (Optional)

    No

    Specifies which headers are allowed in preflight requests. For details about preflight requests, see CORS Request Types.

    • Settings and constraints:
      • You can enter multiple allowed headers and separate them with line breaks. The headers are case-insensitive.
      • You can contain only one asterisk (*) at most in each line.
      • If you enter an asterisk (*) as the allowed header, any header can be carried in cross-origin requests.
      • Spaces, ampersands (&), colons (:), less-than signs (<), and full-width characters are not allowed.
    • Common headers:
      • Authorization: signature information carried in the request
      • Content-Length: length of a message (excluding the message header)
      • Content-Type: type of the requested resource, for example, text/plain.
      • Date: date and time at which the request is initiated
      • Host: requested host and port number
      • Cache-Control: cache directive
      • Connection: network connection control, for example, keep-alive
      • User-Agent: user agent information of the request sender, for example, browser type
      • Accept: type of content that can be processed by the client
      • Accept-Language: natural language that can be accepted by the client
      • Accept-Encoding: content encoding that can be accepted by the client
      • Accept-Charset: character set that can be accepted by the client

    Exposed Header (Optional)

    No

    Specifies the exposed headers in CORS responses, providing additional information for clients. By default, a browser can access only headers Content-Length and Content-Type. If the browser wants to access other headers, you need to configure those headers in this parameter.

    • Settings and constraints:
      • You can enter multiple exposed headers, one per line.
      • Spaces, asterisks (*), ampersands (&), colons (:), less-than signs (<), and full-width characters are not allowed.
    • Common exposed headers:
      • ETag
      • x-obs-request-id
      • x-obs-api
      • Cache-Control
      • Content-Disposition
      • Content-Encoding
      • Expires
      • x-obs-id-2
      • x-reserved-indicator
      • x-obs-version-id
      • x-obs-copy-source-version-id
      • x-obs-storage-class
      • x-obs-delete-marker
      • x-obs-expiration
      • x-obs-website-redirect-location
      • x-obs-restore
      • x-obs-version
      • x-obs-object-type
      • x-obs-next-append-position

    Cache Duration (Optional)

    Yes

    Specifies how long your client (browser) can cache the response for an OPTIONS preflight request.

    Within the cache validity period, the same cross-origin request for the same resource will not send a preflight request again.

    The duration is in seconds (100 seconds by default). The value range is 0~9999999.

  6. Click OK.

    If the new CORS rule is displayed in the CORS rule list, the CORS configuration is successful. The CORS configuration takes effect within two minutes.

    Example: There is a bucket named testbucket. The allowed origin is set to https://www.example.com, the allowed method to GET, the allowed headers to *, the exposed header to ETag, and the cache duration to 100. This configuration indicates that OBS allows only GET requests from https://www.example.com to access testbucket and does not restrict request headers. The ETag value can be returned in the response. The client can cache the CORS response for 100 seconds.

Using APIs

Configuring Bucket CORS

Using SDKs

Java

Python

C

Go

BrowserJS: not supported

.NET

Android

iOS

PHP

Node.js

Example Scenarios

The following describes how to configure CORS rules for different service scenarios.

Loading Static Resources from an OBS Bucket to a Website

If you want to load and display images and JS files stored in test-bucket on the website https://www.testexample.com, configure the CORS rule parameters for the bucket based on the table below.

Table 3 CORS rule parameters

Parameter

Value

Description

Allowed Origin

 
https://www.testexample.com

Only cross-origin requests from this website are allowed to access test-bucket.

Allowed Method

GET and HEAD

GET and HEAD are used to obtain information about objects in a bucket.

Allowed Header (Optional)

Left blank

Leave this parameter blank because this example demonstrates a simple scenario where a preflight request is not triggered.

Exposed Header (Optional)

 
ETag
Content-Length

Etag is used to verify object integrity, and Content-Length is used to display the loading progress.

Cache Duration (Optional)

86400

Setting this parameter to 24 hours reduces repeated preflight requests.

Uploading Files to an OBS Bucket

If you want to upload files such as resumes, award certificates, and technical achievements to bucket test-bucket01 from the website https://www.testexample01.com, configure the CORS rule parameters for the bucket based on the table below.

Table 4 CORS rule parameters

Parameter

Value

Description

Allowed Origin

 
https://www.testexample01.com

Only cross-origin requests from this website are allowed to access test-bucket01.

Allowed Method

Select PUT and POST.

PUT and POST are used to upload or update files in a bucket.

Allowed Header (Optional)

*

The security of browser uploads is ensured through signature validation. In this example, use the asterisk (*) to allow compatibility with multiple SDK-generated headers.

Exposed Header (Optional)

 
ETag
x-obs-request-id
  • Etag is used to verify object integrity.
  • x-obs-request-id is the value created by OBS to uniquely identify the request. OBS uses this value to locate the fault.

Cache Duration (Optional)

600

If object uploads are infrequent in this example, set the parameter to 10 minutes to reduce preflight requests and improve response speed.

Accessing an OBS Bucket from Multiple Environments

If multiple production lines (for example, line01.testexample.com and line02.testexample.com) need access to the files in test-bucket02, configure the CORS rule parameters for the bucket based on the table below.

Table 5 CORS rule parameters

Parameter

Value

Description

Allowed Origin

 
https://*.testexample.com

The wildcard (*) allows all HTTPS subdomains under the domain name testexample.com to access test-bucket across different origins.

Allowed Method

Select GET, PUT, and POST.

Files in the OBS bucket can be uploaded and updated.

Allowed Header (Optional)

*

When multiple production lines access the bucket, different headers may be introduced. Therefore, you can use an asterisk (*) to allow any header, avoiding frequent CORS rule updates.

Exposed Header (Optional)

 
ETag
x-obs-request-id
  • Etag is used to verify object integrity.
  • x-obs-request-id is the value created by OBS to uniquely identify the request. OBS uses this value to locate the fault.

Cache Duration (Optional)

3600

Setting the client to cache preflight request results for one hour makes switching and debugging across multiple production lines more flexible.

Accessing an OBS Bucket via an API with a Signature

If the website https://api.testexample.com needs to carry a signature to access files in the protected bucket test-bucket03, configure the CORS rule parameters for the bucket based on the table below.

Table 6 CORS rule parameters

Parameter

Value

Description

Allowed Origin

 
https://api.testexample.com

Only cross-origin requests from this website are allowed to access test-bucket03.

Allowed Method

Select GET, PUT, and DELETE.

Files in the OBS bucket can be uploaded, updated, and deleted.

Allowed Header (Optional)

 
Authorization
Content-Type

Permission control is strict. Do not use the wildcard (*), and comply with the principle of least privilege.

The request for accessing an OBS bucket across domains carries the signature and the type of the resource to be accessed.

Exposed Header (Optional)

 
ETag
Content-Length

Etag is used for cache verification, and Content-Length is used to display the loading progress.

Cache Duration (Optional)

600

Setting this parameter to 10 minutes helps quickly update security policies.

CORS Request Types

CORS involves two request types: simple requests and preflight requests, distinguished by whether a preflight check is required.

  • Simple request: The actual request is sent directly without a preceding preflight request.
  • Preflight request: An initial OPTIONS request is sent to verify whether the server allows the actual request. After receiving a positive response, the actual request is sent.

    Preflight requests enhance the security of cross-origin access, prevent malicious websites from issuing harmful requests to OBS, and enable controlled cross-origin resource sharing.

Simple requests and preflight requests require different CORS rule configurations, as described in Table 7.

Table 7 CORS rule configurations for simple and preflight requests

Request Type

Trigger Condition

CORS Configuration

Description

Simple requests

All of the following conditions must be met:

  • Request method: GET/POST/HEAD
  • Request headers:
    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type: application/x-www-form-urlencoded, multipart/form-data, and text/plain
  • Custom request headers: none

Allowed Origin

For simple requests, only the requested domain names are verified on the server. The request methods and request headers are not verified.

Preflight requests

Any of the following conditions are met:

  • Request method: any method (such as PUT/DELETE) except GET/POST/HEAD
  • Content-Type: any value (such as application/json) except application/x-www-form-urlencoded, multipart/form-data, and text/plain
  • Custom request headers: x-obs-* (as an example)

All three of the following parameters must be configured:

  • Allowed Origin
  • Allowed Method
  • Allowed Header

For preflight requests, the requested domain names, request methods, and request headers are verified on the server.

If these domain names, request methods, and request headers match those specified in the CORS rules configured on OBS, the client sends the actual request.

The following details the process of handling simple and preflight requests.

  1. The browser sends the actual request directly to the OBS server and automatically includes the Origin header (for example, Origin: https://www.example.com).
  2. The OBS server verifies the Origin header value against the CORS rules (the value of Allowed Origin).
    • If they match, OBS adds the Access-Control-Allow-Origin header (set to the value of Allowed Origin) to the response and returns it to the browser.
    • If they do not match, the request fails.
  3. After receiving the response, the browser checks whether the Access-Control-Allow-Origin header value matches the domain name in the original request. If they match, the request succeeds; otherwise, it fails.
  1. The browser sends an OPTIONS preflight request containing the domain name, request method, and request headers to the OBS server. This request does not include service data.
  2. The OBS server checks the domain name, request method, and request headers in the preflight request against the configured CORS rules (the values of Allowed Origin, Allowed Method, Allowed Header, and Cache Duration).
    • If the values match, the OBS server returns a response indicating that the preflight request is allowed.
    • If they do not fully match, the request fails and the actual request is not sent.
  3. After receiving the preflight response, the browser sends the actual request to the OBS server, following the same process as a simple request.

Replicating CORS Rules

You can use OBS Console to replicate CORS rules. You cannot use APIs, SDKs, OBS Browser+, or obsutil to do so.

  1. In the navigation pane of OBS Console, choose Buckets.
  2. In the bucket list, click the desired bucket. The Objects page is displayed.
  3. In the navigation pane, choose Data Security > CORS Rules.
  4. Click Replicate.
  5. Select a replication source, which is the bucket whose CORS rules you want to replicate.

    • The CORS rules replicated from a source bucket do not overwrite existing rules in the current bucket. Any rules that conflict with existing ones are not replicated.
    • The version of both the source and destination buckets must be 3.0.
    • There can be 100 CORS rules at most in a bucket. If the number of rules you plan to replicate plus the number of existing rules in the destination bucket exceeds 100, the replication will fail. Before replicating the rules, delete some if necessary.
    Figure 2 Replicating CORS rules

  6. Click OK to replicate the CORS rules to the current bucket.

Best Practices

  • Scenarios with high security requirements

    In scenarios with high security requirements, you are advised to configure CORS rules with attention to the settings of Allowed Origin, Allowed Method, and Allowed Header.

    • Accurately configuring the allowed origin: If the bucket is not fully open to the public, avoid using the wildcard (*) and specify the exact domain name.
    • Minimizing allowed methods: Evaluate the request methods required by the service and avoid setting too many allowed methods. For example, if you only need to view images in a bucket on a website, set the method to GET and HEAD.
    • Listing only necessary allowed headers: Follow the principle of least privilege and explicitly list the required request headers. Avoid using the wildcard (*).
  • Scenarios with high performance requirements

    In scenarios with high performance requirements, you are advised to reduce the number of preflight requests to improve access performance.

    You can set an appropriate cache duration (for example, 86,400 seconds) to reduce the number of preflight requests.

  • Working with CDN

    If CDN acceleration is enabled for a bucket and the CDN domain name is used to access it, cross-origin requests to OBS first reach the CDN PoP. There are two configuration modes:

    • Configure HTTP headers on CDN so that CDN directly returns the CORS headers. For details, see Configuring HTTP Headers.
    • Allow CDN to transparently pass through the CORS headers returned by OBS. In this case, configure CORS rules on OBS.

    The CORS rules configured on OBS take effect only when requests directly access the OBS origin server domain name or CDN transparently forwards the origin server's response headers.

References

What Do I Do If the Browser Displays the Error Message "No 'Access-Control-Allow-Origin' Header Is Present on the Requested Resource"?

This error indicates that the browser does not find the Access-Control-Allow-Origin response header. The possible cause is an incorrect origin configuration in the CORS rule, preventing the request from matching. Another possible cause is that the browser caches an older response without this header. Perform the following steps:

  1. Clear the browser cache and try again.
    • If the issue is resolved, the cause is browser caching. To prevent recurrence, set the cache duration in the CORS rule to 0.
    • If the issue persists, go to 2.
  2. Check whether the origin configuration in the CORS rule matches the cross-origin request.
    • If not, update the setting of Allowed Origin in the CORS rule.
    • If it matches but the issue persists, CDN acceleration may have been enabled for OBS. In this case, go to 3.
  3. Rectify the CDN acceleration issue.

    Log in to the CDN console, temporarily disable CDN acceleration, and check whether the issue persists.

    • If the issue disappears, the cause is the acceleration domain name configured for the OBS bucket. In this case, configure a custom HTTP header on the Advanced Settings tab page of the CDN acceleration domain name.
    • If the issue persists, go to 4.
  4. Submit a service ticket to contact technical support.

What Do I Do If the Browser Displays Error "The 'Access-Control-Allow-Origin' Header Has a Value '...' That Is Not Equal to the Supplied Origin"?

This error indicates that the OBS server returned the Access-Control-Allow-Origin header, but its value does not match the origin of the current cross-origin request. The possible cause is incorrect browser caching. When multiple CORS rules are configured for a bucket to support multiple websites, the browser or CDN may cache the Origin header from another website.

Solution: Clear the browser cache and access the page again.

What Do I Do If Error "The Value of the 'Access-Control-Allow-Origin' Header Must Not Be the Wildcard '*' When Credentials Mode Is 'include'" Is Displayed in the Browser?

This error indicates that the frontend JavaScript code sends a request with Access-Control-Allow-Credentials: true, but the CORS rule uses the wildcard (*) for Allowed Origin. For security reasons, browsers do not allow the wildcard when credential information is included.

Solution:

  • If credential information must be retained, set Allowed Origin to a specific domain name and add Access-Control-Allow-Credentials: true to Allowed Header.
  • If credential information is not required, set xhr.withCredentials to false in the frontend JavaScript code and ensure that Access-Control-Allow-Credentials: false is added to Allowed Header or omitted entirely.

Setting Access-Control-Allow-Credentials to true may expose user credentials and increase security risks. Avoid setting this header to true unless necessary.

How Do I Improve the Cross-Origin Access Speed of OBS?

OBS cross-origin access speed depends on the physical link between the client and the OBS bucket. If they are geographically distant, you are advised to configure an acceleration domain name for the bucket to improve the access speed. For details, see Accessing a Bucket Using a CDN Acceleration Domain Name.

After enabling CDN acceleration, you are advised to enable Include Vary: Origin in Headers in the CORS rule. This header instructs intermediate caches such as CDN to differentiate cached versions based on the Origin header, preventing cache conflicts during multi-origin access.

Parent Topic: Data Security