10 cross-origin resource sharing methods

Same-origin policy

In client programming languages such as JavaScript and ActionScript, the same-source policy is a very important security concept, which has an important significance in ensuring data security. The same-origin policy specifies that scripts in different domains are isolated. scripts in one domain cannot access and operate most of the attributes and methods in another domain. So what is the same domain and what is different domain? When two domains have the same protocol (such as http), the same port (such as 80), and the same host (such as www.example.org), we can think that they are the same domain. For example, https://www.example.org, http://www.example.org: 8080, any two in the http://sub.example.org will constitute a cross-domain. The same-origin policy should also handle some special situations, such as limiting the access permissions of scripts under the file protocol. Local HTML files are opened through the file protocol in the browser. If the script can access any other files on the hard disk through the file protocol, security risks may occur, at present, IE8 still has such risks.

Cross-origin Resource Sharing is restricted by the same-origin policy. However, with the development of practices and browsers, we have gained a lot of valuable experience in cross-origin request skills. Here I divide cross-origin Resource Sharing into two types: one is one-way data requests and the other is two-way message communication. Next, I will list some common cross-origin methods. The source code of the following cross-origin instances can be obtained from here.

Unidirectional cross-domain JSONP

JSONP (JSON with Padding) is a simple and efficient cross-origin method. The script tag in HTML can load and execute JavaScript in other domains, therefore, we can dynamically load resources in other domains using script tags. For example, if I want to load the data of Domain B from the pageA page of Domain A, then in the pageB page of Domain B, I declare the data required by pageA in the form of JavaScript, then, in pageA, use the script tag to load pageB, and the script in pageB will be executed. JSONP adds a callback function. After pageB loads the function, it executes the function defined in pageA. The required data is passed to the function in the form of parameters. JSONP is easy to implement, but it also has some security risks. If a third-party script is executed at will, it can tamper with the page content and intercept sensitive data. However, JSONP is a perfect choice for both trusted Parties to transmit data.

Flash URLLoader

Flash has its own security policy. The server can use crossdomain. an xml file is used to declare which domains can be accessed by SWF files. SWF can also use APIs to determine which domains can be loaded by SWF files. When cross-origin resource access, for example, requests data from the domain www.a.com to the domain www. B .com, we can use Flash to send HTTP requests. First, modify crossdomain. xml on the domain www. B .com (usually stored in the root directory, if not manually created) and add www.a.com TO THE whitelist. Second, send HTTP requests through Flash URLLoader, and finally pass the response results to JavaScript through Flash API. Flash URLLoader is a common cross-origin solution. However, if you need to support iOS, this solution is powerless.

Access Control

Access Control is a cross-origin method that exclusive to each other. Currently, it is only supported in a few browsers. These browsers can send a cross-origin HTTP Request (Firefox, Google Chrome, etc. through XMLHTTPRequest, in IE8), the request response must contain an HTTP Response Header of Access-Control-Allow-Origin, which declares the Access permission of the Request domain. For example, if www.a.com sends a cross-origin HTTP request to asset. php under www. B .com, the following response header must be added to asset. php:

header("Access-Control-Allow-Origin: http://www.a.com");

 

Window. name

The name attribute of the window object is a very special attribute. When the location of the window changes and is reloaded, its name attribute can remain unchanged. In this case, we can use iframe to load page B of other domains in page A, while in page B, we use JavaScript to assign the data to window. after name and iframe are loaded, page A modifies the iframe address and changes it to an address in the same domain. Then the window can be read. the value of name. This method is suitable for one-way data requests, and the protocol is simple and secure. External scripts are not executed without restrictions like JSONP.

Server proxy

When the data provider does not support the JSONP protocol or the window. name protocol or has no access permission to other domains, we can capture data through the server proxy. For example, when a user requests the resource file asset.txt under www.a.com, an ajaxrequest directed to www. B .com/asset.txtwill be blocked by the browser. At this time, we configure a proxy under www.a.com, and then bind the ajax request to this proxy path, such as www.a.com/proxy/. Then the proxy sends an HTTP request to asset.txt under www. B .com. cross-origin HTTP requests are made on the server, the client does not generate cross-origin ajax requests. This cross-origin method does not need to sign agreements with the target resource and is aggressive. In addition, it should be noted that the proxy should be protected to a certain extent in practice, such as limiting the use or frequency of others.

Bidirectional cross-Origin document. domain

By modifying the domain attribute of the document, we can communicate between the domain and the subdomain or different subdomains. The same domain policy assumes that the domain and subdomain belong to different domains. For example, www.a.com and sub.a.com are different domains. At this time, we cannot call the JavaScript method defined in sub.a.com on the page under www.a.com. But when we change the domain attribute of their document to a.com, the browser will think that they are in the same domain, then we can call each other's method to communicate with each other.

FIM-Fragment Identitier Messaging

JavaScript can only perform limited access and operations between different domains. In fact, we can use these limited access permissions to achieve cross-origin communication. FIM (Fragment Identitier Messaging) was invented on this premise. The parent window can perform URL reading and writing on iframe, and iframe can also read and write the URL of the parent window. A part of the URL is called frag, which is the # and its subsequent characters. It is generally used for browser anchor location, the Server does not care about this part. It should be said that the HTTP request process will not carry frag, so this part of modification will not generate HTTP requests, but will generate browser history records. The FIM principle is to change the URL's frag for bidirectional communication. Each window sends messages by changing the location of other windows, and listens for changes in its own URL to receive messages. This communication method may cause unnecessary browser history records. In addition, some browsers do not support the onhashchange event. You need to poll the changes to the URL. Finally, the URL has a length limit in the browser, this restricts the amount of data transferred each time.

Flash LocalConnection

Two-way communication on the page can also be solved through Flash. The Flash API has the LocalConnection class, which allows two SWF to communicate through the process, at this time, SWF can be played in an independent Flash Player or AIR, or embedded in an HTML page or PDF. Following this communication principle, we can nest a SWF on the HTML pages of different domains to transfer data to each other. SWF exchange data quickly through LocalConnection, but each time the data volume has a size limit of 40 kb. Cross-origin communication using this method is too complex and requires two SWF files, which is not practical.

Window. postMessage

Window. postMessage is a new method defined in html5. this method can easily communicate across windows. Because it is a new method, it cannot be used in both old and old browsers.

Cross Frame

Cross Frame is a variant of FIM. It uses a blank iframe to generate no excessive browser history or change the URL, the availability and performance have been greatly improved. When sending a message in response, a hidden iframe will be created on the page. The srcof iframedirects to proxyb.html and uses the message as the URL response to obtain the iframe URL, parse the message, and remove the iframe. When B .html#sends a message to a.html, the principle is the same. Cross Frame is a good two-way communication method and is safe and efficient, but it cannot be used in Opera. However, in Opera, we can use a simpler window. postMessage instead.

Summary

There are many cross-origin methods. We can find the most suitable solution for different application scenarios. For example, for one-way data requests, we should prioritize JSONP or window. name, two-way communication we adopt Cross Frame. We can also use server proxy to capture data without reaching a communication protocol with the data provider.

Source: http://ued.koubei.com /? P = 1291