Often yes. A fix you have deployed does not reach visitors while a cache still serves the old file. After a security change, purge the affected paths, confirm the new content is served from the edge, and check that old copies are not kept by browsers or other shared caches.
Why it matters
A CDN is a shared cache sitting between your origin and visitors. MDN describes a shared cache as one that stores a single response and reuses it for many users, and notes that the s-maxage directive sets how long a response stays fresh in shared caches. If you patched a vulnerable script and its cached copy lives for a day or a week, visitors keep getting the vulnerable file until it expires or you purge.
Browsers cache too. A response marked for a long max-age can sit on a visitor's device regardless of what the edge does.
Steps
- Identify what changed. List every URL whose content or headers changed: scripts, HTML pages, config files, redirect rules.
- Check how each is cached. Look at the Cache-Control header on those URLs. Note s-maxage, max-age and any immutable directive.
- Deploy the fix. Ship the change to the origin or the static host.
- Purge. Use your CDN's purge feature for the exact paths, or a version tag if it supports one. A full purge is a blunt tool and causes a burst of origin requests, so prefer targeted purges for a small change.
- Verify at the edge. Request the file with curl and read the response. Confirm the content changed, and check any cache status header your CDN sets.
- Verify from outside. Test from a different network or region if your CDN has many edge locations, since purges can take time to propagate.
- Handle browser copies. If the old file was cached with a long lifetime, a purge will not reach browsers. Change the file name, usually by including a content hash, so pages request a new URL.
- Record it. Note the time of deploy, time of purge and the verification result in the incident or change ticket.
Make the next fix easier
| Practice | Benefit |
|---|---|
| Content-hashed file names for scripts and styles | A new version gets a new URL, no purge needed |
| Long cache for hashed files, short for HTML | Fast pages and quick rollouts |
| Never cache private or personalised responses in shared caches | Avoids serving one person's data to another |
| Keep HTML short-lived or revalidated | Pages pick up new file names promptly |
MDN warns that personalised content should not be stored in shared caches, because one stored response is reused for many users. Use the private directive or no-store for anything tied to a person.
Do not forget what else holds copies
Search engine caches, web archives and third-party mirrors may keep old versions. For a leaked secret, rotating the secret matters far more than purging, because you cannot recall every copy.
Try it yourself
The fix-available demo shows a vulnerable package moving to a fixed version. Notice that the fix is not complete until the new version is what actually runs, which on a CDN site means what is actually served.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard can find the vulnerable dependency and raise a fix pull request when you enable that option. Purging and verification remain steps in your own release process. Free scan: gold.safeguard.sh/scan.
Quick check
Is a purge enough if a secret was exposed?
No. Rotate the secret. Copies may exist outside your cache.
Why use hashed file names?
Each release gets a new URL, so no cache can serve a stale version of it.
Sources
- MDN, Cache-Control header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control
Last reviewed: 19 October 2026.
