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

201–210 of 285 posts

Re: Developers don't understand CORS (2019)

#201

Post by mrweasel »

confidantlake wrote: post #152
mrweasel wrote: post #62

Earlier quoted context omitted.

We had a project were the same developer wrote the frontend and backend and still managed to get CORS wrong. As the operations people we rewrote them correctly in the load balancer... well I assume correctly, at least the application now works. CORS is really hard to wrap your head around, but sadly there's also a ton of developers that not only fail understand the threat model that CORS guards against, they also don…

> they also don't understand webdevelopment in general, especially the http protocol. I find that somewhat strange, because they also can't do native application Why would that be strange? Someone who is bad at thing A is likely also bab at closely related thing B.

Okay, but these are developers that can't do frontend, can't do backend, can't do native, can't do embedded, or at least none of them very well.... so what kind of developer are they really, other than a bad one?

Re: Developers don't understand CORS (2019)

#203

Post by [deleted] »

embedding-shape wrote: post #181
Beltiras wrote: post #143

Earlier quoted context omitted.

I don't understand it. And I'm a web developer. I don't understand the documentation, I don't understand the problem it's trying to solve and I don't understand how it's going about a solution of any problem. The closest I've come to an understanding is that it's meaningless make-work for a ledger of http calls that are not giving any security.

Back in the day when I started web development, websites making their own requests after they loaded wasn't a thing. Eventually, XMLHttpRequest appeared, which let JS do HTTP requests at (page) runtime, and the whole "AJAX movement" kicked off. Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this…

[deleted]

Re: Developers don't understand CORS (2019)

#204

Post by everforward »

xg15 wrote: post #127
Lerc wrote: post #54

Earlier quoted context omitted.

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

There’s few implementations of the engine, but many implementations of rules for that engine.

I think OPs point is that many of those rule sets probably don’t do what the author intended.

I would second that, because CORS questions are common and “turn on the allow all pattern” is almost always in the top 3 suggestions.

Semi-related tangent, it annoys the hell out of me that create-react-app (and the newer incarnation) don’t come with an “allow all” CORS rule. Don’t force me to figure out which arcane setting configures CORS headers, I’m the one writing the code, I’m okay with wherever the HTTP requests are going, I’ll set up real CORS headers on nginx for prod.

Re: Developers don't understand CORS (2019)

#205

Post by mr_toad »

cyphar wrote: post #132
bazoom42 wrote: post #114

Earlier quoted context omitted.

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…

> 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. Isn't that what CSRF protections are for, not CORS? There are other (very old) ways to trick a user into doing a POST that wouldn't be blocked by CORS -- and as you say, GET and some POST requests can always be sent but you don'…

> Isn't that what CSRF protections are for, not CORS?

Without the same origin policy CSRF protections would be trivial to circumvent, since you’d be able to read the CSRF token from any page.

Re: Developers don't understand CORS (2019)

#206

Post by mr_toad »

debazel wrote: post #130
bazoom42 wrote: post #114

Earlier quoted context omitted.

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?

It’s mostly for backwards compatibility. Sites don’t always check the request origin, the browser SOP mitigates that problem on behalf of the user.

Re: Developers don't understand CORS (2019)

#207

Post by mattkenefick »

Finbel wrote: post #90
ghoshbishakh wrote: post #74

Earlier quoted context omitted.

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

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

Re: Developers don't understand CORS (2019)

#208

Post by mr_toad »

koolala wrote: post #139
inigyou wrote: post #134

Earlier quoted context omitted.

Because that would break things. You couldn't stay logged into HN without cookies. Cookies aren't just for credentials, imagine hotlinking to an image and getting a different language version because your language cookie wasn't sent.

I thought we were talking about cross origin requests. I've not encountered content worth hotlinking that can't work on first load without cookies. That seems like a slim hypothetical that doesn't justify banning the ability entirely. You don't attach cookies just to wget something from a server.

Nevertheless cookies being sent with HTTP requests was how it worked before Javascript was invented, and at the time Netscape had to work with that for compatibility reasons.

If we’d known then how the web is used now then a few things might have been done differently.

Re: Developers don't understand CORS (2019)

#209

Post by Sophira »

xg15 wrote: post #197
Sophira wrote: post #184

Earlier quoted context omitted.

> ...there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format... The browser basically never forces you into a particular format. You don't even need to do the trick with the form stuff that the sibling was talking about. Consider the following JavaScript: var xhr = new XMLHttpRequest(); var url = "http://localhost:12345/endpoint"; xhr.open("POST", url, true)…

Interesting. Is this still sent as a "safe" request though or does it trigger a preflight request etc?

If it was one of the requests that would trigger a preflight normally, then yes, it would trigger a preflight. But the code as shown doesn't do that because "multipart/form-data" is one of the allowed MIME types that can bypass these preflights.

Re: Developers don't understand CORS (2019)

#210

Post by Sophira »

RagingCactus wrote: post #199
Sophira wrote: post #184

Earlier quoted context omitted.

> ...there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format... The browser basically never forces you into a particular format. You don't even need to do the trick with the form stuff that the sibling was talking about. Consider the following JavaScript: var xhr = new XMLHttpRequest(); var url = "http://localhost:12345/endpoint"; xhr.open("POST", url, true)…

You can do that, but my understanding is you can't get the browser to attach cookies to your request in this way, while you can with forms. Do you agree?

I haven't actually investigated that (and I'm not able to do so right now), so I couldn't tell you for sure.

If that's the case, then yes, the forms method would be 'better'.

Post reply on HN