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

261–270 of 285 posts

Re: Developers don't understand CORS (2019)

#261

Post by TurdF3rguson »

Lerc wrote: post #219
mr_toad wrote: post #193

Earlier quoted context omitted.

CORS isn’t designed to increase security, since the same-origin policy is a secure default. It’s a mechanism to allow pages to access servers that they can’t by default - with the permission of the server operator.

But the combination of the two reduces security in the same manner as absurd password requirements cause people to write down their passwords. A strong security measure without a reliable way to do the things you want to do induces people to bypass the security altogether. Security designers generally are ok with this because they consider usability or user behaviour to be not their responsibility.

If you're hosting some 3rd party api that's safe to call client side then you send some header that says so. The problem is when it's not safe and devs try to bypass (a reliable way to do the things they want).

The solution is to convince devs to not want to do those things.

Re: Developers don't understand CORS (2019)

#262

Post by bazoom42 »

ksbd-pls-finish wrote: post #158
stymaar wrote: post #142

Earlier quoted context omitted.

I don't understand why this is the most upvoted comment. OP is right, and you are wrong. > The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects. 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.…

>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. Just my first thought as a security engineer, but sounds like a perfect opportunity to execute a timing attack to me. For example, vheck which users exist (by measuring response time for /api/users?name…

Probably, but note that cross-domain GET-requests have been supported since the beginning of the web, since this is literally how links works.

So while a badly implemented GET handler can indeed cause security issues, this is old news and unrelated to CORS.

(Besides, why measure response times? Can’t you just check if api/users?name=john returns a resource or a 404 not found?)

Re: Developers don't understand CORS (2019)

#263

Post by [deleted] »

rnotaro wrote: post #168
masklinn wrote: post #144

Earlier quoted context omitted.

That’s… not what cors does? CORS will only block browser-mediated “non-simple” requests, they don’t prevent other systems from accessing it as long as they don’t use a browser (or disable CORS in a headless browser).

I'm pretty sure they understand that since they wrote that the resources will need to be proxied. They just want to prevent hotlinking/leeching.

[deleted]

Re: Developers don't understand CORS (2019)

#264

Post by temporallobe »

I read through the comments to make sure I wasn’t the only one…Nobody understands CORS because it’s too complicated and too conflicting. The standards and the headers are always changing too, so mostly what happens is that we developers just tinker with it until it works, then ship the product and call it a day. Even when it works, you may still end up with errors and warnings in the dev console, but as long as things appear to be working, we leave it alone.

Re: Developers don't understand CORS (2019)

#266

Post by Keyframe »

sourcecodeplz wrote: post #48
rishabhpoddar wrote: post #42

I agree that CORS is hard to understand and fix. I was the CTO at an auth company and SO many of our users used to run into various CORS issues and asked questions on our support. However, I'd now argue that developers don't need to understand CORS anymore.. cause claude / gpt does! Just throw in the error in claude code / codex and it would fix it.

damn where are we heading?

Start learning security, this will be a great career going forward!

Re: Developers don't understand CORS (2019)

#267

Post by [deleted] »

temporallobe wrote: post #264

I read through the comments to make sure I wasn’t the only one…Nobody understands CORS because it’s too complicated and too conflicting. The standards and the headers are always changing too, so mostly what happens is that we developers just tinker with it until it works, then ship the product and call it a day. Even when it works, you may still end up with errors and warnings in the dev console, but as long as thing…

[deleted]

Re: Developers don't understand CORS (2019)

#268

Post by christophilus »

embedding-shape wrote: post #185
simonw wrote: post #183

Earlier quoted context omitted.

Frontend candidates who have worked with CORS still aren't able to explain SOP and why those policies exist, in my experience. CORS is seen an irritation to be worked around. There are a few examples of that in this HN thread!

> Frontend candidates who have worked with CORS still aren't able to explain SOP and why those policies exist, in my experience But that's exactly the kind of thing you want to surface in the hiring process with that question :) I guess it depends on if you're hiring juniors to be trained, or seniors to elevate your current team, but personally I'd skip very quickly on people who don't know the basics of their jobs,…

To be fair, I set up our CORS policy 6-7 years ago. I don’t remember the details anymore. I’ve been busy building product. So, this interview question will make me stumble, even though I’m quite senior. I think asking people about things that are set it and forget it once per project is probably not the best way to screen for relevant knowledge.

Re: Developers don't understand CORS (2019)

#269

Post by embedding-shape »

christophilus wrote: post #268
embedding-shape wrote: post #185

Earlier quoted context omitted.

> Frontend candidates who have worked with CORS still aren't able to explain SOP and why those policies exist, in my experience But that's exactly the kind of thing you want to surface in the hiring process with that question :) I guess it depends on if you're hiring juniors to be trained, or seniors to elevate your current team, but personally I'd skip very quickly on people who don't know the basics of their jobs,…

To be fair, I set up our CORS policy 6-7 years ago. I don’t remember the details anymore. I’ve been busy building product. So, this interview question will make me stumble, even though I’m quite senior. I think asking people about things that are set it and forget it once per project is probably not the best way to screen for relevant knowledge.

If understanding Origin isn't part of what a frontend developer needs know, kind of feels like nothing is. You need to understand that part to even know what APIs are available to you, without a "secure origin" you won't have access to cryptography, geolocation and a whole host of other JS APIs, as just one example. Understanding why HTTP requests works against one API but not the other also feels like pretty trivial troubleshooting skills.

I'm not saying people should make hiring decisions based on one question that people may not have in the forefront of their mind, but evaluating if a web backend developer understands HTTP or if a frontend developer understands Origins feels like pretty bare minimum here. If you don't recall 100% of the details, surely you must remember some, or if reminded, some details about it are remembered. Otherwise, maybe you actually have lost the expertise since then? That's a useful signal too.

Re: Developers don't understand CORS (2019)

#270

Post by jkrejcha »

JimDabell wrote: post #242
kittywantsbacon wrote: post #61

[flagged]

I think perhaps it’s generational. If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along and CORS was created to bypass this security. Therefore to do the thing you want to do, you need to enable CORS. No problem, that’s pretty easy. If you only picked up web development after CORS existed, then you try to make a cross-origin request; the browser unde…

Gonna play devil's advocate here

I think to some extent CORS and SOP are a bit equivocated somewhat intentionally... i.e. CORS is a used as a shorthand for SOP because CORS is a more well known term, especially in its acronymized form.

Consider for example the error I get when opening up the console on Google's homepage

> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://play.google.com/log?format=json&hasfast=true. (Reason: CORS request did not succeed). Status code: (null).

There is a reference to the SOP in here but it starts off with "Cross-Origin Request" and also says "CORS request did not succeed". Which makes it sound like CORS is the problem or the thing doing the blocking or that "CORS" is enforcing the "Same Origin Policy". Chrome, I've heard, is even more cryptic

Also, it feels like one of those things that are a little pedantic to mention in a discussion irl, so that's probably why the term CORS sticks and the term SOP doesn't

Post reply on HN