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

Re: Developers don't understand CORS (2019)

#91

Post by himata4113 » Sun, Jun 21, 2026, 8:47 AM UTC

StrauXX wrote: post #83

himata4113 wrote: post #76

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 yo…

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.

ah right, my own brain got jumbled from reading all the comments forgetting that cors: '*' is not the default.

Re: Developers don't understand CORS (2019)

#92

Post by utopiah » Sun, Jun 21, 2026, 8:47 AM UTC

I definitely understand CORS in theory, then when it's time to solve a CORS related error, anything goes. /s

Re: Developers don't understand CORS (2019)

#93

Post by kristiandupont » Sun, Jun 21, 2026, 8:49 AM UTC

dboreham wrote: post #10

The only thing to understand is that it does nothing useful today.

What do you mean? It's a way to mitigate a certain attack vector and as far as I can tell, it works as intended given the circumstances it was designed under.

Re: Developers don't understand CORS (2019)

#94

Post by bwblabs » Sun, Jun 21, 2026, 8:49 AM UTC

SahAssar wrote: post #78

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). P…

> Any decent webdev should not let GET/HEAD/OPTIONS modify state

> additionally PUT/DELETE should also be idempotent

Yes, but I think the majority of large web applications are not fully correct in terms of 'Safe and Idempotent Methods' (https://datatracker.ietf.org/doc/html/rfc9110#name-common-me...).

Re: Developers don't understand CORS (2019)

#95

Post by gib444 » Sun, Jun 21, 2026, 9:11 AM UTC

kittywantsbacon wrote: post #61

[flagged]

Guidelines say to edit out swipes, so your comment can be edited to just:

""

Re: Developers don't understand CORS (2019)

#96

Post by IceDane » Sun, Jun 21, 2026, 9:12 AM UTC

d--b wrote: post #52

A CORS protected endpoint tells YOUR BROWSER not to let YOU access its content if the website you’re browsing from is not whitelisted. It’s confusing because unlike most security features, it’s meant to protect the users from themselves. The risk comes from a combination of users being allowed to visit malevolent sites and browsers letting all websites do a lot of random stuff, including making 3rd party requests wit…

Like the sibling said: CORS is the relaxation of default security features. It's even in the name: Cross-Origin Resource Sharing.

Re: Developers don't understand CORS (2019)

#97

Post by Izmaki » Sun, Jun 21, 2026, 9:14 AM UTC

I don't fully understand CORS and was hoping he'd explain how it works. :(

Re: Developers don't understand CORS (2019)

#98

Post by koolala » Sun, Jun 21, 2026, 9:18 AM UTC

9dev wrote: post #75

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.

Its not? Remember the 90s? There was a beautiful time before CORS and DRM in the browser. Browsers used to be something that actually cared about allowing full client control.

Re: Developers don't understand CORS (2019)

#99

Post by rubendev » Sun, Jun 21, 2026, 9:24 AM UTC

This is really a self inflicted problem. If you host your backend on the same origin as your frontend (using a reverse proxy) you don’t need CORS at all and you can use the vanilla SOP, and strengthen it further with a strict CSP.

Re: Developers don't understand CORS (2019)

#100

Post by koolala » Sun, Jun 21, 2026, 9:25 AM UTC

IceDane wrote: post #96

d--b wrote: post #52

A CORS protected endpoint tells YOUR BROWSER not to let YOU access its content if the website you’re browsing from is not whitelisted. It’s confusing because unlike most security features, it’s meant to protect the users from themselves. The risk comes from a combination of users being allowed to visit malevolent sites and browsers letting all websites do a lot of random stuff, including making 3rd party requests wit…

Like the sibling said: CORS is the relaxation of default security features. It's even in the name: Cross-Origin Resource Sharing.

'No Sharing' is a policy on sharing. Being literal about the name misses their point.