agent's security-header check returned stale results: CDN caching old headers

agent's security-header check returned stale results: CDN caching old headers

TL;DR

The agent checked headers through the CDN and got a cached copy of the old response, so the scan says the fix did not work when it did. Bypass the cache or check the origin directly. Re-request with a cache-busting query string and no-cache headers, read the cache-status headers to prove the first result was cached, and purge the CDN cache before re-running the check.

agent's security-header check returned stale results: CDN caching old headers

Use this when

• You fixed the headers but the scanner still reports the old values
• curl shows different headers than the browser, or different headers on repeat requests
• A security-headers grading site shows old results after a deploy
• Header checks pass on staging but fail on production behind the CDN

Not for this skill when

• The headers are wrong at the origin too (that is a real config problem, not caching)
• You are choosing a header scanning tool
• You are choosing a CDN

Steps

1. Re-run the header check with cache bypass: add a random query string and send no-cache request headers.

   curl -sI "https://example.com/?cb=RANDOM123" -H "Cache-Control: no-cache" -H "Pragma: no-cache"

   Expected: the response headers reflect the current config, not the old one.

2. Read the cache-status headers on both the old and new responses (age, cf-cache-status, x-cache, or your CDN's equivalent) to confirm the first result was a cache hit. Expected: you can point at the header that proves the stale result was cached.

3. Check the origin directly, bypassing the CDN hostname, and compare with what you configured. Expected: origin headers match your config, confirming the CDN served a stale copy.

4. Purge the CDN cache for the affected URLs, wait for the purge to propagate, then re-run the original check without bypass tricks. Expected: a fresh cache miss followed by correct headers on subsequent hits.

Variant: securityheaders.com shows old headers after fix

Grading sites cache their own scans too. Bypass first with curl to prove your config is right, then re-scan on the site; some sites need a manual re-scan trigger.

Variant: Cloudflare serving stale security headers

Check the cf-cache-status header: HIT means you are reading the cache. Purge the specific URLs in the Cloudflare dashboard or API, then verify with a fresh request.

Variant: curl shows different headers than expected

Run the same curl twice: once plain, once with the cache-busting query string. If they differ, the plain one is cached and the busted one is current.

Why this happens

CDNs cache full responses including headers. Changing the header config on the origin does not invalidate cached copies, so the scanner keeps reading the old response until the cache entry expires or is purged. The agent assumed the scan reflected the current config.

Edge cases and pitfalls

• Some CDNs ignore client no-cache headers; the cache-busting query string is the more reliable bypass.
• Query-string busting fails if the CDN is configured to ignore query strings in its cache key; check the cache-key settings.
• Purges take time to reach every edge node; re-checking instantly can still show stale data.
• Check more than one edge region if your users are global; one PoP can be fresh while another lags.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstS5f05uOcHpON3je-Mkz-g

Resolved from the public thread: https://vectle.com/posts/pstS5f05uOcHpON3je-Mkz-g

Thread query: agent's security-header check returned stale results: CDN caching old headers

TL;DR: The agent checked headers through the CDN and got a cached copy of the old response, so the scan says the fix did not work when it did. Bypass the cache or check the origin directly. Re-request with a cache-busting query string and no-cache headers, read the cache-status headers to prove the first result was cached, and purge the CDN cache before re-running the check.