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

221–230 of 285 posts

Re: Developers don't understand CORS (2019)

#221

Post by Levitz »

mrweasel wrote: post #201
confidantlake wrote: post #152

Earlier quoted context omitted.

> 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?

The amount of time the average webdev spends actually consciously dealing with the intricacies of the http protocol is just very small.

Re: Developers don't understand CORS (2019)

#222

Post by sivalus »

CORS could be handled by your SRE/DevOps/Security equivalents and they will probably do it better because they more often operate while seeing the entire landscape. Feature developers are typically trying to work in a particular area at a time and lose 'peripheral vision'. Or maybe it's something to be learned at the staff/late senior level where you can get more of that perspective because you should have more freedom. The situation in this article also means this was missed by their security folks as well.

Who decided this was a developer's responsibility?

Re: Developers don't understand CORS (2019)

#223

Post by JimDabell »

stymaar wrote: post #218
JimDabell wrote: post #177

Earlier quoted context omitted.

> GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests. This is not correct. Safety and idempotency are two different concepts. Safety is when a request does not result in a state change. Idempotency is when the outcome is the same whether you make the requ…

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.

HTTP requests are not RPC calls. The end state of a DELETE request is that the resource does not exist. If you make the request once, the end result is that the resource does not exist. If you make the request twice, the end result is that the resource does not exist. The spec. allows for the actual response to differ; the important thing is that the state is the same regardless.

Re: Developers don't understand CORS (2019)

#225

Post by yallpendantools »

spl757 wrote: post #200
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…

A poorly documented, poorly implememented, and poorly understood protocol is a worthless protocol. More than that, it's a potential attack surface, and the idea is to reduce those. If you are the admin of something, and you are putting things into production in which you don't fully understand the implications, because you copy/pasted some crap from stackexchange assuming the person that posted it knew what they are…

> When in doubt, grab the RFC and figure it out.

Back in the day, I was using Cloudhopper, a Twitter-developed library for the SMPP protocol (not to be confused with SMTP!). Protocols being protocols, there are strict limits on field sizes, defined on the actual protocol spec. I noticed that Cloudhopper didn't impose those limits, however.

Long story short, it turns out they just left out strictly imposing field limits because other implementations didn't care either. De facto has overruled de jura and the inmates are running the asylum!

Re: Developers don't understand CORS (2019)

#227

Post by PunchyHamster »

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

It's probably trained more on fixes on incorrect CORS than the problems

Re: Developers don't understand CORS (2019)

#228

Post by PunchyHamster »

ozim wrote: post #38

Issue is that for most projects CORS is set and forget. You don’t run into it once a month or even once a year - you run into it when setting up new project from scratch. Many or most developers work on existing projects that have all kinds of security defaults set somewhere in the past and no one bothers reviewing those.

Nah the clowns at standard board just decide to fuck shit up every few years and add some new mess to CORS that breaks in some subtle edge case on existing setup

Re: Developers don't understand CORS (2019)

#229

Post by koolala »

9dev wrote: post #186
koolala wrote: post #146

Earlier quoted context omitted.

Who said anything about authentication? The only freedom I want is being able to wget content no differently than from a terminal. You need a modded custom browser to do that.

> Who said anything about authentication? That's the thing. If you're logged in to good.com (with a session cookie), then go to evil.com and it has an AJAX call to good.com, it'll carry your cookie. Thus - authentication. Suddenly evil.com can remote control good.com. (at least it used to be this way at the time we got CORS; the situation has changed a bit with newer web platform features like SameSite cookie params.…

You don't have to send cookies. Thats the entire point of credentialless. The option to be able not to do this is trivial yet everyone is so fixed on it being mandatory when its the entire problem. Forcing cookies on people is not a good thing.

Re: Developers don't understand CORS (2019)

#230

Post by koolala »

mr_toad wrote: post #208
koolala wrote: post #139

Earlier quoted context omitted.

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.

But it can easily be done differently. Its entirely possible to have the option available without cookies. It doesn't break backwards compatibility and no one has to use it in a situation where they need cookies. Cookies shouldn't be forced on people.
Post reply on HN