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

61–70 of 128 posts

Re: How to win at CORS

#61

Post by lol768 »

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 run-of-the-mill user that CORS protects, and CORS being enforced protects them when they visit e.g. an attacker-controlled site with, for example, a valid cookie-based session on your service. It prevents the attacker's site from making dangerous authenticated requests to your API service and reading the result.

> 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

That's not what CORS is designed to protect against at all, of course you can hit an API separately and your HTTP client will ignore the CORS headers. Your HTTP client isn't a browser! It doesn't need to worry about CORS.

Similarly, users shooting themselves in the foot by disabling CORS are only hurting themselves. They are not the attacker here.

Re: How to win at CORS

#62

Post by chrismorgan »

AlbertoGP wrote: post #55
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 t…

Yeah, that’s fair enough. In the past I was more likely to close tags like p/tr/td than I am now because the Vim indent file I was using for html didn’t handle some of those properly back then.

Re: How to win at CORS

#63

Post by fraktl »

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.

This.

But hey, with so many impostors around - they're not capable of fathoming how golden this advice is.

Sad truth is, since "developers" don't use this, they genuinely don't understand browsers and HTTP and that's what 's dangerous.

Re: How to win at CORS

#64

Post by jaffathecake »

Bonus fact: I wanted the 'app' (https://jakearchibald.com/2021/cors/playground/) to allow the HTTP method to be set to anything, which meant I needed a server that could accept anything.

I usually use NodeJS, but it turns out the HTTP library they use turns the HTTP method into an enum, so only a subset is supported (https://github.com/nodejs/node/blob/d798de1c653efa5ec0015d44...). This restriction only exists in their HTTP/1 library, their HTTP/2 library supports any method.

Anyway, I couldn't use that, so I used Deno via Deno Deploy. Their HTTP library supports any method, and the APIs they use are very similar to web APIs, so it was really easy to get started. Here's the server code: https://github.com/jakearchibald/cors-playground/blob/main/i....

Re: How to win at CORS

#65

Post by [deleted] »

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…

[deleted]

Re: How to win at CORS

#66

Post by dspillett »

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

> writing some frontend that is hosted on localhost

I assume this would also work for CORS purposes: for some time I've not used localhost where possible, for SSL reasons. Giving the local machine a perfectly valid name that I can get a cert for via LE (or already have a cert for, I actually use a non-production name for which I maintain a wildcard cert) is slightly less faf than having my own signing cert installed as trusted everywhere I might need it. Anything I might do publicly is HTTPS-only so my dev/test environments are too.

Re: How to win at CORS

#67

Post by nuerow »

kindall wrote: post #7
billfruit wrote: post #2

How they jump into the article without explaining or even expanding what the CORS acronym stands for.

If you don't already know what CORS is, you're probably not a Web developer and don't need to know.

> If you don't already know what CORS is, you're probably not a Web developer and don't need to know.

This is an appallingly poor and misguided take, and goes against the most basic rules of writing technical documents. Docs need to be clear, unambiguous, and self-contained. The very first time a acronym is presented, it must be after the full name is presented.

It takes less than a sentence to do the right thing. There is no excuse.

Re: How to win at CORS

#68

Post by fraktl »

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…

Out of curiosity, how come you dared to make this comment without ensuring you've got all your facts straight?

No, it isn't security through obscurity. Yes, it protects and it protects a lot.

Thank you for contributing to lack of knowledge, do keep up.

Re: How to win at CORS

#69

Post by chrismorgan »

jaffathecake wrote: post #64

Bonus fact: I wanted the 'app' ( https://jakearchibald.com/2021/cors/playground/ ) to allow the HTTP method to be set to anything, which meant I needed a server that could accept anything. I usually use NodeJS, but it turns out the HTTP library they use turns the HTTP method into an enum, so only a subset is supported ( https://github.com/nodejs/node/blob/d798de1c653efa5ec0015d44... ). This restriction only exists in…

My recollection from circa 2013 is that Node.js at least used to use the nginx HTTP parser, which was a horror of manually-implemented state machine written so in the name of performance, but consequently basically unmaintainable and fairly bug-riddled. And not as fast as it should have been, anyway. (The state machine approach is fine, but it should have used a lot more code generation.) It read the method byte by byte into the state machine, and baulked at unknown methods. Evidently they’ve kept that limitation, whatever they may have changed since in the parser they use (and I think nginx did eventually abandon and replace that parser entirely).

(These are my recollections from investigation I did back in 2013 when I was writing the first serious Rust HTTP library.)

Re: How to win at CORS

#70

Post by fadikhadra »

jaffathecake wrote: post #64

Bonus fact: I wanted the 'app' ( https://jakearchibald.com/2021/cors/playground/ ) to allow the HTTP method to be set to anything, which meant I needed a server that could accept anything. I usually use NodeJS, but it turns out the HTTP library they use turns the HTTP method into an enum, so only a subset is supported ( https://github.com/nodejs/node/blob/d798de1c653efa5ec0015d44... ). This restriction only exists in…

Hey Jake, would love to see this topic discussed in HTTP 203!
Post reply on HN