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

How to win at CORS

jakearchibald.com

Post reply on HN
Print view View original

91–100 of 128 posts

Re: How to win at CORS

#91

Post by tomashubelbauer »

llimllib wrote: post #90
tomashubelbauer wrote: post #88

Earlier quoted context omitted.

I tried to achieve the same thing in the past and have run across issues with HSTS. The details are escaping me but I think it might have been that when using the production app without a proxy, the SSL certificate was associated with the HSTS records in the browser and when I switched to a proxy, the HSTS started failing because the certificate has changed. Have you run into this at all? How have you solved it?

I don't develop at the same URL as I publish at - I'll generate keys with mkcert and host my site locally via a proxy at local.realdomainhere.com for a site that has dev.realdomainhere.com and the prod domain www.realdomainhere.com.

I see, I misunderstood. My dream setup is one where I have the same URL for TEST/STAG/PROD and just switch which BE the URL resolves to based on some configuration/tool.

Re: How to win at CORS

#92

Post by jaffathecake »

rogual wrote: post #89

If CORS is supposed to solve the problem of credentials being sent to third-party sites without the user's knowledge, I don't understand why the solution wasn't just to not send the credentials.

That isn't all it's supposed to solve. Give the article a read, these points are specifically addressed :)

Re: How to win at CORS

#93

Post by ufmace »

I've banged my head against some CORS puzzles recently. That's a pretty good guide, but I actually know an extra quirk that was missed:

You know that nice "Access-Control-Allow-Credentials: true" header? In theory, it means that you can make authorized requests with cookies included to the cross-origin API. It actually has some extra rules that aren't obvious though. The cookies won't actually send unless they explicitly have "SameSite=None" set. Which itself isn't valid unless you are both making the request over HTTPS, and the cookie also has the flag "Secure". See here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...

The cookie logic is kind of mysterious. When everything is set up correctly and it works, it's pretty invisible to the code making the cross-origin requests. But if it isn't set up quite right, it will just not work, and it can be pretty tricky to figure out what's wrong. The whole SameSite logic is a pretty interesting kludge too. Ideally, most things would be SameSite=Strict, but that also means that links the user follows from third-parties to your site won't include cookies, since in theory those requests could include GET params doing who knows what.

Digging into all of the CORS rules and how they interact is almost an archaeology project into how the web was built and all of the weird things that both legit sites and malicious attackers have tried to do over the years.

Re: How to win at CORS

#94

Post by jaffathecake »

ufmace wrote: post #93

I've banged my head against some CORS puzzles recently. That's a pretty good guide, but I actually know an extra quirk that was missed: You know that nice "Access-Control-Allow-Credentials: true" header? In theory, it means that you can make authorized requests with cookies included to the cross-origin API. It actually has some extra rules that aren't obvious though. The cookies won't actually send unless they explic…

The article mentions the SameSite stuff early on, then kinda mentions it in passing when it comes to CORS + credentials "The same-site rules around cookies still apply, as do the kinds of isolation we see in Firefox and Safari. But these only come into effect cross-site, not cross-origin".

Seems like I need to word it better though.

Re: How to win at CORS

#95

Post by Jenk »

lwouis wrote: post #76

When developing a webapp these days, I use a local proxy. This allows me to type a staging/production URL into Chrome, and get the frontend and the backend from either my local machine or staging/prod. I can mix and match any combination by checking/unchecking a box in Proxyman. This means there is no need to whitelist localhost for CORS, and other hoops. Another advantage is that you're experiencing the app with SSL…

Alternatively there are dynamic DNS services like https://sslip.io/, https://nip.io, or if it ever comes back: https://xip.io.

They let you use hostnames that redirect, so for example: https://foo.127.0.0.1.sslip.io will redirect to your localhost.

Re: How to win at CORS

#96

Post by Randosaurus »

lol768 wrote: post #61
lloydatkinson wrote: post #56

CORS is a stupid idea that serves no purpose. If someone is really determined they will either 1) turn off CORS with a browser extension 2) simply call your precious API from something other than an a browser It is essentially security by obscurity and protects nothing. Don't get me started how some technologies like AWS Lambda with a Gateway, when a function has an error, responds by default in such a way it makes t…

> CORS is a stupid idea that serves no purpose. If someone is really determined they will either 1) turn off CORS with a browser extension 2) simply call your precious API from something other than an a browser > It is essentially security by obscurity and protects nothing. What. I think there's been a fundamental misunderstanding of who is being protected here on your part, and what CORS is actually for. It's your r…

Nowadays you can set cookie flags to ensure those sorts of attacks don't happen.

Re: How to win at CORS

#97

Post by [deleted] »

Waterluvian wrote: post #16
kadoban wrote: post #9

Earlier quoted context omitted.

Aren't they optional 100% of the time though?

Not 100%. There are a small handful of really wicked gotchas. I think there’s a lot of articles on them. I can’t find the one I like and don’t want to share one I haven’t read yet.

[deleted]

Re: How to win at CORS

#98

Post by jnovacho »

eurasiantiger wrote: post #71
thepasswordis wrote: post #37

CORS has been no shortage of greys in my beard! When I'm writing some frontend that is hosted on localhost, with an API that is hosted on its domain somewhere, it always is some sort of PITA to get the dev environ started. There's a plugin for firefox that ignores CORS which is helpful for this. It's becoming less useful for me as my APIs now usually have a toggle to add a cross origin header which allows localhost.…

Just use http-proxy to set up a local domain so you can access your dev environment at frontend.yoursite.local (proxied to localhost:3000) and the api at api.yoursite.local (proxied to whatever 3rd party api). Boom, problem solved. You can even rewrite headers and content of the requests in and out.

Do you have any recomendations, which proxy to use? Specifically on Win.

Re: How to win at CORS

#99

Post by Aulig »

jaffathecake wrote: post #85
Aulig wrote: post #84

I wish there was a way to let me make POST requests on behalf of the user without dealing with CORS. Of course the request wouldn't include any user cookies etc to avoid the security issues. I just want to easily let my users make API requests to an API whose CORS settings don't allow it. Instead I have to tell my users to give me their API key so I can make the request from my server. Or I'd have to tell them to run…

> I wish there was a way to let me make POST requests on behalf of the user without dealing with CORS. Of course the request wouldn't include any user cookies etc to avoid the security issues. You can! And it can include credentials! You can do this with a basic element, so fetch() lets you do the same. What you can't do is read the response. Demo: https://jakearchibald.com/2021/cors/playground/?prefillForm=...

Thank you! Unfortunately I need to read the response (so extra thank you for pointing that out before), but maybe just posting will be enough for a future application :)

Re: How to win at CORS

#100

Post by rogual »

jaffathecake wrote: post #92
rogual wrote: post #89

If CORS is supposed to solve the problem of credentials being sent to third-party sites without the user's knowledge, I don't understand why the solution wasn't just to not send the credentials.

That isn't all it's supposed to solve. Give the article a read, these points are specifically addressed :)

Enlightening, thanks! I had thought maybe a site could in theory use your IP or even just your ability to connect to figure out who it thinks you are, but didn't know this was so common.
Post reply on HN