1) User is logged in bank.com in one tab, where everything is secured by CSRF tokens. Then he opens evil.com in another tab.

2) Javascript in evil.com might try to make a POST request to bank.com/send_money only if it knew csrf_token.

3) In order to reveal csrf_token, javascript in evil.com might try to do GET ajax call to bank.com/send_money to get the exact same html user would get by visting this page in his browser. And then read the token.

QUESTION - why the last step will fail and will it always fail?

As far as I understand, bank.com will actually respond to this request and render all the html just fine, but on the client side the browser will decide that content coming from another domain should not be accessible, therefore it fails.

If there is an iframe in evil.com to bank.com/send_money, the iframe will load all the html just fine, but again the browser will decide that this html cannot be used by javascript and it can only be viewed in iframe. Therefore JS cannot get the token and cannot make POST request.

Is it correct? Can this be fooled?

1 Answer 1


JavaScript cannot read the content of other sites due to the same-origin policy.

This is one of the most fundamental principles of web security and goes way beyond CSRF protection. Without the same-origin policy, any website could read our e-mails through our webmailer, have a look at our PayPal account, get our private information from Facebook etc. So browser vendors do put a lot of effort into preventing this.

Like with all security mechanisms, there may be bugs. And there's also a specific attack called DNS rebinding. But all in all, the same-origin policy works very well and cannot easily be defeated.

  • what if i manually copy the csrf token and then make a request? the malicious website should be able to make a request to the server right? Commented Jan 14, 2020 at 14:44
  • If YOU "manually copy the CSRF token and then make a request" - then it is not CSRF. In a way, you're copying your own token to "impersonate" yourself because that CSRF token was meant to be used by you. As clarified by @Fleche, the malicious website (evil.com) cannot read cookies & local storage and such of other domains (i.e. bank.com)
    – Monis
    Commented Jun 9 at 17:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .