background

In an early attempt to avoid CSRF (Cross-Site Request Forgery) attacks, browsers introduced the same-origin policy mechanism. If the protocol of the two URLs, host name (domain name /IP), port number is the same, then the two URLs are considered “homologous”, belong to the same “domain”, otherwise it is considered “non-homologous”, that is, “cross-domain”. Browsers actively intercept cross-domain Ajax requests to avoid security risks.

The “same origin policy” certainly improves the security of requests, but sometimes we need to request resources under other domain names across domains, such as requesting COS API interface under business domain name, or reading the contents of files in the COS bucket for some logical processing.

The browser supports a cross-domain access verification mechanism, CORS (Cross-Origin Resource Sharing across source resources). This mechanism allows a server to tell the browser whether to block a cross-domain request by returning a specific HTTP header.

COS allows users to configure the “cross-domain access CORS” rule in the bucket to allow legitimate cross-domain requests.

The business scenario

Let’s take a look at how to configure CORS rules in COS using a blog development example.

The user is developing a blog site, so he uploads a batch of Markdown files to COS, sets custom header X-COS-META-keywords for each Markdown file to represent the keywords of the article, and sets the file permissions to public read and private write.

The front-end JS script of the website makes Ajax request to COS through the browser, reads the content and header information of the response, converts the content into HTML text, analyzes the keywords contained in X-COS-META-keywords, and then mount them to the corresponding DOM node of the page respectively. The request process is shown in the figure below:

User website address is http://example.com, Markdown files address is https://bucketname-1250000000.cos.ap-guangzhou.myqcloud.com/test.md

Obviously, this is a cross-domain request to “light” under http://example.com.

Unsurprisingly, the browser blocked the request. If you open your browser’s Console bar, you’ll see the following error:

Access to XMLHttpRequest at 'https://bucketname-1250000000.cos.ap-guangzhou.myqcloud.com/test.md'
from origin 'http://example.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

GET https://bucketname-1250000000.cos.ap-guangzhou.myqcloud.com/test.md net::ERR_FAILED

CORS cross-domain access mechanism

To solve this problem, we need to understand the browser’s CORS cross-domain access mechanism. Browsers classify CORS requests into two categories: simple requests and not-so-simple requests, which are “simple” as long as the following two conditions are met, or “non-simple.”

The request method is one of three methods:

  • HEAD
  • GET
  • POST

HTTP header information does not exceed the following fields:

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-type: Limited to three valuesapplication/x-www-form-urlencoded,multipart/form-data,text/plain

For simple requests, the browser carries the Origin header with the request, stating which “domain” the request came from, The server uses the Access-Control-Allow-Origin and Access-Control-Allow-Methods response headers to tell the browser which “domains” and “HTTP verbs” are allowed.

For non-simple requests, the browser makes a “Preflight Request” before the actual request, which is used to ask the server if cross-domain is allowed, and if it is not, the actual request is not made.

Precheck requests use the OPTIONS verb and carry the Origin, Access-Control-Request-Method, Access-Control-Request-Headers Request Headers. To declare information such as “the current domain,” “the HTTP verb used by the actual request,” and “the header that the actual request will carry.”

The server uses Access-Control-Allow-Origin and Access-Control-Allow-Methods , Access-Control-Allow-Headers, Access-Control-Allow-Credentials response Headers to tell the browser what fields are allowed, all HTTP verbs are allowed, all HTTP Headers are allowed to carry, and “Whether to carry Cookie, Authorization header, etc.”

At the same time, in order to avoid the frequent launch of cross-domain detection, the server will return Access-Control-Max-Age to declare the validity of this cross-domain detection, and the browser will cache the detection result and use the browser cache during the validity period.

A server can also tell the browser which specific response Headers are allowed to Expose to Ajax requests by returning the Access-Control-Expose-Headers header. Usually only Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, and Pragma allow exposure. Other headers require server-specific declarations.

The browser will make a judgment based on the CORS-related Headers of the precheck request response. Only when the Origin, Methods, Headers, etc. of the actual request meet the requirements will the actual request be initiated.

Configure CORS cross – domain rules in COS

With an understanding of the CORS cross-domain access mechanism, let’s look at which CORS response headers the user needs to configure.

  • Need to configureAccess-Control-Allow-OriginMust containhttp://example.com, means allowhttp://example.comCross-domain access to cosine.
  • Need to configureAccess-Control-Allow-MethodsMust containGETMethods.
  • Need to configureAccess-Control-Expose-HeadersMust include custom headersx-cos-meta-keywords, indicating that exposure of the response header is allowed.

Then the user enters the COS console, clicks into the bucket, selects “Cross-domain Access CORS Settings” from the “Security Settings” on the left, clicks Add Rule, and fills in as follows:

  • Source: fill inhttp://example.com(You can also fill it out*, which stands for all domains allowed)
  • Operation Methods: CheckGET
  • Allow-headers: Set to*Represents a request for permission to carry any header
  • Expose – Headers: addx-cos-meta-keywords

The actual filling is as shown in the figure below, and click OK.

If you try the previous cross-domain request again, you can see that the cross-domain request succeeds and returns the file contents and the custom header information.

Further, users also want to add “save article”, “delete article” and other functions on the website. In order to reduce the development cost, we recommend them to use COS-JS-SDK-V5. To avoid cross-domain problems with other subsequent requests, we recommend the following Settings:

  • Source: fill inhttp://example.com(Please fill in your domain name, including the agreement)
  • Operation Methods: CheckPUT,GET,POST,DELETE,HEAD
  • Allow-headers: Set to*Represents a request for permission to carry any header
  • Expose – Headers: addETag.x-cos-request-idHeaders to ensure that the SDK can read the required headers
  • Timeout max-age: Set to 600 to let the browser cache cross-domain detection results, with an expiration time of 600 seconds

Configure CORS rules on the CDN

If CDN service is opened and COS is set as the source station of CDN, CDN will cache the response result of COS, including the header of cross-domain response. When accessing files on COS via CDN domain name, if you want to respond to a newly configured cross-domain Header, you can set the CORS-related cross-domain Header in the “Response Header Configuration” of the CDN console, as shown in the figure below:

As you can see, the cross-domain request CDN accelerates the success of the resource under the domain name, and the response of the cross-domain header is consistent with the configuration of the CDN console.

conclusion

This paper introduces the cross-domain access mechanism of CORS and how to configure the cross-domain rules on COS and CDN through the development of blog website and the scenario of the browser taking the initiative to intercept cross-domain Ajax requests.

In addition, the CORS cross-domain mechanism of object storage COS can configure multiple cross-domain access rules based on the bucket, allowing the Web application server to carry out cross-domain access control, so that cross-domain data transmission can be carried out safely, easily and without additional third-party tool operation. To meet the needs of customer Web applications that need cross-domain access to bucket resources, and help you build rich Web applications.

COS has been continuously enriching product features, helping users to more easily use objects to store COS, allowing users to focus on data content, enabling business and releasing data value.