Why does the browser not throw a CORS error when trying out CSRF attack by posting through a from from different domain?

Question

I am trying out some sample code from an Auth0 blog post, Prevent Cross-Site Request Forgery (CSRF) Attacks.

There are two servers being setup, a vulnerable site at localhost:3000 and the attacker's site at localhost:4000. The attacker's site makes a POST request to the vulnerable site using a hidden form, and the vulnerable site accepts the attacker's data.

I checked the attackers POST request, and the origin and the referer headers are both localhost:4000. Since it is making a request to localhost:3000, why doesn't the browser throw a CORS error? The localhost:3000 server does not implement any kind of CORS policy.

The sample code is in the repo https://github.com/auth0-blog/csrf-sample-app.git.

Also, don't browsers give some sort of leeway to `localhost`? — Sheraff, Jun 26 '21 at 12:22
In the end, `localhost:3000` isn't a website protected by a browser, it's a server. It's the one responsible for enforcing any sort of cross-origin protection. — Sheraff, Jun 26 '21 at 12:25

score 1 · Answer 1 · answered Jun 26 '21 at 13:08

The purpose of CORS is not to increase security, but to allow new kinds of cross-origin communication. The approach in this code (cross-origin form posting) is an old kind of cross-origin request that has always been allowed by browsers, and is explicitly exempted from the newer CORS mechanisms.

Because this kind of attack has always been possible, sites have always needed CSRF protection against it. I assume that the authors of the article chose this method specifically to avoid the additional complexity of having to explain the CORS protocol.

Why does the browser not throw a CORS error when trying out CSRF attack by posting through a from from different domain?

1 Answers1