Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers don't understand CORS

fosterelli.co

Post reply on HN
Print view View original

111–120 of 366 posts

Re: Developers don't understand CORS

#111

Post by alexbanks »

rolltiide wrote: post #70
csours wrote: 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.

I came to this thread hoping to find that I am not alone. Thanks for validating that for me.

Re: Developers don't understand CORS

#112

Post by tgsovlerkhgsel »

yeldarb wrote: post #43
zenexer wrote: post #31

The author suggests that using CORS to allow https://zoom.us with http://localhost:19421 is possible. This is factually incorrect. Mixed content policies prevent the http: origin from communicating with the https: origin. "For very intentional reasons, the browser explicitly ignores any CORS policy for servers running on localhost." That last sentence is incorrect – Chrome does respect CORS headers for localhost webs…

Could they sign and distribute a cert for localhost.zoom.us and point the DNS at 127.0.0.1?

They could, but if they distribute the private key, which they would, the private key would be considered compromised, and the CA would be required to revoke the certificate within something like 24h of being notified with appropriate evidence (e.g. a copy of the key or a special message signed with the key).

In the case of LetsEncrypt certificates, there is even an API for this revocation.

However, given how ineffective revocation is, it unfortunately could still be a viable strategy.

The easier approach is, of course, using the fact that browsers now consider http://127.0.0.1 (and/or http://localhost) a secure origin to avoid this issue.

Re: Developers don't understand CORS

#113

Post by jedberg »

icebraining wrote: post #94
jedberg wrote: post #69

Earlier quoted context omitted.

It wasn’t reaching the browser.

Seems like you have to whitelist the headers: https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...

I did, but it still didn't work. It was extra complicated because it was coming out of API gateway calling Lambda.

But the point is, it shouldn't be that complex and I shouldn't have to dive deep into the docs to make it work. That is as much an impediment to CORS as is the lack of understanding.

Re: Developers don't understand CORS

#114

Post by throwamay1241 »

untog wrote: post #95
jrudolph wrote: post #80

CORS is a minefield. It doesn't help that the RFC is incredibly dense. I may be totally missing something, but I've repeatedly wondered though if CORS still has its place in times of SPAs that exclusively use xhr + javascript + some sort of auth token talking to a REST API? Consider this argument: CORS basically ensures that browser and servers cooperate to protect end users from a "smart" user agent that happily thr…

> Remove cookies and basic auth headers, what's the point of CORS? The ability to communicate with a domain other than the one your app is running on. For instance, if my site on www.example.com wants to send a POST to www.example2.com, I need CORS. example2.com needs CORS to specify that only example.com is allowed to send a POST to it, not anyoldaddress.com. example2.com could look at the Origin header and refuse c…

I don't think the act of sending the POST is blocked by CORS, receiving the POSTed response data is though.

Re: Developers don't understand CORS

#115

Post by greenshackle2 »

MetalGuru wrote: post #10

> The webserver listening in on localhost:19421 should implement a REST API Is this server started by Zoom? In order to implement an endpoint, they’d have to ship a server along with the client. And this server would always be running? Is this not overkill for such a small feature (being able to click a link)

They already ship a server along with the client. It's already always running.

The author is explaining how they could have done it more securely. I think everyone here including the author would agree it's a ridiculous solution for this "feature".

Re: Developers don't understand CORS

#116

Post by whatshisface »

iforgotpassword wrote: post #103
klodolph wrote: post #67

Earlier quoted context omitted.

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

Studies funded by companies selling Teflon products say 300 degrees. Others conclude it happens at temperatures as low as 200 which you can easily reach while cooking. Anyways I'm almost always using plain old steel pans and pots. There are very few things that stick so badly I resort to the one Teflon pan I have.

Watch out: some types of stainless steel can leech enough nickel to approach the safety line.

Re: Developers don't understand CORS

#117

Post by theturtletalks »

icebraining wrote: post #62
theturtletalks wrote: post #27

Earlier quoted context omitted.

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?

Yes frontend is a Next.js app and the backend is a GraphQL server.

Re: Developers don't understand CORS

#118

Post by superasn »

csours wrote: 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.

I have some basic understanding of it. I'll try to simplify what I know if anyone else is feeling confused about CORS.

- You visit evil.com.

- Evil tries to makes an HTTP request to bank.com/transfer.php

- But before the request goes through the Browser says, hey, wait a minute I first need to make sure if evil.com can access bank.com

- Browser asks bank.com, if evil.com (also known as origin) is allowed by sending an "OPTIONS" request first (this is before making the actual request)

- Bank.com replies in header saying "sure, everyone is allowed" (e.g. my bank), technically by setting a HTTP "Access-Control-Allow-Origin: * " header (or just evil.com instead of * )

- Browser is happy, it makes the requests and you get the data

Of course there is more to this like the server can tell which HTTP methods evil.com can do like "POST", "GET", "PUT", etc using "Access-Control-Allow-Methods". If the browser needs to send the cookies too with the request ("Access-Control-Allow-Credentials"), etc. But that is pretty much the gist of it as I understand.

Re: Developers don't understand CORS

#119

Post by mehrdadn »

bzbarsky wrote: post #104
pixelperfect wrote: post #54

Earlier quoted context omitted.

I thought the browser at evil.com would first send a pre-fetch request without the cookies, but not send the full request when it doesn't get the correct value from Access-Control-Allow-Origin in the response from banking.com. I'll admit I may be one of the developers that doesn't understand CORS...

CORS doesn't apply to navigations by default, so anaphor is correct: evil.com can just submit a form to banking.com and it will send the banking.com cookies. This is the whole field of CSRF (cross-site request forgery) mitigation. CORS was introduced as a way to allow requests that browsers used to not allow at all: things like cross-site XHR in the first instance. Then it was expanded so that requests that are not n…

Is my take on this also generally correct? That it wouldn't have been a problem had cookies and such been designed to take into account the origin properly (and hence why it's unintuitive and catches people off-guard)?

Re: Developers don't understand CORS

#120

Post by tgsovlerkhgsel »

euroclydon wrote: post #109
tgsovlerkhgsel wrote: post #102

Earlier quoted context omitted.

CORS stands for Cross-origin resource sharing. It allows you to make arbitrary HTTP requests across origins, even those that would normally be blocked by the same-origin policy, as long as the server collaborates and allows it, easily and in a secure way. If you control the server (or can get someone to adjust it, or it already supports it), you can use it to make requests from one website to another, directly from t…

Well... CORS controls whether the browser lets the other page read the response, not issue the request, preflight not withstanding.

Yes, because issuing the request was already allowed despite the same-origin policy. For example, you can do GET requests with iframes, images or redirects, and POST requests with HTTP forms.

The important part is that CORS can be used to relax any existing same-origin restrictions on HTTP requests.

1. If the same-origin policy isn't a problem for you, no need to change anything, obviously.

2. If you want to _tighten_ the same-origin policy, CORS isn't going to help you (as far as I know).

3. You can get rid of any request-related same-origin policy restriction with CORS, easily and in a way that is easy to secure. There is no need to build around it.

4. If you try to use something custom to achieve that instead, you're likely making a dumb mistake, because you're not only creating unnecessary work, but also most likely either breaking many more users than there are users that don't support CORS, or introducing a gaping security hole, or both. Usually both.

Post reply on HN