Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers don't understand CORS (2019)

fosterelli.co

Post reply on HN
Print view View original

71–80 of 285 posts

Re: Developers don't understand CORS (2019)

#71

Post by 9dev »

rusk wrote: post #66

It’s TOS for using ebdpoint. It says: access is provided under condition you respect these restrictions You are not obliged to honour this. It is not enforceable so it seems strange. Browsers enforce it, but it can be turned off and nobody expects it to be implemented by a simple REST client application. It’s a gentleman’s agreement. It’s a statement of expectation to the browser. On the one hand it may be for the pr…

> Browsers enforce it, but it can be turned off and nobody expects it to be implemented by a simple REST client application.

No, you're missing the point. Normal people using normal browsers with default settings have CORS enabled. That's the vast majority of your users; everyone who disables it stupidly opts into a risk themselves without any reason to.

So the expectation that CORS is enabled on your user's devices holds. This means it's not a gentleman's agreement!

Re: Developers don't understand CORS (2019)

#72

Post by ivanjermakov »

robertclaus wrote: post #11

I bet there's an awful lot of servers out there that will happily take CORS requests from any host because someone didn't understand why their second domain couldn't talk to the same API.

Sometimes it's a good thing when I try to use someone else's backend in my web app. For example map tile server or route builder, which are session-less and have no authentication.

The idea that HTTP servers are restricted to requests from a single domain by default is strange, wonder if CORS world be better off opt-in rather than opt-out.

Re: Developers don't understand CORS (2019)

#73

Post by RobotToaster »

Lerc wrote: post #54
muvlon wrote: 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…

It seems like nobody understands CORS.

Including me TBH.

Re: Developers don't understand CORS (2019)

#75

Post by 9dev »

koolala wrote: post #16

CORS sucks since Cross-Origin-Embedder-Policy: credentialless was never made standard across all browsers. It's a browser client restriction you can't turn off. If you want to do anything interesting with WWW content you have to run your own browser or run an out-of-box one off a proxy server that breaks everything.

> If you want to do anything interesting […] you have to run your own browser

This is usually a sign you don't really understand what you're doing.

Re: Developers don't understand CORS (2019)

#76

Post by himata4113 »

It was pretty amusing reading the comment section so I'll chime in: SOP protects you (the browser) from leaking information to websites that should not be able to access that information and CORS allows you to weaken it.

Example: SOP stops example.com from fetching the list of subscriptions on youtube.com. But CORS allows example.com to access youtube.com/public/*.

This is also not the sole use-case, it also stops your backend api being up under a different frontend which would allow data theft since you could log into real services on google.com, but you're actually on g00gle.com enabling data exfiltration because now every request can be MitM'd.

Re: Developers don't understand CORS (2019)

#77

Post by 9dev »

ralusek wrote: post #63

I understand CORS and I don't. TL;DR: It's a restriction your browser gives itself . If it's on Domain A and it sees a request going out to Domain B, unless Domain B responds saying that it's expecting traffic from Domain A, the browser prevents itself from making the call. I think the part about it that is off/silly to most people is that it's not a normal security threat model, because a malicious client could simp…

> […] the browser prevents itself from making the call.

That's not strictly correct, by the way. The request is made, but the JavaScript code on Domain A is not allowed to read the response. This matters when a request is destructive on its own, for example.

Re: Developers don't understand CORS (2019)

#78

Post by SahAssar »

muvlon wrote: 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…

> assuming we're talking just about "safe" Methods

That's a pretty big assumption. Any decent webdev should not let GET/HEAD/OPTIONS modify state (joining a meeting is changing state) and additionally PUT/DELETE should also be idempotent.

POST with JSON (or other non-form formats) api's should also have it's content-type header checked (text/plain forms can send a JSON body but the content-type will be text/plain). PUT/PATCH/DELETE and POST with a non-form content-type (application/x-www-form-urlencoded, multipart/form-data, or text/plain) will trigger a preflight so that CORS is properly checked before the actual request reaches the server.

Re: Developers don't understand CORS (2019)

#80

Post by 9dev »

sourcecodeplz wrote: post #48
rishabhpoddar wrote: post #42

I agree that CORS is hard to understand and fix. I was the CTO at an auth company and SO many of our users used to run into various CORS issues and asked questions on our support. However, I'd now argue that developers don't need to understand CORS anymore.. cause claude / gpt does! Just throw in the error in claude code / codex and it would fix it.

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
Post reply on HN