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

51–60 of 128 posts

Re: How to win at CORS

#51

Post by locallost »

nhumrich wrote: post #30

How to win at CORS: Don't use it. Just put the apis you need on the same domain, use a reverse proxy. Same-site just works, always.

My colleagues and I came to the same conclusion some time ago. I think CORS is not that complicated in essence, but I don't need to deal with it often enough to really memorize all the details. And there are many, as the article shows. Somehow we were always able to in the end deal with it, but at one point we didn't want to anymore. You make all these plans on how this service should be service.example.com and that one service2.example.com and this kind of feels like building something, but in reality it's just a headache unless you really need to do this for some reason.

Re: How to win at CORS

#52

Post by EE84M3i »

roca wrote: post #38

I tried really hard to get and to default to requiring same-origin but people were still skeptical about CORS deployment, and there were also arguments for consistency with . Oh well, I think we eventually got to a consensus that that "consistency" is not worth having.

webfonts require it though! I was really surprised!

Re: How to win at CORS

#53

Post by roca »

EE84M3i wrote: post #52
roca wrote: post #38

I tried really hard to get and to default to requiring same-origin but people were still skeptical about CORS deployment, and there were also arguments for consistency with . Oh well, I think we eventually got to a consensus that that "consistency" is not worth having.

webfonts require it though! I was really surprised!

Yeah, when Web fonts rolled around we fought that battle again and won. Some important people saw the light :-). (And to be fair, CORS was more widely available on servers.)

Re: How to win at CORS

#54

Post by jaffathecake »

roca wrote: post #53
EE84M3i wrote: post #52

Earlier quoted context omitted.

webfonts require it though! I was really surprised!

Yeah, when Web fonts rolled around we fought that battle again and won. Some important people saw the light :-). (And to be fair, CORS was more widely available on servers.)

I think font foundries were particularly keen on that juicy Origin header so they could tell who was using their font, and block sites that hadn't paid.

Re: How to win at CORS

#55

Post by AlbertoGP »

chrismorgan wrote: post #3

Point of fairly idle curiosity about the presentation of the article: why do you put a trailing slash on your empty elements (img, link) in your code samples? Some aren’t aware that the trailing slash is useless in the HTML syntax, simply being ignored by the parser and not doing anything. (Except for in inline SVG and MathML content, which switch the parser into a more XML-like mode where the trailing slash behaves…

> I can imagine some recommending it for XML compatibility (which is related to the original purpose of the ignore-the-trailing-slash behaviour, though slightly inverted in direction), but I don’t think I’ve ever encountered anyone saying so.

Well, pleased to meet you!

I do use it for XML compatibility: it allows me to use XML editor modes (usually nxml in Emacs) which, being simpler to implement as they don’t have to encode the rules of which tags close where, are more likely to be available and to work well.

I’ve also done little customizations to nxml over the years, and this way I have them always there no matter whether I’m working with XML or HTML.

And then occasionally I use other XML tools on it, such as xsltproc. You can still pipe the HTML through tidy to translate it (although xsltproc has --html, tidy has been more reliable), but having it compatible with XML does spare me small chores again and again.

Re: How to win at CORS

#56

Post by lloydatkinson »

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 the browser log a CORS error instead of, you know, a 500 or the actual error message.

I always do the "allow anything" setting for CORS when I make an API.

Re: How to win at CORS

#57

Post by lloydatkinson »

roca wrote: post #38

I tried really hard to get and to default to requiring same-origin but people were still skeptical about CORS deployment, and there were also arguments for consistency with . Oh well, I think we eventually got to a consensus that that "consistency" is not worth having.

I am really glad they overruled you.

Re: How to win at CORS

#58

Post by jaffathecake »

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…

Author here! I don't know if you read the article, but it includes the history and reason behind CORS.

It definitely protects more than nothing :)

Re: How to win at CORS

#59

Post by lloydatkinson »

jaffathecake wrote: post #58
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…

Author here! I don't know if you read the article, but it includes the history and reason behind CORS. It definitely protects more than nothing :)

I had a quick scan yeah. I'm sure historically it does but I've yet to ever need or encounter anyone that makes use of these features. I've never been in a team that particularly cares about any of it's supposed value either, it's merely a frustration to remove...

Re: How to win at CORS

#60

Post by jaffathecake »

lloydatkinson wrote: post #59
jaffathecake wrote: post #58

Earlier quoted context omitted.

Author here! I don't know if you read the article, but it includes the history and reason behind CORS. It definitely protects more than nothing :)

I had a quick scan yeah. I'm sure historically it does but I've yet to ever need or encounter anyone that makes use of these features. I've never been in a team that particularly cares about any of it's supposed value either, it's merely a frustration to remove...

You should try out some connected home devices, including things like routers. Like I said in the article, many of them assume they're safe because they're on a local network, so their security is lax.

Also, I know quite a few public sites that serve debugging data if the request comes from the company's IP range. They shouldn't be doing this, but they do.

Maybe one day we can remove CORS for no-credential requests if we can detect that the destination isn't "internal", and we just decide that folks who serve debugging data by IP deserve to have their data leak. I've heard ideas around this for 10 years now, but maybe it'll happen eventually.

Post reply on HN