Hacker News Reader

Comment by mrweasel | Hacker News Reader

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't understand webdevelopment in general, especially the http protocol. I find that somewhat strange, because they also can't do native application.

View on HN

It's easy to get wrong, and CORS is not well suited to today's cloud-native microservice era, when your code calls into a million and one different api endpoints hosted by various means.

It used to be that there was a webserver which handled requests, and a static site server, which served the assets, sitting behind a LB connected to the HTTP address.

It made zero sense to do anything cross origin, and it was automatically suspicious. Nowadays, there's N services, all potentially talking to each other, making CORS very difficult to get right.

And more often than not, they are hosted on generic 'api aggregator' endpoints, which make it very hard to get CORS to do anything meaningful with regards to security.

Also, considering you can URL encode stuff, the part saying CORS prevents the exfiltration of data is not true, it just imposes an inconvenience tax.

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

A bad one.

> I assume correctly, at least the application now works.

That's like saying the lock works because people can enter the building. What about keeping the bad guys out, which is the whole point?

> That's like saying the lock works because people can enter the building. What about keeping the bad guys out, which is the whole point?

You can keep all the "bad guys" out by putting a brick wall in place of every entrance and window. That will achieve 100% of the security goal, and even ops people might breathe a sigh of relief - until the stakeholders who commissioned the buildings get wind of it, that is.

Beyond that, locks aren't about "keeping bad guys out", but about giving owners a degree of control over who can access what and when. "Keeping bad guys out" is a subset of it, possibly a small one, unless you're happy defining "bad guys" as "people whose goals are at odds with the owner's business model".

Reply on news.ycombinator.com