Hacker News Reader

Comment by 88913527 | Hacker News Reader

I can tell you how to lose at CORS in Chrome. If your browser caches a response, and sometime later you mutate the request by adding the "Origin" header it (e.g, add attribute crossorigin="anonymous" to a <script> tag), Chrome won't make a new request. What it will do is use the cached response, which is missing the ACAO response header, and thus the browser rejects a file from its own cache via draconian security policy.

There are many ways to lose at CORS and this one is my story.

View on HN

Author here! The post covers this detail. This happens because your response is missing a Vary header.

Getting Vary right isn't just important for Chrome, it's important for CDNs too.

You're right, the real issue is CloudFront won't include Origin in the Vary response header if it wasn't included in the initial request. And if you change your HTML attributes, you're changing your request, but you essentially end up with a poisoned local cache. Rolling out crossorigin="anonymous" on previously cached assets is a subtlety you won't know about (even if you think you know CORS) until your site breaks as critical assets are missing.

Yeah, it's generally understood that you need to change the URL to cache-bust when the content changes, but it's easy to forget that you need to do the same thing if important headers change.

Hmm, I think I'll add a section to the article on this when I'm back at my laptop.

Aaaand it's done https://jakearchibald.com/2021/cors/#cors-and-caching

Thanks for prompting this!

If your data is coming from an S3 origin and the original (cached request) was not CORS (but you also want to support CORS), then you can inject the necessary headers with Lambda@Edge or CloudFront Functions.

S3 is used as an example, as it does not include a Vary header for non-CORS requests. However, the same would be true of some other origin which isn't correctly inserting a Vary header.

That works, but I found a simpler / cheaper alternative to fix this particular Cloudfront problem: Create a custom "Cache policy" that only includes the header "origin" and then the answer from Cloudfront will always include "Vary: origin", even if it wasn't in the request (That behaviour is not documented anywhere I could find, stumbled upon it by accident)

Ha, I feel your pain, I ran into something similar with Chrome and Cloudfront.

For us it got triggered because an image on the site appeared both as a video "poster" attribute (which loads with CORS) and as a regular image. So depending on which image the user encountered first you would see a CORS error. But it would be gone after a reload, so devilishly hard to reproduce until you realise what's happening.

Also took me ages to figure out that Cloudfront didn't include the Origin in the Vary header if it wasn't in the original request.

(@jaffathecake perhaps that Cloudfront behaviour warrants a special mention. Great article by the way, I learned a lot)

ServiceWorkers also don't play nice with CORS in my experience. We often need to bypass them in Angular when making certain requests.

Author here! I'm also an editor on the service worker spec, so I'm interested to know where the pain points are.

Hi Jake! (I watch your videos ;)) Many times, the (Angular) ServiceWorker has given us CORS headaches on various requests to our APIs and AWS storage files. The only method we've found, after various AWS configs and ngsw-config.json attempts, was to add `ngsw-bypass=true` to all requests. I'll see if I can find the Github issue, where this has come up before.

Incidentally, while you're here, I'm planning on building something which will require use of SharedArrayBuffer. Will adding the (now) required Cross-Origin isolation COOP/COEP headers cause any issues to existing CORS setups?

COOP+COEP won't change how CORS works, but it means you can't have no-cors resources on your page unless they have CORP headers

Very useful info. Thanks!

Reply on news.ycombinator.com