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.
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.