Hacker News Reader

Comment by zaptheimpaler | Hacker News Reader

Great article. I've never understood CORS. One thing that still doesn't make sense to me here -

the article says cross origin writes, which includes form submissions are allowed by default. Isn't that a security risk? Wouldn't the scenario of deleting your bank account be possible if the bank used a form submission instead of a POST request on the delete page?

View on HN

It used to be, and that's why web frameworks included a CSRF token with all write requests. Without the CSRF token (which a third party couldn't have), the write would be stopped.

In modern browsers, the CSRF token isn't necessary anymore as long as the cookie's SameSite policy is set to Lax (the default) or Strict. Both will stop the cookie from being sent with a third party form submission.

That's simply because of historical compatibility. What you're describing is what a basic HTML form does - and despite it representing a CSRF risk, it can't be removed. As such, it's standard practice to protect against CSRF attacks

Yeah, the thing I've never quite understood is why the CORS rules are so complex, and why there are so many exceptions. I think this article could be improved by doing a better job explaining why there are so many exceptions. E.g. form posts to cross-origin servers are allowed by default, but as another commenter pointed out, this is only for historical compatibility reasons and would be disallowed if we were creating the rules of HTML from scratch today.

This is simply because it has always been allowed. Even before JavaScript, a form could post to an arbitrary URL. So to remain backwards compatible, CORS could not disallow it.

Well yes, and that's why CSFR are still somewhat common today.

Reply on news.ycombinator.com