Live data from Hacker News

Developers don't understand CORS

fosterelli.co

61–70 of 366 posts

Re: Developers don't understand CORS

#61
post #55

Earlier quoted context omitted.

I see it is fixed now. I thought up this work-around back in 2014, when NPAPI was phased out. Spotify and another large player came up with similar solutions.

Totally. I do get the constraints and I imagine Zoom had similar thinking here. The image approach, although hacky, can even be secure as-is if they need it for backward-compatibility but it needs to check the headers and not honour requests with the wrong value.

I kind of like the ingenuity of the approach. Never occurred to me to use non-active content.

Re: Developers don't understand CORS

#62
post #4

Earlier quoted context omitted.

I'm not familiar with Blazor or WebAPI, but if you're not expecting requests from client-side javascript specifically, you can just use `Access-Control-Allow-Origin: null`, since non-browser clients don't respect CORS anyway. If by "open to the public" you mean "open to requests from any client domain", CORS isn't going to help. In that case I'd probably have api clients pre-register a whitelist of domains that they'…

Can you point me to some documentation for dynamically allow-origin header? I’m working on open sourcing our frontend and so if users have their own frontend on their own domain, how do we allow those calls to our backend with CORS? If we turn CORS off, is this a security issue? From the frontend, we send a JWT with the header and check this for protected routes on the backend.

Is your frontend a static webapp that communicates directly from the browser to your backend, or another server that talks to your backend?

Re: Developers don't understand CORS

#63
post #38
post #24

Seriously wondering! Why is Zoom worth $2B and companies are paying per minute plans to host meetings when you can now host your own videoconferencing software easily on your own website or app or intranet using WebRTC, branded, with your own experience, widgets, and it can all be open source? All you need to pay for are dumb TURN servers eg from twilio. Plus it would be far more secure. For example we built https://…

This reads so much like the infamous dropbox comment.

For anyone wanting the link.

Comment

https://news.ycombinator.com/item?id=9224

Post

https://news.ycombinator.com/item?id=8863

Re: Developers don't understand CORS

#64

Earlier quoted context omitted.

As a motivation to use: To prevent other sites using your resources, causing you an extra bandwith cost.

On the contrary: CORS is what enables other sites to use your resources (in a way allowed by your policy). It was created because, by default, browsers don't let you do that.

I think what GP commented is a very common misconception. CORS is not the source of the developer trouble (that would be cross-origin restrictions), it is a way around them. But it is perhaps understandable where the confusion comes from... Browsers always mention CORS headers as part of error messages, after all.

Re: Developers don't understand CORS

#65
post #20

It's not just a lack of understanding but a lack of support in server tooling. I was setting up CloudFront on AWS and kept running into CORS issues. I did all the steps to set the necessary headers, but it still didn't work. I ended up just doing some layer 7 routing to route requests to /api towards the other server that was on the other domain to avoid the CORS issues, because now there is no cross domain request.…

But were the headers reaching the browser or not? CORS is something strictly for the browsers to parse, so if it's reaching the browser, either the policy is wrong (and you can usually see that in the browser console, when it blocks the cross-domain request) or it's not a CORS problem.

Re: Developers don't understand CORS

#66
post #4

Earlier quoted context omitted.

I'm not familiar with Blazor or WebAPI, but if you're not expecting requests from client-side javascript specifically, you can just use `Access-Control-Allow-Origin: null`, since non-browser clients don't respect CORS anyway. If by "open to the public" you mean "open to requests from any client domain", CORS isn't going to help. In that case I'd probably have api clients pre-register a whitelist of domains that they'…

Can you point me to some documentation for dynamically allow-origin header? I’m working on open sourcing our frontend and so if users have their own frontend on their own domain, how do we allow those calls to our backend with CORS? If we turn CORS off, is this a security issue? From the frontend, we send a JWT with the header and check this for protected routes on the backend.

CORS is really pretty simple, it's getting the threat model that is tricky. Some docs on Allow-Origin here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac... and a more complete walkthrough here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Dynamic allow-origin sounds magical, but is really straightforward. You just look at the `Origin` header of a request (e.g., in express `req.headers['Origin']`), compare it against your database of whitelisted origins, and if it's in there, return it as the value of `Access-Control-Allow-Header`.

If you don't have any relationship with the folks using your frontend, I'd just "turn it off", that is, use "Access-Control-Allow-Origin: *". It's a security issue only insofar as you don't trust the third party that owns the web frontend to handle their users' data securely, either by introducing their own security vulnerabilities, or by hijacking users' sessions themselves. The big question I think is whether the third party's users are your users too, in which case you're responsible to vet the third party to protect your users. If you're just a backend for whatever-the-heck, just make sure you have a good terms of service for the api so you're not assuming responsibility for other people's mistakes/malice.

Re: Developers don't understand CORS

#67
post #40
post #28

Earlier quoted context omitted.

I read extensive parts of the CORS specification and it is indeed teflon (and just as toxic as teflon as well). The spec is full of exceptions and leaves many choices to the browser vendors. To truly understand CORS, you have to fundamentally understand 'the origin' as a security and execution context. Sharing means that content normally intended for another origin is shared with the initial origin. Perhaps that is b…

> In that case, I propose to read more of the spec. Ingest more teflon when in doubt about its toxicity.

But Teflon is non-toxic and biocompatible. You can eat it, your body is unable to process it or break it down and it will pass through your digestive system. You can coat surgical instruments and medical implants with Teflon.

(Above 300°C Teflon will generate toxic fumes, but then again, so will wood.)

Re: Developers don't understand CORS

#68
post #30
post #29

Earlier quoted context omitted.

Wrong conclusion. The kludge is making cross origin requests in the first place.

Maybe, but people want to write applications that can easily interact with each other in a secure way. Trying to do that when your browser implicitly authorizes you no matter what the origin of a request is makes that extraordinarily difficult to do safely. Adding in the backwards compatibility problem makes it even worse because any solution is going to have to work with the existing methods.

[deleted]

Re: Developers don't understand CORS

#69
post #20

It's not just a lack of understanding but a lack of support in server tooling. I was setting up CloudFront on AWS and kept running into CORS issues. I did all the steps to set the necessary headers, but it still didn't work. I ended up just doing some layer 7 routing to route requests to /api towards the other server that was on the other domain to avoid the CORS issues, because now there is no cross domain request.…

But were the headers reaching the browser or not? CORS is something strictly for the browsers to parse, so if it's reaching the browser, either the policy is wrong (and you can usually see that in the browser console, when it blocks the cross-domain request) or it's not a CORS problem.

It wasn’t reaching the browser.

Re: Developers don't understand CORS

#70
post #12

I certainly don't understand CORS. I've read about it several times and I don't remember what I read. It's like CORS has a teflon coating that prevents it from sticking in my mind. I know what CORS is for and why you need it, but I have no idea how, where, and when to use it.

The only thing I know about CORS is when every web project I do starts generating funky errors and the fix is some CORS related copy-pasta I have to add.

Very little objective thought involved.

Post reply on HN