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.
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 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 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 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
www.b.comrespectively that run 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 appends the Header of Access-Control-Allow-Origin to the resource and returns it to the user at
www.a.com. If a user then sends a request from
www.b.com, 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
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.
If "test" (the file content) is returned, the file can be accessed normally.
(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.
You can set up the webpage on the server with the address
http://127.0.0.1:8081, so the Origin is
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.
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.
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.
After the configuration is completed, try accessing the test.txt file again. If the result is as follows, you can request access 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 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 are as follows:
This refers to the origin allowing cross-origin requests.
*can be used to indicate all domain names are allowed (not recommended).
http://*.abc.com, are supported (only one
*is allowed per line).
Allowed cross-origin request headers;
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.