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

111–120 of 285 posts

Re: Developers don't understand CORS (2019)

#111

Post by moring »

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…

> it’s meant to protect the users from themselves

This is false. It is meant to protect users from a confused-deputy attack made by malicious websites, where that website makes a request to a "serious" API but the user has never asked for, or approved, that request.

Blaming the user for everything that happens serves nobody.

Re: Developers don't understand CORS (2019)

#112

Post by rswail »

bwblabs wrote: post #94
SahAssar wrote: post #78

Earlier quoted context omitted.

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

That's because they're badly written by people that don't understand that REST doesn't mean JSON+POST+GET.

Re: Developers don't understand CORS (2019)

#113

Post by flux3125 »

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.

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

Re: Developers don't understand CORS (2019)

#114

Post by bazoom42 »

sureglymop wrote: post #103
bazoom42 wrote: post #70

Earlier quoted context omitted.

CORS is counter intuitive. I don’t think there is a better way to solve the problem, it is just a difficult to understand problem. CORS errors occur when JavaScript in the browser attempts to call a server which is not configured to allow it. But the check is purely client-side. You can circumvent it entirely by using curl or whatever outside the browser. For example the server sends a header indicating which domains…

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 some weird exceptions to this, for example a client can always GET and POST data to another domain under certain constraints, since this have always been possible using HTML forms. So it is not obvious what is possible and what isnt.

Re: Developers don't understand CORS (2019)

#116

Post by ronbenton »

yaur wrote: post #18
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…

It’s not that hard to understand… in the cors threat model an attacker gets one your users to take an action on your site by visiting their site.

No? CORS is about preventing an unauthorized third party from _accessing_ data. That’s the meaning of “resource sharing.” If you want to prevent action-taking, there are other mechanisms. For example, using a header-based CSRF token if your auth scheme relies on cookies.

Re: Developers don't understand CORS (2019)

#117

Post by tgv »

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

I think many (most?) have preferred sources. I would weight Wikipedia and MDN higher than Snurk Grubble's blog in training, no matter what the topic.

Re: Developers don't understand CORS (2019)

#118

Post by vachina »

inigyou wrote: post #86
vachina wrote: post #46

Earlier quoted context omitted.

CORS is amazing for when you want to prevent people from (easily) stealing your bandwidth and hosting resources. Thieves have to stand up their own proxies, which makes them very easily blocked.

How's it going with AI scrapers for you

AI cant scrape my API. There’s no index for them to crawl.

Re: Developers don't understand CORS (2019)

#119

Post by xg15 »

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…

> (ignoring preflight requests for now and assuming we're talking just about "safe" Methods)

You can't ignore those because they constitute the bulk of CORS' security model.

Yes, you're technically right that CORS cannot prevent other websites from making any request to your server - this would be impossible, since the browser somehow has to get the CORS headers in the first place.

However what CORS absolutely lets you do is prevent requests to particular endpoints - and you can then design your API in such a way that the dangerous actions are only available behind those endpoints and thus make it safe.

I.e. what's missing in the TFA quote is that the server must also change the endpoint from GET to POST (in addition to setting the CORS headers) and remove the GET endpoint. Other websites would still be able to send a GET or a preflight OPTIONS request, but they wouldn't be able to send the actual POST request.

As such, Zoom's workaround had two problems: They didn't set any CORS headers, which prompted the browsers to only allow "safe", i.e. GET requests - and then put an unsafe action behind the endpoint, therefore violating the "safe" assumption. Moral of the story: Don't put actions that do something else than returning a result behind a GET request.

Re: Developers don't understand CORS (2019)

#120

Post by vachina »

trick-or-treat wrote: post #53
vachina wrote: post #46

Earlier quoted context omitted.

CORS is amazing for when you want to prevent people from (easily) stealing your bandwidth and hosting resources. Thieves have to stand up their own proxies, which makes them very easily blocked.

I think you're confused. The only thing blocked would be client side fetch. You need to find another way to protect everything else.

> The only thing blocked would be client side fetch.

Exactly what I need. My API is public I just don’t want someone other than my own website to consume it. Is it that hard to understand?

Post reply on HN