Hacker News Reader

Comment by why-el | Hacker News Reader

That's certainly true, you are making the leap of faith that your customers are running standard compliant browsers, which, all considered, is true. All the techniques you mention require you to break either the customers or some element along the network chain to the server, and once you do, well, CORS is the least of your problems.

View on HN

Yes. CORS is not so much a protection of your site against malicious user-agents;

It is a protection of your site's users, using good non-malicious browsers, against malicious other JS on the web.

I think this is one of the most basic misunderstood things about CORS.

Once you understand that, you can start actually trying to understand the threat model... which is still pretty confusing, to me anyway. But until you are there, you haven't even started.

If a native app can request any resource why shouldn't a web app be able to do that too? Does it matter whether that app runs in my browser, Electron (which can easily bypass CORS policies) or whatever other runtime? If it does then CORS restrictions should be put in place at the OS level, if it doesn't they should be removed altogether. There are a ton of other ways to make sure you don't "give your stuff" to unauthorized parties: authentication, CRSF tokens, hash validation.

Seriously, if it gets to the point of having to write "{Class of professionals} don't understand {Obscure restriction that doesn't make much sense nowadays}" it's likely not a security issue anymore, it's a UX issue (with the developers being the users). At the very least prompt the user to (dis)allow CORS when a request is being made, similarly to how the user is warned when running an unsigned executable on macOS.

A web browser is different than a native app, because simply clicking a link can execute code from an untrusted party.

First of all, when you are using a web browser, if it wasn't for cross-browser request restrictions, code executing on one site (or web app) would be able to _use credentials stored in cookies_ by another site altogether. Because all these web apps exist in the same browser context. Native apps are all separate, code running in an Native App A can't say "make a request to facebook using the credentials the user already logged into in the facebook app." But Web App A could do exactly that with the credentials the user logged into on facebook.com -- if it wasn't for cross-browser request restrictions. Which then CORS let some sites carefully opt out of.

Secondly, when you download an app, you are trusting the developers of that app.

You navigate the web, you are trusting every single site you visit (to also not have their own code injection or other vulnerabilities to which web pages/apps are particularly vulnerable to), and most users have no idea what sites they are visiting, they are just clicking links.

What we really need a more clear explanation of the CORS threat model, with examples. I think we'd all be more clear about what it's for and why we need it if we understood it better.

It is definitely a developer UX issue, but it is sadly one that is baked into the web for legacy reasons.

Reply on news.ycombinator.com