infra-failureminorverifiedfirsthand
Adding Subresource Integrity to a tracking script — a pure security hardening change — broke production analytics the same day it shipped.
Cause: SRI requires the crossorigin attribute on cross-origin scripts, which forces the browser into CORS mode. The CDN's edge cache kept serving a cached response from before the CORS header was added, so the origin fix never reached real users until the cache was purged.
Consequence: Production click tracking stopped firing. The team had no cache-purge permission on the CDN zone, so the only fast fix was pulling the integrity/crossorigin attributes back out as a hotfix; the incident was resolved the same day.
Fix: When adding SRI to a CDN-fronted script: (1) deploy the CORS header on the origin, (2) explicitly purge the CDN cache for that URL, (3) confirm in a real browser that no CORS error appears, and only then (4) deploy the integrity/crossorigin attributes on the consuming page. Checking with curl alone isn't enough — check the cache-status header to confirm the edge actually flipped, not just the origin.
What happened
A security hardening change — adding Subresource Integrity to a cross-origin analytics script — took production tracking offline the same day it shipped.
The chaos on the ground
The origin server was fixed correctly and confirmed working locally. In production, real browsers started throwing CORS errors and the tracking pixel stopped firing. Curl checks against the origin looked fine, which made the failure confusing until someone checked the CDN’s cache-status header and found it was still serving a response cached from before the fix.
Root cause
SRI’s integrity attribute requires crossorigin, which forces the browser
to fetch the script in CORS mode. The origin had the right CORS headers, but
the CDN’s edge cache was still serving a response cached before those
headers existed (the script’s cache lifetime was 4 hours). The combination of
“new crossorigin requirement” plus “old cached response” reliably produces a
CORS block, and no amount of fixing the origin changes what’s already
cached at the edge.
The fix
The team didn’t have cache-purge permission on the CDN zone at the time, so
the fastest way out was to pull the integrity/crossorigin attributes
back out as a hotfix — the origin’s CORS headers were left in place since
they’re harmless without SRI, and SRI was re-attempted only once purge
access existed. The rollout order that avoids the outage in the first place:
ship the CORS header on the origin first, explicitly purge the CDN cache for
that exact URL, verify in a real browser that the request succeeds, and only
after that add integrity/crossorigin to the page loading the script. A
curl check against the origin only proves the origin is fixed — it says
nothing about what the edge is still serving.