In computing, the same origin policy is an important security concept for a number of browser-side programming languages, such as JavaScript. The term origin is defined using the domain name, protocol, and port number of the HTML document running the script. It has always been possible for the browser to make cross origin requests by specifying a resource from a foreign domain in the IMG, SCRIPT, IFRAME tags etc. But with these requests the client-side script does not have access to the content of this resource, it can only be executed or rendered by the browser.
The same origin policy permits scripts running on pages originating from the same site to access each other’s methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites. The goal of the policy is to prevent cross-site scripting (XSS), a type of computer security vulnerability typically found in Web applications that enables attackers to inject client-side script into Web pages viewed by other users.
With the growing popularity of Ajax, a group of interrelated web development methods used on the client-side to create asynchronous web applications, the same origin policy became more and more a serious drawback. With Ajax, data is usually retrieved using the XMLHttpRequest object.
Various alternatives have been developed to circumvent the same origin security feature, for example :
- Flash or Silverlight with a crossdomain.xml policy file
- iFrame URL Technique
- JSONP (JSON with padding)
- XMLHttpRequest Level 2, which has been merged into the main XMLHttpRequest specification in December 2011
- XDomainRequest (non standard) used by IE 8
- window.location.hash hack
- Facebook cross domain communication channel
- window.postMessage() : supported by Firefox 3, Safari 4, Chrome and IE 8
With HTML 5, a new web browser technology emerged which defines ways for a web server to allow its resources be accessed by a web page from a different domain. This technology is called CORS (Cross-Origin Resource Sharing), a first working draft was published by W3C.
CORS works on a per-page access-control model. Every page has to respond with a special header, the Access-Control-Allow-Origin header to be accessible by a foreign site.In the CORS model the responsibility of Access Control is in the hands of the developers and not the server administrators. One drawback of this technology is that the Access-Control-Allow-Origin header is not yet supported by Amazon AWS S3. A lot of web designers are requesting this feature on the AWS Developer Forum.
The following list gives additional useful links to websites reporting about this topic :
- Using CORS with all (modern) browsers, by Kendo UI
- Using CORS, by Monsur Hossain – Software Engineer, Google
- Secure Cross-Domain Communication in the Browser, by msdn
- Enable cross-origin resource sharing, by enable-cors.org
- Same origin policy for JavaScript, by Mozilla Developer Network
- Backwards compatible window.postMessage(), by Josh Frazer
- Cross-Origin Resource Sharing for JSON and RAILS, by Tom Sheffler
- Introducing JSON, by Douglas Crockford
- Defining Safer JSON-P, by Kyle Simpson