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

Cache your CORS

httptoolkit.tech

Post reply on HN
Print view View original

111–118 of 118 posts

Re: Cache your CORS

#111

Post by unwind »

stblack wrote: post #85
unwind wrote: post #19

CORS = Cross-Origin Resource Sharing. There, that wasn't so hard, was it? I assume this is written for web developers who find this the most familiar acronym in the world, but ... still, it would not kill anybody to include the definition of the acronym, perhaps even with a friendly link [1] to make it Even More Accessible. I'll be off looking at the lawn mowing robot, now. [1]: https://developer.mozilla.org/en-US/do…

Downvotes for a comment like this is really the low-side of Hacker News. Me: web developer since 1996. I had to look it up. Came here to make the same comment, and see you being lambasted for it. Don't let these haterz get you down. It's standard practice across ALL domains to define acronyms, and those who give this article a pass because ReASonS!! aren't people I'd willingly choose to work with: anglo-saxons who be…

Yeah, thanks for the support.

I guess I need to work on my tone, less snark more helpful. It's a bit comforting at least that people like you exist, who are web developers but still didn't know this one. :)

Re: Cache your CORS

#112

Post by cakoose »

three14 wrote: post #43
cakoose wrote: post #8

Unfortunately this caching is still per-path. For example: GET /v1/document/{document-id}/comments/{comment-id} For every new document-id or comment-id, there will be a new pre-flight request. Alternative hacks: Offer a variant of your API format that either 1. Moves the resource path to the request body (or to a header that is included in "Vary"). Though the rest of your stack (load balancing, observability, redacti…

To hijack the thread a bit, if you are still with Dropbox, could you get them to implement what you did in #2 in the official Dropbox JS SDK? Right now it still does a pre-flight request for everything.

No, I left Dropbox 5 years ago.

But it might be easy to add? https://github.com/dropbox/dropbox-sdk-js/blob/main/src/drop...

Make sure to always set the URL parameter "reject_cors_preflight=true", which will make sure you're not inadvertently triggering pre-flight requests.

Re: Cache your CORS

#113

Post by cakoose »

Cthulhu_ wrote: post #33
cakoose wrote: post #8

Unfortunately this caching is still per-path. For example: GET /v1/document/{document-id}/comments/{comment-id} For every new document-id or comment-id, there will be a new pre-flight request. Alternative hacks: Offer a variant of your API format that either 1. Moves the resource path to the request body (or to a header that is included in "Vary"). Though the rest of your stack (load balancing, observability, redacti…

3. Don't allow cross-platform requests in the first place; have your API consumers go through a server-side proxy on the same domain instead, or host it on the same domain in the first place.

> 3. Don't allow cross-platform requests in the first place; have your API consumers go through a server-side proxy on the same domain instead, or host it on the same domain in the first place.

That works for first-party JS. Doesn't work for a public API used by others.

Edit: Specifically purely client-side apps. For someone hosting a static HTML+JS app, it's annoying to have to set up and run a server-side route just to circumvent CORS.

(Maybe not so bad with something like Next.js, where it's easy to add a backend route to your primarily static website.)

And it adds an extra hop of latency to every request.

Re: Cache your CORS

#114

Post by zmxz »

LunaSea wrote: post #98
zmxz wrote: post #97

Earlier quoted context omitted.

They're not, but you're blatantly refusing to read what's being written. Public CDN should never be trusted. If you use a CDN in the first place and have strict security requirements, then you create your own private CDN. And if you can control that private CDN, you have all the ingredients to avoid CORS. It's really that simple. No one is saying you are wrong, but you're refusing to look at the entire picture and yo…

So your point is that there is no reason to not serve everything behind the same origin, it only requires setting up a full fledged CDN to do so. I'm sorry but that's simply not an acceptable constraint.

I'm sorry that we ended up discussing this because all you did was invent situations and argued with people who didn't even state any of what you managed to read.

No one is telling you not to deal with CORS your way. Fact of the matter is that you can avoid it, but you're making up reasons why you can't. The only reason you can't is because you won't. You're free to use whatever approach you like, there's no police here, just don't state that I or anyone else wrote what we didn't. It'd be grown up thing to do. Thanks and best of success with your projects.

Re: Cache your CORS

#115

Post by javier2 »

tomjakubowski wrote: post #102
javier2 wrote: post #91

Earlier quoted context omitted.

Well, you double the latency for every. single. request.

CORS does not double latency for every single request. It adds the additional overhead of a separate OPTIONS request for every single request. Unless the responses are as trivial to compute/serve as OPTIONS responses are, that will be way less than a doubling in latency.

What I mean by latency is the transport latency, even assuming 0ms OPTIONS compute time, you still need twice the round trip time.

Re: Cache your CORS

#116

Post by LanceH »

javier2 wrote: post #90
LanceH wrote: post #79

Earlier quoted context omitted.

CORS is one of my favorite interview questions (front-end/react dev) as it has the potential to tell me if the interviewee is the person who has researched the problem and implemented solutions. There is a lot of potential discussion from how it works, why it's necessary, to how it is solved in production vs development.

CORS is something I 'fixed' once, five years ago. Hard to talk in detail about that anymore. I wish we would have the time to implement it safely, but alas. We still can't produce an allowList of allowed domains :/

> CORS is something I 'fixed' once, five years ago

I'm careful that I don't demand anyone go into depth on any particular subject. CORS is just one opportunity that seems to need a fix with every new project. It also has a variety of solutions, which is again opportunity to show what they know.

There is little point in looking for what a client doesn't know. I've got that covered.

Re: Cache your CORS

#117

Post by snowwrestler »

LunaSea wrote: post #95
snowwrestler wrote: post #80

Earlier quoted context omitted.

Are you sure about that? Have you talked to a good lawyer about it?

This is not necessarily only a legal issue it's also an information security issue. You can't guarantee the integrity and privacy of the full request and response chain. This goes against various security standards and ISOs. You might be able to get away with it and trust the CDN but that's an awful lot of trust.

Unless you are terminating TLS entirely on owned hardware, you are paying a 3rd party to manage TLS for you.

A lot of people seem to think that there is a big difference between paying a lessor (e.g. Hetzner) for a server on which you terminate TLS, paying a cloud host (e.g. Amazon) to terminate TLS, and paying a CDN (e.g. Fastly) to terminate TLS. Legally there is no difference aside from the specific language of the contracts, which you can review and negotiate in advance.

The difference security-wise is entirely down to the operations of each company, which again you can review and discuss in advance. Strictly speaking a CDN should have lower risk than a host since they are not persisting sensitive data (if you set your cache headers correctly). And as discussed above, using one domain helps avoids cross-domain security concerns.

Re: Cache your CORS

#118

Post by zemnmez »

nmjenkins wrote: post #39
zemnmez wrote: post #22

Access-Control-Max-Age has, unfortunately a big security caveat which is that it is cached on a per-endpoint basis. Because Access-Control-Allow-Origin only allows one origin specification, if you previously used the Origin header to determine who could access the API, your next API requestor will effectively get your last response. For example, to allow abc.com AND bcd.com, you could check Origin and if correct retu…

This is because you have forgotten to return a `Vary: Origin` header in the response. If you don’t do this, caches will presume the response is the same regardless of the Origin header in the request and so you will get the bug you describe.

Vary has no effect on the cors preflight cache: https://stackoverflow.com/questions/42848208/cors-preflight-...
Post reply on HN