Live data from Hacker News

Developers don't understand CORS (2019)

fosterelli.co

121–130 of 285 posts

Re: Developers don't understand CORS (2019)

#121
post #39

Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly: > The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us . This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver. No, that does not do that. JavaScript from any other website can still talk to lo…

Importantly it only prevents clients that actually cares about the cors headers. Like ohh I'm from hacker.org and the http headers says it only allows zoom.us ohh nooooo. Like it's just a http header! Now if you use a mainstream browsers and you accidentally visits hacker.org in a iframe at some shady site - then the cors header will prevent your browser from accessing it.

Re: Developers don't understand CORS (2019)

#122
post #101

Earlier quoted context omitted.

But it isn't the 90s anymore. Billions of people are using the internet, doing everything from voting to shopping to managing their stock portfolio. There are valid reasons why we have security protocols. And aside from that - it's not like CORS is preventing you from anything. The only requirement is to read up on it, understand it, and configure your web server accordingly. If you're unable to do that, or you'd rat…

I don't care about my server. It has everything to do with what it is preventing my browser client from doing. The whole point is using content from the whole web not my server.

You can do whatever you want with your browser client. You just cannot create a website that will make the browser clients of other people send authenticated requests from JavaScript to my site if I don’t want that.

Re: Developers don't understand CORS (2019)

#124
post #83

Earlier quoted context omitted.

No, it's exactly the other way around. The SOP protects you from these security issues. CORS is a feature that can be used to loosen up the SOP, to allow more complex inter-application behaviour.

And now he's part of the confusing comment section lol

I fixed it, it stays relatively the same vs original explanation, just had inverted defaults I have no idea why I thought '*' was the default. Definitely impacted by the confusing comment section haha.

Re: Developers don't understand CORS (2019)

#125
post #57
post #24

> Developer's don't understand CORS Count me in!

Even the HN comments here are a sea of confusion and contradiction. It's stunning and makes me wonder whether CORS is a bad solution, or if it's solving a hard problem.

Fundamental mistake was to build web like we did.

If you can run arbitrary code that can connect to other sites and make requests there someone will do that. And those calls can do exactly what they would on site. Only place to control this is the browser. Thus moving this decision to browser. One piece we probably trust way too much.

Live is simple when you directly communicate with one "server"(address) for one thing. Communicate with more. Well you never know if those others intended you to be able to do this.

And then when also all the authentication information lives in the browser too the mess is ready... So whole thing should have been build differently from start.

Re: Developers don't understand CORS (2019)

#127
post #54
post #39

Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly: > The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us . This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver. No, that does not do that. JavaScript from any other website can still talk to lo…

I don't think you can even say CORS does that. The degree to which CORS is poorly understood (I have read numerous (often contradictory) documentation and I don't really understand it.) means that you can't rely on it being implemented properly by an unknown party, If a protocol reaches this level of widespread confusion, I think all bets are off. Even if one end of a system performs correctly, who's to say that the…

I think it still works, because the number of "client implementations" of CORS is very limited (*) - only the browsers have to implement that, and the browser devs seem to understand it well enough.

So there is only one end of the system that is confused - the servers - but at least the other end - the browsers - can mostly be trusted to implement it correctly.

(*) unless you're implementing an open proxy, but then you have bigger problems.

Re: Developers don't understand CORS (2019)

#128
post #80

Earlier quoted context omitted.

damn where are we heading?

It's astounding how willingly people give up their agency. Dystopic sci-fi novels turn out to be bogus, because nobody will rebel against the machines if it prints funny progress indicator words to the terminal

I am actually starting to believe that those stories where everything was offloaded to AI will come true. And not enough people will actually care even when pointed out... They haven't done much wrong this far...

Re: Developers don't understand CORS (2019)

#129
CORS seems to be the Offside rule of the webdev world.

I wonder if much of that misunderstanding comes from the threat model being quite unusual and not always easy to understand.

For starters, there are three parties, which all don't trust each other: The server, the browser and the JavaScript running inside the browser.

The browser is supposed to protect the server against requests from unauthorized JavaScript applications. CORS is there to mark certain requests as "authorized", while keeping the protection active for the rest.

But the entire system only works if those three components exist in the first place, as enforcement is solely relying on the browser.

Re: Developers don't understand CORS (2019)

#130

Earlier quoted context omitted.

Could you go the full mile and explain that very specific kind of attack?

Example: I post “fungame.com” on Show HN, you visit it, and in the background the JavaScript calls Facebook on your behalf (using your Facebook authentication cookie) and adds me as friend. By default such cross-domain requests from JavaScript are disallowed, but CORS allows it if the server specifically opt-in. But the check happen in the browser, since the purpose is to protect the user of the browser. There are so…

Is there a reason this has to happen client side with extra pre-flight requests? Taking your example, why couldn't Facebook's server just check the origin header and then reject all request from unapproved origins server side instead?
Post reply on HN