This article has participated in the third “topic writing” track of the Denver Creators Training Camp. For details, check out: Digg Project | Creators Training Camp third is ongoing, “write” to make a personal impact.

Let’s take a look at what happens when a cross-domain request is made. As shown in the figure above, I launched an interface on baidu’s home page to get a list of gold digging articles. The request failed and the console reported an error. Your request was blocked because of the CORS policy. What is a CORS policy? Your request is cross-site. In other words, the page site from which you initiated the request is not the same site as the target site, and only the same site request is likely to succeed. Why is this so? Imagine what would happen if different sites could request resources from each other via XMLHttpRequest. I can think of several main implications:

  • The current site can read and write the DOM object of the other site through JavaScript scripts.
  • The current site can read sensitive data such as cookies, IndexDB, and localStorage of the other site.
  • If the current site knows the API address of the other site, it can obtain the interface data of the other site.

If it is like the above description, it is terrible. Hackers or malicious sites can do a lot of bad things, such as uploading user information to their own servers and then making bogus requests, such as transferring money or deleting articles mined for gold.

We need security policies to keep our data safe, and that’s where the same origin policy for browsers comes in! So what is the same origin policy?

The same origin policy is an important security policy that restricts how an Origin document or the scripts it loads can interact with resources from another source. It can help block malicious documents and reduce the number of vectors that can be attacked.

Definition of homology:

Two urls are cognate if their protocol, port (en-us) (if specified), and host are the same. This scheme is also known as a “protocol/host/port tuple”, or simply “tuple”.

The following table gives the comparing with the URL https://juejin.cn/post/6994417198164869133 source example:

URL Whether the same why
https://juejin.cn/test homologous Only the path is different
http://juejin.cn/test Different source Different protocols
https://juejin.cn:80/post/6994417198164869133 Different source The default HTTPS port is 443
http://test.juejin.cn/test Different source Hosts (domain names) are different

To prevent this from happening, browsers require that only sites that comply with the same origin policy can make requests using XMLHttpRequest, thus ensuring data security. But is this absolutely true? Isn’t there another way to request resources across sites in a non-same-origin policy? The answer is yes! That is CORS!

CORS (Cross-Origin Resource Sharing) is a system that consists of a series of transmitted HTTP headers that determine whether the browser prevents front-end JavaScript code from getting a response to a cross-domain request.

This is a whitelist configuration that is implemented by configuring the ACCESS-Control-Allow-Origin CORS header, which indicates which domains the requested resource can be shared to. Syntax is as follows

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>
Copy the code
  • Among them*The number represents a wildcard that allows all domains to have access to resources.
  • <origin>Specify a URI that can access the resource. The other is not said, the specific configuration can refer toMDNDocumentation here.

In general, XMLHttpRequest does not allow cross-domain resource requests because of the browser’s same-origin policy, which ensures data security. However, cross-site requests can be implemented in other ways, such as CORS.