Developers don't understand CORS (2019) • Hacker News Board

Re: Developers don't understand CORS (2019)

#231

Post by stymaar » Sun, Jun 21, 2026, 3:53 PM UTC

gbuk2013 wrote: post #220

stymaar wrote: post #218

Earlier quoted context omitted.

I wasn't aware of the distinction between “safe” and “idempotent”, TIL, thank you. > DELETE is not defined to be safe but it is defined to be idempotent This one puzzles me though. How can DELETE be idempotent? If the first request works then the second one should return a 404, as the key to delete doesn't exist anymore.

Response is implementation detail: a 404 on second request is one way to do it, a 202 would be another, or 200 with some sort of response to distinguish (e.g. { changed: boolean }). Idempotency just means no state mutation on subsequent request.

> 202 would be another

Then you'd return 202 on a request to delete any invalid element, which really doesn't sound right.

> 200 with some sort of response to distinguish (e.g. { changed: boolean }).

Sounds even worse, and much like APIs that returns 200 with a payload saying {error:"not found"}

Re: Developers don't understand CORS (2019)

#232

Post by default-kramer » Sun, Jun 21, 2026, 4:06 PM UTC

I understand how the Same Origin Policy protects browsers from executing malicious scripts. I also understand how the Access-Control-Allow-Origin header can be used by servers to declare additional origins as trustworthy, relaxing the SOP.

What I still don't understand is what purpose the Access-Control-Allow-Headers header serves. It doesn't seem like it improves security for the browser (and definitely not for the server). Was it included "just for completeness" by the protocol designers? See also https://stackoverflow.com/questions/17992042

Re: Developers don't understand CORS (2019)

#233

Post by mhh__ » Sun, Jun 21, 2026, 4:10 PM UTC

ghoshbishakh wrote: post #74

kittywantsbacon wrote: post #61

[flagged]

100% - although it is stunning to see since most LLMs get CORS questions right (which is surprising since they trained on all sorts of incorrect data).

They look for latent structure in the data.

Re: Developers don't understand CORS (2019)

#234

Post by paulddraper » Sun, Jun 21, 2026, 4:15 PM UTC

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…

>> This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.

> No, that does not do that.

It restricts non-zoom.us domains to CORS-safe operations.

Which sometimes includes making the request, sometimes includes reading the response content or headers.

Re: Developers don't understand CORS (2019)

#235

Post by xnx » Sun, Jun 21, 2026, 4:19 PM UTC

mattkenefick wrote: post #207

Finbel wrote: post #90

Earlier quoted context omitted.

Maybe it’s like that trick where if a thousand people guess the amount of beans in a jar almost all of them will be wrong but their average will be very close to, if not, correct.

they probably weight documentation higher

They're applying trust factors similar to PageRank.

Re: Developers don't understand CORS (2019)

#236

Post by paulddraper » Sun, Jun 21, 2026, 4:19 PM UTC

z3t4 wrote: post #121

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…

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.

It is widely assumed by users that web browsing is safe.

If a browser does not implement CORS protections (but allows cross-origin requests), then its users must have non-standard expectations about security.

Re: Developers don't understand CORS (2019)

#237

Post by paulddraper » Sun, Jun 21, 2026, 4:21 PM UTC

kittywantsbacon wrote: post #61

[flagged]

Depressing.

While CORS is not intuitive, it is understandable by RTFM.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...

Re: Developers don't understand CORS (2019)

#238

Post by xtracto » Sun, Jun 21, 2026, 4:26 PM UTC

Ha! I kind of understand (apparently not really well from reading comments) CORS and many other web dev related constructs but oftentimes choose to work around them like what the zoom people did on the article exactly for this reason:

https://news.ycombinator.com/item?id=48616086

The whole thread shows that It seems even highly technical people that supposedly know a lot about this shit get it wrong. Because the mechanics are so complex, nobody really knows how they really work. Or it is a freaking mess or chore to achieve something.

Similar to just making a website HTTPS... even with let's encrypt and certbot , why does making a site https have to be so hard? (Try it on a service within a vpn).

Re: Developers don't understand CORS (2019)

#239

Post by paulddraper » Sun, Jun 21, 2026, 4:27 PM UTC

encomiast wrote: post #7

It's not just CORS that's hard to understand. Many (most?) developers don't really understand the threat model. And even when it's explained it hard to see why it's a big deal. Part of this is that backend developers usually have to configure CORS and it's not an access privilege protection. From the point of view of the backend it doesn't seem to matter. Bad guys can't get it. From the point of view of the front-end…

> Many (most?) developers don't really understand the threat model.

It’s because CORS builds on a very odd base permission model. So if you use multipart form data, okay. But application JavaScript bad.

Re: Developers don't understand CORS (2019)

#240

Post by paulddraper » Sun, Jun 21, 2026, 4:29 PM UTC

webstrand wrote: post #47

ctidd wrote: post #34

Earlier quoted context omitted.

All CORS does is allow for selective loosening of anti-CSRF controls. CORS is a mechanism for a service to tell a client “I’m CSRF-resistant” so that that the client doesn’t need to protect its user as tightly when interacting with that service.

Isn't CSRF about forging mutating requests? CORS doesn't block the underlying GET/POST request, the request still goes through and the server still needs to properly implement CSRF prevention. CORS just prevents javascript from reading the response. CORS _additionally_ requires OPTIONS pre-flight to succeed, before allowing any kind of request outside of what can be achieved with a HTML form submit action. So it bloc…

> CORS doesn't block the underlying GET/POST request

It does block ALL requests for certain content types.

In the common cross origin case of a JSON API, CSRF beyond CORS is unnecessary.