Hacker News new | past | comments | ask | show | jobs | submit login

> And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself.

That's a typical misunderstanding of purpose of CORS. Regardless of your website setting or not setting CORS, an attacker with a modified browser or a custom browser can ignore it. That's not what CORS protects from - CORS protects against a non-modified browser uased by Joe Random User installed via a factory/distribution path being tricked into doing something against the site policy, therefore exposing the user.

I don't misunderstand.

My beef with CORS is that I have to encoded the validation logic into its HTTP headers.

But maybe what I want doesn't fit in its headers, e.g. I want to allow requests from *.example.org. So then I am writing server code, and if I am writing server code anyway, why have the extra step of encoding validation logic in CORS headers in the first place?

You are still thinking about a server checking if a browser is trusted to run some code on a server, when the CORS is about a browser deciding if it should trust some of the server response.

Surely you can implement your security rules this way. But for most people CORS are a cheaper way to enable cross origin requests. And clueless people are stuck with same origin policy which secure by default.

> CORS are a cheaper way to enable cross origin requests

Is it really that much more expensive to check the Origin header than to check the Authorization and Cookie headers?

If your server can handle Origin checks that way, then leave your CORS headers wide open and problem solved.

The problem is that existing servers don’t generally check origin headers, so browsers needed some other mechansim to understand which requests were safe.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact