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

181–190 of 285 posts

Re: Developers don't understand CORS (2019)

#181

Post by embedding-shape »

Beltiras wrote: post #143
RobotToaster wrote: post #73

Earlier quoted context omitted.

It seems like nobody understands CORS. Including me TBH.

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 opens up a whole host of issues, so browsers started limiting websites to just being allowed to make requests to the same Origin. But sometimes we want to be able to make requests from pages to other Origins, so CORS (Cross-Origin Resource Sharing) lets you configure your server to tell browsers that "You're allowed to make requests to me, even if you're on a different origin".

This is basically the simplified version of the why and how behind CORS.

Re: Developers don't understand CORS (2019)

#182

Post by TeMPOraL »

zdc1 wrote: post #57
physix wrote: post #24

> Developer's don't understand CORS Count me in!

Even the HN comments here are a sea of confusion and contradiction. It's stunning and makes me wonder whether CORS is a bad solution, or if it's solving a hard problem.

Problems:

- It has a name. That name was allowed to become more recognizable than that of the actual security mechanism (SOP).

- Once you use its name and start thinking of CORS as "the thing", most of DX is about CORS standing between you and perfectly reasonable, legitimate functionality you need to support.

- It does seem to put control in a weird place (backend telling a browser what it is or isn't allowed to do), and people seem to miss that this relies entirely on the browser itself being a compliant party you cannot control.

- I have my own, rather negative, opinions on the whole security model of the browser, that's strongly countercurrent (mostly about how it disenfranchises users), so let's just say here that this is indeed a hard problem being solved - so it doesn't help when people think of an exception policy as a security measure.

Re: Developers don't understand CORS (2019)

#183

Post by simonw »

embedding-shape wrote: post #179
simonw wrote: post #176

To understand CORS, you have to understand the Same Origin Policy. If you find CORS difficult to understand, particularly the question of "why do we need this?", I suggest starting here: https://developer.mozilla.org/en-US/docs/Web/Security/Defens... I've tried using the Same Origin Policy as an interview question in the past, but it's not a good question because the majority of candidates aren't familiar with it, so…

> I've tried using the Same Origin Policy as an interview question in the past, but it's not a good question because the majority of candidates aren't familiar with it, so you learn very little by bringing it up. For hiring frontend developers, I've found it to be an excellent question, as surely if you've been developing web apps, you essentially must have come across it at some point. If you haven't, I'd be asking…

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!

Re: Developers don't understand CORS (2019)

#184

Post by Sophira »

xg15 wrote: post #151
Sophira wrote: post #138

Earlier quoted context omitted.

If your web application specifically parses data based on the Content-Type that it advertises itself to be, then yes, the webapp would hit a parse error. But there are many applications that don't do that. An attacker might use JavaScript to set a "multipart/form-data" Content-Type (thereby bypassing the otherwise required OPTIONS preflight), but send JSON in the request body. Unless your web application specifically…

Well, if your endpoint expects JSON, then at some point it will have to parse it. Even if it completely ignores the content-type header and simply always passes the request body to the JSON parser, the parser would throw. (But I was wrong, there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format, as the sibling comment demonstrated)

> ...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);
    xhr.setRequestHeader('Content-Type', 'multipart/form-data');
    xhr.send('{"hello":"world"}');
No trickery required, it just does it.

[Edited to illustrate my point better.]

Re: Developers don't understand CORS (2019)

#185

Post by embedding-shape »

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

Earlier quoted context omitted.

> I've tried using the Same Origin Policy as an interview question in the past, but it's not a good question because the majority of candidates aren't familiar with it, so you learn very little by bringing it up. For hiring frontend developers, I've found it to be an excellent question, as surely if you've been developing web apps, you essentially must have come across it at some point. If you haven't, I'd be asking…

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, unless of course the point is to hire them to train them.

Re: Developers don't understand CORS (2019)

#186

Post by 9dev »

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

Earlier quoted context omitted.

You can do whatever you want with your browser client. You just cannot create a website that will make the browser clients of other people send authenticated requests from JavaScript to my site if I don’t want that.

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

> The only freedom I want is being able to wget content no differently than from a terminal.

I see your point, I really do. But the Venn diagram overlap of "sites that need to download arbitrary websites", "sites that need to only fetch content client-side in the browser, not via their backend", and "sites that do this for non-nefarious purposes" is infinitesimally small. I'm pretty sure your use case is missing at least one of these three criteria.

Re: Developers don't understand CORS (2019)

#188

Post by rswail »

stephbook wrote: post #21

I still don't understand the threat model and, obviously, it's not explained here either. I log in to social.net. I click on scam.org and change sites. I'm on scam.org and it triggers a request to social.net/friends. No cookies are sent, no JWT. I'm not logged in and get a "Needs login" HTTP error. Nothing bad happens. I thought that's how it works without CORS already.

CORS relaxes the rules about what requests the browser can make.

The server doesn't get to stop the browser making calls that it didn't want, so it's a browser security feature, to stop the browser sending cookies where it shouldn't, or more precisely, to only send authentication and other info where it should.

It relaxes the same origin policy.

Usually a browser will not load resources from another origin based on the HTML it receives. If the page is from example.com, it won't allow you to load a page from example.org.

That stops things like authentication and cookies etc from example.com being transmitted to example.org if someone hacks the webpage.

CORS allows the server to relax those rules so that it can say "You can load resources from me, or from these other servers."

So it can say "I'm example.com but you can load resources from example.org and that's OK."

At least, that's how I think it works :)

Re: Developers don't understand CORS (2019)

#189

Post by Sophira »

xg15 wrote: post #164
TeMPOraL wrote: post #160

Earlier quoted context omitted.

Obviously JSON is a subset of text/plain, so I don't know what people were expecting? For text/plain to mean "plaintext, excluding any string that could possibly parse as any of the other named formats that have a plaintext representation"? Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"?

I wasn't aware that plaintext was one of the whitelisted types that are allowed without a preflight request. I guess the same trick might work with urlencoded forms, but it wouldn't work with multipart/form-data > Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"? For better or worse, yes, or at least as one layer. That's on…

> I guess the same trick might work with urlencoded forms, but it wouldn't work with multipart/form-data

It does, though. See my reply at https://news.ycombinator.com/item?id=48618539 .

Post reply on HN