People's Newsroom


Even though the Same-Origin Policy effectively prevents execution contexts from different origins from directly influencing one another, several interaction patterns are present in the Web or are explicitly enabled. A first example is a local interaction between different execution contexts, a feature highly-demanded by mashup developers. Today, the Web Messaging specification offers an opt-in mechanism to enable controlled interaction between different execution contexts and is currently available in all modern browsers. Such controlled interaction allows different contexts to cooperate or exchange information, which in turn enables alternative architectures that isolate security-sensitive components in their own origin.

A second example consists of an implicit interaction when a page from origin A makes a request to a server located within origin B, for example, to include a script or an image from origin B. When the browser sends out such requests, it will attach any cookies that it has stored for origin B, allowing the cross-origin request to become part of the user’s session with origin B. This interaction pattern is a crucial requirement for numerous interactions on the Web, such as Facebook’s like button, which can be embedded in arbitrary pages, allowing users to like the page on their Facebook accounts by simply clicking the button. Unfortunately, as will be covered in the coming sections, this interaction pattern also lies at the basis of Cross-Site Request Forgery (CSRF) attacks. A final example of cross-origin interactions is the intricacies of explicit interactions initiated by a script running in a page’s execution context.

The traditional script-based communication mechanism uses the XMLHttpRequest object to send custom requests and was restricted to communication within the same origin. This limitation has sparked creative solutions to bypass the same-origin restriction using script tags, JSON, and “padding”. This technique, called JSON-P, dynamically includes additional JavaScript files, which will invoke a callback function in the local execution context. This effectively enables cross-origin communication, since the browser can send parameters in the request for a script file, and the server responds with the requested data. Unfortunately, this also introduces a severe security vulnerability, since the server can willingly or unwillingly inject content into the page’s execution context.

In response to this dangerous practice, the XMLHttpRequest Level 2 specification makes cross-origin communication explicitly possible by implementing the Cross-Origin Resource Sharing (CORS) specification. CORS allows servers to provide the browser with a security policy that explicitly allows certain cross-origin interactions to be sent from a local execution context. As CORS is an opt-in policy, legacy servers that are not aware of these new capabilities will not become vulnerable to new attacks. While CORS largely succeeds in this effort, some caveats still remain.

Back to top button