Setting Cross-Origin Access

Last updated: 2020-03-10 18:57:57

    One-Origin Policy

    One-origin policy is a key security mechanism for isolating potentially malicious files and restricts the way the files or scripts loaded from one origin interacts with the resources from another one. Resources with the same protocol, domain name (or IP), and port are considered to belong to one origin. The scripts in one origin only have the permissions to read or write the resources in the same origin, and cannot access the resources from other origins.

    Definition of one-origin resources

    Webpages from a single origin should have the same protocol, domain name, and port (if specified). The following table shows how to test whether a webpage belongs to the same origin as

    URL Result Reason Successful Same protocol, domain name, and port Successful Same protocol, domain name, and port Failed Different protocols (HTTPS) Failed Different ports (81) Failed Different domain names

    Cross-Origin Resource Sharing (CORS)

    Cross-Origin Resource Sharing (CORS) is also known as cross-origin access. It allows Web application servers to perform cross-origin access control to ensure secure cross-origin data transfer. Both browser and server need to support this feature before you can use it. The feature is compatible with all browsers (for IE browser, IE10 or above is required).
    The CORS communication process is automatically completed by the browser without any manual intervention. For developers, CORS communication and one-origin AJAX communication work the same way using the same code. Once the browser identifies an AJAX request for cross-origin access, it automatically adds some header information. In some cases, an additional request is made, but user will not be aware of it.
    Therefore, the key to CORS communication is server. As long as the server implements the CORS APIs, it can implement a cross-origin communication.

    CORS Use Cases

    CORS is used only when you're using a browser, because access permissions are controlled by a browser, instead of a server. You don't need to care about any cross-origin issues when using other clients.
    CORS is mainly used in uploading and downloading. You can use AJAX on browsers to access COS data and do not require user server to transfer data. For the websites using both COS and AJAX, it is recommended to use CORS for direct communication with COS.

    COS Support for CORS

    COS supports configuring CORS rules to allow or deny cross-origin requests as needed. CORS rules are configured at bucket level.
    COS authentication and if a CORS request is allowed are separate matters. In other words, CORS rules of COS are one of rules used to decide if to add CORS-related headers. It's up to the browser whether to block the request.
    All object-related APIs of COS and Multipart APIs support CORS authentication.

    When two webpages from and respectively that run on the same browser request the same cross-origin resource at the same time, if the request from arrives at the server first, the server appends the Header of Access-Control-Allow-Origin to the resource and returns it to the user at If a user then sends a request from, the browser returns the cached response to the last request to the user. If the content of the Header does not match the content required by CORS, the request fails.

    CORS Configuration Example

    The following example shows the how to configure CORS to get data from COS using AJAX. The Bucket permission used in the example is set to Public. For a bucket with private access permission, all other configuration items are the same as those for a public bucket, except that a signature needs to be appended to the request.
    The bucket used in the following example is named corstest, with an access permission of Public Read/Private Write.

    Before configuring CORS

    1. Verify whether the file can be accessed
      Upload a test.txt file to corstest. The access address of test.txt is
      Access the text file using curl, with the following address replaced with your file address:
      If "test" (the file content) is returned, the file can be accessed normally.
    2. Access the file using AJAX
      You can access the text.txt file directly using AJAX.
      (1) Write a simple HTML file by copying the following code to a local file and saving it as an HTML file, and then open it with a browser. Because no custom header is set, no preflight request is required.
      <!doctype html>
      <html lang="en">
       <meta charset="UTF-8">
      <a href="javascript:test()">Test CORS</a>
       function test() {
           var url = '';
           var xhr = new XMLHttpRequest();
 'HEAD', url);
           xhr.onload = function () {
               var headers = xhr.getAllResponseHeaders().replace(/\r\n/g, '\n');
               alert('request success, CORS allow.\n' +
                   'url: ' + url + '\n' +
                   'status: ' + xhr.status + '\n' +
                   'headers:\n' + headers);
           xhr.onerror = function () {
               alert('request error, maybe CORS error.');
      (2) Open the HTML file in the browser and click the Test CORS button to send the request. The following error occurs with the message "Access denied. No Access-Control-Allow-Origin Header found". This is because CORS has not been configured on the server.

      (3) When the access fails, enter the Header page to check the reason. You can find that the browser sent a Request with Origin, which means it is a cross-origin request.

      You can set up the webpage on the server with the address, so the Origin is

    Configuring CORS

    After identifying the reason for the failed access, you can solve the problem by configuring the bucket-related CORS. In this example, CORS is configured in the COS Console. For uncomplicated CORS settings, it is recommended to configure CORS using the console.

    1. Log in to the COS Console and go to the configuration page.

    Login COS console Click "Bucket list" to enter the relevant Bucket, click the "basic configuration" tab, and then you can find the "Cross-domain Access CORS setting item" on the drop-down page.

    2. Enable and set CORS rules

    Click "add Rule" to add the first rule. Use the loosest configuration as follows:

    The CORS configuration is composed of multiple rules, which are matched individually from top to bottom. The first matched rule will be used.

    Verify the result

    After the configuration is completed, try accessing the test.txt file again. If the result is as follows, you can request access normally.

    Troubleshooting and suggestions

    To avoid problems related to cross-origin access, you can set the least restricted CORS rule as described above to allow all cross-origin requests. If an error occurs even under this configuration, the root cause may lie in other factors than CORS.

    In addition to configuring the least restricted rule, you can configure more specific control mechanism for targeted control. For example, in this example, you can use the minimum allocation configuration as shown below to ensure successful match:

    Therefore, for most scenarios, it is recommended to use the least configuration as needed to ensure security.

    CORS Configuration Items

    CORS configuration items are as follows:


    This refers to the origin allowing cross-origin requests.

    • Multiple origins can be specified (one domain name per line).
    • A wildcard * can be used to indicate all domain names are allowed (not recommended).
    • A specific domain name can be specified, such as
    • Second-level wildcard domain names, such as http://*, are supported (only one * is allowed per line).
    • Do not leave out protocol name HTTP or HTTPS. Specify the port if it is not 80 (default).

      Request Methods

      Enumerate one or multiple allowed cross-origin request methods.
      Such as GET, PUT, POST, DELETE, and HEAD.


    Allowed cross-origin request headers;

    • Multiple origins can be specified (one domain name per line).
    • Header tends to be left out. In general cases, it is recommended to set this to "*" to allow all headers.
    • The values are case insensitive.
    • Each Header specified in Access-Control-Request-Headers must corresponds to a value in Allowed-Header.


    This is a list of headers exposed to the browser, which are the response headers that the user accesses from the application (such as Javascript's XMLHttpRequest object).

    • The configuration should be specific to the requirements of application. Etag is recommended by default.
    • Wildcard is not allowed. The headers are case insensitive, with one header per line.

    Timeout Max-Age

    This is the delay (in sec) from the moment when the browser issues a preflight request (OPTIONS request) for a specific resource until a result is returned. In general cases, you can set it to a bigger value, such as 60 seconds.
    This configuration item is optional.

    Was this page helpful?

    Was this page helpful?

    • Not at all
    • Not very helpful
    • Somewhat helpful
    • Very helpful
    • Extremely helpful
    Send Feedback