Key words: Same-origin policy, CSP, Cross-document Messaging API, WebSocket Origin, JSONP, CORS (Coress-orgin Resource Sharing)

Browser security can be divided into three chunks – Web page security, browser network security and browser system security.

Same-origin policy: Two urls are said to be same-origin if they share the same protocol, domain name, and port. Specifically, the same origin policy is mainly manifested in DOM, Web data and network.

  1. The DOM level. The same origin policy restricts how JavaScript scripts from different sources can read and write to the current DOM object.
  2. The same-origin policy prevents sites from accessing data such as cookies, IndexDB, and LocalStorage of the current site.
  3. Network layer. The same origin policy restricts the sending of data from a site to a site from a different source using XMLHttpRequest, Fetch, and so on.

Security and convenience trade-offs

  1. Third party resources can be embedded in the page

Sometimes pages need to import resources from different sources, but this can be a security issue. The idea behind CSP is to let the server decide what resources the browser can load and whether the browser can execute inline JavaScript code.

  1. Cross-domain resource sharing and cross-document messaging mechanisms

By default, the same origin policy prevents XMLHTTPREQUEST from making requests to the web site, which can greatly limit our productivity. To solve this problem, cross-origin Resource Sharing (CORS) is introduced

If two pages are not homologous, you cannot manipulate the DOM with each other. However, in practical applications, it is often necessary to communicate between the DOM of two different sources, so the browser introduced the cross-document message mechanism, which can communicate with the DOM of different sources through the JavaScript interface of window.postMessage.

The particularity of Cookie in the same-origin policy

A Cookie is a small piece of information written by a server to a browser that can only be shared by web pages of the same origin. However, the two web pages have the same level 1 domain but different level 2 domain names, and browsers allow document.domain to share cookies.

For example, if web page A is w1.example.com/a.html and web page B is w2.example.com/b.html, both pages can share cookies as long as the same document.domain is set.

document.domain = ‘example.com’;

When setting cookies, the server can specify the domain name of the Cookie as the level-1 domain name, for example,.example.com.

Set-Cookie: key=value; domain=.example.com; path=/

In this case, the second level domain and the third level domain can read this Cookie without setting anything.

For sites with completely different sources, there are currently three approaches to cross domain window communication.

Fragment Identifier (Hash)window.name Cross-document communication API (Cross-documentMessaging)Copy the code

A fragment identifier is the part of a URL after the #, such as example.com/x.html#frag… If you just change the fragment identifier, the page does not refresh. The parent window can write information to the fragment identifier of the child window. The child window is notified by listening for the Hashchange event.

The window object has a new window.postMessage method that allows cross-window communication, regardless of whether the two Windows are identical or not. For example, the parent window aaa.com sends a message to the child window http://bbb.com by calling the postMessage method.

var popup = window.open('http://bbb.com'.'title');
popup.postMessage('Hello World! '.'http://bbb.com');
Copy the code

The first argument to the postMessage method is the specific message content, and the second argument is the origin of the window that received the message, i.e. “protocol + domain + port”. You can also set this parameter to *, which indicates that the domain name is not limited and the message is sent to all Windows.

window.opener.postMessage('Nice to see you'.'http://aaa.com');
Copy the code

Both parent and child Windows can listen for messages from each other through message events.

window.addEventListener('message'.function(e) {
  console.log(e.data);
},false);
Copy the code

The event object for the Message event provides the following three properties.

Event. source: indicates the window for sending messages. Event. Origin: indicates the website for sending messagesCopy the code

To break Ajax’s same-origin policy, there are three methods: JSONP, WebSocket, and CORS:

WebSocket is a communication protocol that prefixes ws:// (unencrypted) and WSS :// (encrypted). This protocol does not enforce the same origin policy and can be used for cross-source communication as long as the server supports it.

Here is an example of a WebSocket request header sent by the browser

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
Copy the code

In the code above, one of the fields is Origin, indicating the Origin of the request, i.e. the domain name from which it originated. It is because of the Origin field that WebSocket does not implement the same Origin policy. Because the server can determine whether to allow the communication based on this field. If the domain name is whitelisted, the server responds as follows.

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
Copy the code

Reference: www.ruanyifeng.com/blog/2016/0… Time.geekbang.org/column/arti…