The one-origin policy is a key security mechanism for isolating potentially malicious files. The policy restricts the way files/scripts loaded from one origin interacts with the resources from another origin. Resources with the same protocol, domain name (or IP), and port are considered to belong to the same origin. The scripts in one origin only have permissions to read/write resources in its origin, and cannot access resources from other origins.
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
||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) 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 in the same way and use 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 the user will not perceive it.
Therefore, the key to CORS communication lies in the server. As long as the server implements the CORS APIs, cross-origin communication can be implemented.
CORS is used when you're using a browser. This is because access permissions are controlled by the browser but not the server. Therefore, if you use other clients, you don't need to concern about cross-origin.
With CORS, you can use AJAX on browsers to directly access, upload, and download COS data without using your app server for data transfer. If your websites use both COS and AJAX, you are advised to use CORS for direct communication with COS.
COS supports configuring CORS rules to allow or deny cross-origin requests as needed. CORS rules are configured at bucket level.
COS authentication and whether a CORS request is allowed are independent. In other words, CORS rules of COS are only used to decide whether 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 (
www.b.com) running on the same browser request the same cross-origin resource at the same time, if the request from
www.a.comarrives at the server first, the server will return the resource to the user of
www.b.comsends a request later, the browser will return the cached response of the last request to the user. In this case, the header content does not match the CORS-required content, leading to the
The following example shows 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, a signature needs to be added in the request, and other configurations are the same.
The bucket used in the following example is named
corstest, with the access permission of public read/private write.
Verify whether the file can be accessed
test.txt file to
corstest. The access address of
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.
Access the file using AJAX
You can access the
text.txt file directly using AJAX.
(1) Copy the following code to a local file, save it as an HTML file, and then open it with a browser. Since no custom header is set, no preflight request is required.
(2) Open the HTML file in the browser and click Test CORS 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, go to the Headers page to find out the cause. You can see that the browser sent a request with Origin specified, meaning it is a cross-origin request.
Our webpage is set up on the server whose address is
http://127.0.0.1:8081. Therefore, the Origin is
Now that you have identified the cause of the access failure, you can solve the problem by configuring the bucket-related CORS. This example configures CORS in the COS console, which is recommended for uncomplicated configurations. You can configure as follows:
The CORS configuration is made up of multiple rules, which are matched individually from top to bottom. The first matched rule will be applied.
After the configuration is completed, try accessing the
test.txt file again. If the result is as follows, the file can be accessed normally.
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 rather than CORS.
In addition to configuring the least restricted rule, you can configure a more refined rule. For example, in this example, you can use the following most restricted configuration to ensure a successful match:
Therefore, for most scenarios, you are advised to use the most restricted configuration as needed to ensure security.
CORS configuration items are as follows:
This refers to the origin allowing cross-origin requests.
http://*.abc.com, are supported. Note that each line can contain only one asterisk (*).
Enumerate one or multiple allowed cross-origin request methods.
Examples: GET, PUT, POST, DELETE, and HEAD
Allowed cross-origin request header.
*, meaning that all headers are allowed.
Access-Control-Request-Headersmust correspond to a value in
This is the time (in seconds) the browser can cache the results of a preflight request (OPTIONS request) for specific resources. In general cases, you can set it to a bigger value, for example, 60 seconds. Note that this configuration item is optional.