I. What is the browser cross-domain limitation? What is the essence?
The so-called cross-Domain browser restrictions, in fact, for data security considerations by Netscape to limit the browser cross-domain access to data policy, this is a convention, formally known as the browser homology policy, is currently supported in most browsers.
In essence, the so-called browser-like policy is: Do not allow the browser to access cross-domain Cookie,ajax cross-domain interface, etc. In other words, browsers are not allowed to access data or interfaces that are not in the same domain as themselves. The most common example: for Web projects that are completely detached from the front and back ends, the following issues occur when the Frontend page accesses data through the rest interface:
- Send POST request is not allowed: The options request is sent before the POST request is sent, and the HTTP response status code is 403 (Forbidden). At the same time, in the browser (Firefox debugging) console can see the following prompt:
Cross-origin requests have been intercepted: the same origin policy prohibits reading remote resources located in Http://host:port/path. (Reason: CORS header is missing ' Access-control-allow-origin ').
- Allow a GET request to be sent: HTTP response status code is 200, but the data returned by the server cannot be read. At the same time, in the browser (Firefox debugging) console can see the following prompt:
Cross-origin requests have been intercepted: the same origin policy prohibits reading remote resources located in Http://host:port/path. (Reason: CORS header is missing ' Access-control-allow-origin ').
For a URL, the so-called "homologous" contains 3 elements: the same protocol, the host (domain name or IP address, IP address is the root domain name) the same, the same port. For example, for the address "http://test.chench.org/page.html", the following conditions are considered to be homologous and non-homologous:
URL |
Results |
cause |
Description |
Http://test.chench.org/page2.html |
Homologous |
Same protocol, same host, same port |
|
Http://test.chench.org/dir2/page.html |
Homologous |
Same protocol, same host, same port |
Different directories under the same domain name |
Http://102.12.34.123/page.html |
Different sources |
Host different |
Domain and domain name corresponding IP also not homologous |
Http://test2.chench.org/page.html |
Different sources |
Primary domain name is the same, sub domain name is different |
|
Http://chench.org/page.html |
Different sources |
Domain names are different |
Same level domain name, different level two domain name |
Http://test.chench.org:81/page.html |
Different sources |
Different ports |
Same domain name, different ports |
Https://test.chench.org/page.html |
Different sources |
Different protocols |
Same domain name, different protocols |
Http://blog.icehoney.me/page.html |
Different sources |
Host different |
Different domain names |
Two. Why are there browser cross-domain restrictions?
Now that there are cross-domain restrictions in mainstream browsers, why must there be this limitation? What happens if there are no cross-domain restrictions? First of all, the browser homologous strategy is proposed to avoid the problem of data security, namely: 限制来自不同源的“document”或脚本,对当前“document”读取或设置某些属性
. If there is no such limit, what will happen? Consider a few scenarios:
- A JavaScript script that might be a.com can also alter B.Com's page (in the browser's display) at will when B.Com has never loaded the script.
- In the browser to open an e-commerce website (domain name is b.com), while opening another website (a.com), then under the A.com domain name script can read B.Com cookie data, if the cookie contains privacy data, the consequences are unthinkable.
- Because you can freely read the cookie data under any domain name, it is easy to launch a CSRFG attack.
Therefore, the browser's same-origin policy is the basis of browser security, the same-origin policy once the vulnerability is bypassed, will also have very serious consequences, many of the security schemes based on the same-origin policy will lose effect.
Three. What resources (Operations) are restricted by the same-origin policy for browsers?
For browsers, some third-party plug-ins that are loaded by browsers have their own homologous policies in addition to the dom,cookie,xmlhttprequest, which is subject to the same-origin policy. Some of the most common plugins, such as Flash,java applet,silverlight,google gears, have their own control strategy. In addition, data stored in the browser, such as Localstorage and INDEXEDDB, is segmented with the source. Each source has its own separate storage space, and JavaScript scripts in one source cannot read and write to data belonging to other sources.
Four. What is the problem with browser cross-domain restrictions?
With the development of the Internet, the demand for user experience is more and more high, AJAX applications are becoming more frequent, the essence of Ajax is XMLHttpRequest. However, XMLHttpRequest is constrained by the same-origin policy, so resources cannot be accessed across domains.
Five. What are the ways to resolve browser cross-domain limitations? How to choose the right solution? 1. JSONP
In the browser,,,, and so on, <script>
<iframe>
<link>
tags can load resources across domains, regardless of the same-origin policy. Each time the label with the "src" attribute is loaded, a GET request is actually initiated by the browser. Unlike XMLHttpRequest, a resource loaded through the SRC attribute, the browser restricts the permissions of the JavaScript so that it cannot read and write the returned content. Detailed description is as follows:
<script src="..."></script>
Tags embed cross-domain scripts. Syntax error messages can only be captured in the same-origin script.
<link rel="stylesheet" href="...">
tags embedded in CSS. Due to the loosely grammatical rules of CSS, the cross-domain of CSS requires a set of correct Content-type message headers. Different browsers have different restrictions.
Embed the picture. The supported picture formats include Png,jpeg,gif,bmp,svg,...
<video>
and <audio>
embed multimedia resources.
<object>
, <embed>
and <applet>
the plug-in.
@font-face
The imported font. Some browsers allow cross-domain fonts (ross-origin fonts), and some require homologous fonts (Same-origin fonts).
<frame>
and <iframe>
any resources that are loaded. Sites can use the X-frame-options message header to prevent this form of cross-domain interaction.
JSONP is the use of this feature, you can load the corresponding resources, and indirectly bypass the browser of the same-origin policy restrictions. Specifically, it is the client that dynamically creates the JavaScript tag, sets the SRC attribute on the tag, passes the function name for the callback in the access request parameter, and the service side responds to the JSONP request with the data as the client callback function parameter specified by the request parameter as the return value. In this way, the server's response data to the client is actually the parameter of the callback function, which is the Javascipt object instead of the string, thus avoiding the steps of using Json.parse.
2. CORS (cross-origin Resource sharing)
Cors is a universal standard, with the name "cross-domain resource sharing" (cross-origin resource sharing). It allows the browser to issue XMLHttpRequest requests to cross-origin servers, overcoming the limitation that Ajax can only be used by origin. Specifically, depending on the cors standard definition, the server needs to include the specified message header in the browser's cross-domain request response, and the browser determines whether the cross-domain resource can be accessed based on the response message.
3. WebSocket
WebSocket is a communication protocol that uses ws://(non-encryption) and wss://(encryption) as the protocol prefix. This protocol does not implement the same-origin policy, as long as the server support, you can cross-source communication through it.
4. Summary of the workaround
Programme |
Advantages |
Disadvantages |
Jsonp |
Simple and practical, the old browser all support, server transformation is very small. |
Only get requests are supported, other types of HTTP requests such as Post are not supported, and javasript call issues between cross-domain pages cannot be resolved |
CORS |
The standard is the fundamental solution to cross-source AJAX requests, allowing any type of request. |
|
WebSocket |
Not affected by browser-origin policies |
Requires a service-side support agreement, browser support WebSocket, not all browsers support WebSocket. |
Reference
https://github.com/acgotaku/WebSecurity/blob/master/docs/content/Browser_Security/Same-Origin-Policy.md Basic introduction of homologous strategyHttps://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy Browser-Origin policyhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Access_Control_CORS HTTP Access Control ( CORS) http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html Browser homologous policy and its avoidance methodhttps://www.zhihu.com/question/25427931 How do you understand the same-origin strategy for browsers? http://www.cnblogs.com/rainman/archive/2011/02/20/1959325.html#m1 JavaScript Cross-domain Summary and solutionhttps://www.zhihu.com/question/26379635 Why does the browser want to restrict cross-domain access?
Resolve browser cross-domain restrictions on sending AJAX requests