Cross-origin resource sharing

Last Updated: Nov 28, 2016

Cross-origin access, or the cross-origin of JavaScript, is a browser restriction set for the sake of security, namely, the same-origin policy. When Website A tries to use the JavaScript code in its webpage to access Website B, the attempt will be rejected by the browser because A and B are two websites of different origins.

Cross-origin access needs arise frequently in actual usage, such as when OSS is used at the back end for the user’s website www.a.com.The upload function implemented with JavaScript is provided in the webpage. However, requests could only be sent to www.a.com in the webpage, and all the requests sent to other websites are rejected by the browser. Thus the data uploaded by users has to be relayed to other sites via www.a.com.If cross-origin access is set, users could upload their data directly to OSS instead of relaying it via www.a.com.

Cross-origin resource sharing (CORS) is the standard across-origin solution provided by HTML5. Currently, the CORS standard is supported by OSS for cross-origin access. For details about the specific CORS rules, refer to W3C CORS Norms. In simple terms, CORS indicates the origin of where the request is originated by using a header containing the origin of the HTTP request. As in the previous example, the origin header contains www.a.com.After receiving the request, the server will judge based on certain rules whether the request should be accepted or not. If yes, the server will attach the Access-Control-Allow-Origin header in the response. The header contains www.a.com, indicating that cross-origin access is allowed. In case that the server accepts all the cross-origin requests, just set the Access-Control-Allow-Origin header to *. The browser will determine whether the cross-origin request is successful or not based on whether the corresponding header has been returned or not. In case that no corresponding header is attached, the browser will block the request. In case that the request is not a simple one, the browser will firstly send an OPTIONS request to obtain the CORS configuration of the server. In case that the server does not support the following operations, the browser will also block the following requests.

OSS provides the configuration of the CORS rule, accepting or rejecting corresponding cross-origin requests as needed. The rule is configured at the bucket level. The details are available in PutBucketCORS.

Key points

  • Attaching relevant CORS headers and other actions are automatically executed by the browser, and no additional action is required by the user. Only in the browser environment could the CORS operations be meaningful.
  • Whether a CORS request is accepted is completely independent of OSS authentication and other such measures, i.e. the OSS CORS rule is only used to determine whether to attach the relevant CORS headers. Whether the request should be blocked should be exclusively determined by the browser.
  • When using cross-origin requests, make sure the browser’s cache function is enabled. For example, the same cross-origin resource have been requested by two webpages running on the same browser (originated from www.a.com and www.b.com) at the same time respectively. If the request of www.a.com is received by the server in the first place, the server will return to the user the resource with the Access-Control-Allow-Origin header “www.a.com”. When www.b.com initiates its request, the browser will return its previous cached request to the user. As the header content does not match the CORS request, the subsequent request fails.

Reference for using the function

Thank you! We've received your feedback.