Hacker News Reader

Comment by ravenstine | Hacker News Reader

> rather than just enforcing access itself.

Could you elaborate on that? I can't picture the alternative you're suggesting.

Same here... from what I can tell, only the browser has reliable information about what's happening. How could the server know code from another domain is making the requests? And if anything, the web is more secure - desktop native applications can usually access each other's data and do malicious requests to remote servers using stolen credentials just fine.

Via the Origin header, just like the preflight requests use. The server is ultimately the one telling the browser what the rules are already. The reason a preflight is needed is so that there is effectively a default deny policy, since both historically and even today you can’t assume all APIs that accept authentication tokens from the browser take into account any kind of cross origin access.

Even still, a lot of people just put ‘Access-Control-Allow-Origin: *’ on everything as soon as they run into an issue, so that rule has to ban credentialed requests altogether.

You are talking about the Origin header set by the browser that you don't trust?

The whole point of CORS is that you trust the browser to do the preflight requests and obey them, otherwise it doesn’t do anything. If you have access to the credentials (which the browser does) and the ability to send whatever HTTP requests you want, you can bypass CORS entirely.

The alternative is for the idea agent to send the Origin header on all requests.

Then the server responds with 200 or 403.

The origin could still be falsified client-side.

No, it can't be falsified by JS in the browser. CORS is only relevant for JS in the browser; it doesn't impact curl at all, for example.

This is kind of like the reports I see every so often to Django's security address, where someone demonstrates that they can CSRF their own session.

The reply is always "yes, you can CSRF yourself, because it's not supposed to protect against that; it's supposed to protect you from other people". In exactly the same way, CORS is there to protect you from other people. You can always hack your own user-agent to disregard CORS, but the only person you can harm that way is yourself.

The people with the security problem are the users of browsers, and the browser vendors have a solution to solve that problem built into the browser. If they didn’t enforce it at the browser level, the owners of the servers would have little incentive to enforce CORS and most just wouldn’t. See https adoption.

Bingo. I still kind of wish there was an ability to make the browser invoke some kind of request that servers would reject by default (e.g. with a non-standard HTTP method) that could combine the preflight check and the request while still making servers that don’t anticipate CORS blanch and not take any dangerous actions. But the browser security model is complex and messy enough as it is, so I doubt it’s worth it.

> the owners of the servers would have little incentive to enforce CORS and most just wouldn’t

Huh? They already implement authorization. (Transport security is similar but different.)

And I've seen plenty of Allow-Origin-Access-Control: * because people get frustrated with CORS, e.g. they can't allow access for *. example.org.

Then it means that a service is vulnerable by default unless it implements the list of allowed origins. With CORS if there are no headers then it means no authorization.

Using HMAC or API keys.

Reply on news.ycombinator.com