Question

Can someone help me to better understand the Same Origin Policy. I’ve seen several websites describing it but I’m looking for an explanation much more simple, how would you describe it to a kid?

This link seems to do the best job that I’ve found. Can anyone expand? Can someone explain why this policy exists?

Answer 1

Same-origin policy is needed to prevent CSRF. Imagine this scenario:

1. Bank manager Joe Fatcat has an account on his bank’s administrative backend. This account lets him access confidential account info for anyone who banks at TBtF Bank. He can even reset someone’s pin number, transfer funds, change account ownership, etc.
2. Now, TBtF Bank lays off Jack the IT Guy. Now he’s Jack the Digruntled Ex-IT-Guy, and he wants to take revenge on his former employer. Jack doesn’t have access to the bank’s administrative backend, but he knows Joe does.
3. So Jack sends his boss an email with a link to a page Jack created. On the page, there’s some JavaScript like:

var xhr = new XMLHttpRequest(),
    data = "from="+victimAccount
           + "&to="+jacksAccount
           + "&amt=a+gazillion+dollars";
xhr.open("POST", "http://tbtfbank.tld/accounts/wiretransfer.aspx", true);
xhr.send(data);

3. The next day, Joe arrives at his office and logs into his administrative account as he always does and leaves the tab open in the background.
4. Joe sees an email containing links to pictures of Natalie Portman covered in hot grits. So naturally he clicks on it, opening the malicious webpage.
5. The browser runs the JavaScript on the page and makes an AJAX POST request to TBtF Bank’s administrative backend site. Because Joe is already logged into the site and has an active session, the bank application accepts the command and wires a gazillion dollars to Jack’s offshore bank account.

And Jack could have just as easily used the same technique to harvest thousands of account numbers and pins or any other information Joe the bank manager has access to via his account.

Luckily, the same-origin policy protects us from these types of attacks most of the time, since Jack’s malicious page is hosted on a different domain from the bank application, it’s not allowed to make XHRs to the bank application. Though the malicious page could still contain an image that makes a GET request to the bank application, so it’s important that actions with side effects are not initiated via GET requests and that applications check the referrer header of requests they receive and take advantage of anti-CSRF tokens.