Cache analysis

01What the Cache lens is (and isn't)

The Cache page (sidebar, under PAGES) is a passive analyzer that runs over your project's captured History. It groups requests by endpoint, reads the cache-relevant headers on each response, and scores the result for cache-related risk. Nothing on this screen touches the network: the topbar pills read observed only, 0 probes, and nothing sent, and the stats band says all data observed / 0 probes sent. That is the literal behavior — the screen only ever looks at bytes the proxy already saw.

Because it's observational, it's part of Crusader's Free tier — a real daily driver, not a teaser. The trade-off is honest: this is an indicators-and-triage tool. It cannot prove a caching bug on its own, because proving one means re-issuing a request (as a second user, from a clean session, or with an attacker-controlled header) and watching what the cache does. Crusader leaves that step to you — every finding ships with a SAFE CONFIRMATION checklist and a 0 requests sent label so there's no ambiguity about what's been verified.

02What it surfaces

For every endpoint with cache evidence, Crusader parses the response headers and derives three things: whether the response is cacheable, whether it was actually served from a shared cache, and whether that's a problem given what the request carried. The raw signals it reads:

From those it raises scored risk classes. The ones worth knowing:

• Public + auth'd — a sensitive response went out Cache-Control: public while the request carried a real credential. Classic shared-cache leak setup.
• No Vary on auth — a sensitive, shared-cacheable response whose Vary doesn't cover Cookie, Authorization, or the API-key header it was keyed by.
• Identity crossing — the same response body signature was observed behind two different real credentials. The strongest pre-confirmation signal that one user can receive another's cached object.
• Cache deception candidate — a static-looking path (or a ;/%2e/.. trick) returned dynamic private HTML or JSON.
• ACAO unkeyed — Access-Control-Allow-Origin reflects the request Origin on a cacheable response that doesn't Vary: Origin.
• Header-poison candidate — a routing header (X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-Prefix, X-Host, X-Original-URL, Forwarded, …) was present on a cacheable response and isn't in Vary — or its value was reflected into Location / CORS.
• Plus: Set-Cookie on a shared-cacheable response, GraphQL cache risk, Next.js/RSC variant, partial-fragment (HTMX/Turbo/Inertia), OAuth/SAML cache, cached redirect poison, ETag cross-identity, HEAD/GET confusion, and route-family signature collision.

03Open it and read the board

Capture some authenticated traffic first — browse the target through Crusader's proxy while logged in, ideally as more than one account, so the lens has identities to compare. Then open Cache from the sidebar.

The header reads N cacheable URLs, observed. with stat tiles for CACHEABLE URLS, LAYERS, AGE RESETS / HR, IDENTITY CROSS, WORTH A LOOK, and ASSETS HIDDEN. Below that, filter chips narrow the list:

You can also group the list by Layer, TTL, Host, or None, and search by URL, host, or header. Start on Findings or Identity crossing — that's where the reportable bugs cluster.

04Triage a finding

Click any entry to open the detail panel on the right. It's built for exactly one decision: is this worth a manual replay? The sections, top to bottom:

• Cache finding — severity (Critical / High / Medium / Low / Info), a 0–100 score, the evidence strings, and a SAFE CONFIRMATION list of read-only steps to prove it.
• Proof lane — the best observed auth → anonymous pair for this URL, with whether the two responses share a signature, fell inside the TTL window, and showed a cache HIT. This is the report-grade path.
• Header evidence — the raw cache and auth headers pulled from History (request + response), so you're reading ground truth, not a paraphrase.
• Cache topology — a You → CDN → Origin chain with the hop that's hot, plus the trust-boundary note (e.g. "public was observed on a request that carried authentication").
• Cache key (inferred) — two columns: inputs that changed the response ("appears keyed") vs. inputs that varied while the response stayed identical ("same public response across variants"). The second column is your unkeyed-input shortlist. Labelled 0 requests sent — this is inferred from captures, not probed.
• Identity / Stranger / Timing — who hit the entry, the cross-session pairing, and the Age timeline.

The detail header carries the actions you'll actually use: Repeater (send the captured request straight to a tab to replay it), Proof pack (copy a full text report — URL, layer, status, identities, age resets, evidence, the auth/stranger pair, inferred key signals, and the raw cache headers), History, Popout, and Ignore.

05Web cache deception

Web cache deception is when a static-looking URL — /account/settings.css, /api/me;.js, a %2e-encoded path — is treated as cacheable by the CDN but served dynamic, private content by the origin. The cache then stores one user's private page under a URL anyone can request.

Crusader flags these as cache deception candidates: it spots a static extension or path trick (;, %2e, %2f, ..) on a response that was actually HTML- or structured-content, carried a real credential, and shows shared-cache risk evidence. Crusader's scanner has a matching passive module (web-cache-passive) that goes further on the body: when a static-extension path returns dynamic content, it scans for per-user markers — emails, names, user/tenant IDs, JWTs, session cookies, API keys — and rates confidence by whether the response was an observed cache HIT and whether the leaked value is credential-like.

The confirm step is always the same shape: in Repeater, append a harmless static suffix variant to the private URL and check whether the private HTML/JSON becomes cacheable and is then served from cache to a clean client.

06Cache poisoning candidates

Cache poisoning is the inverse: an attacker sends a request with an unkeyed input — a routing header the cache ignores when building its key — that changes the cached response everyone else then receives. The classic vector is X-Forwarded-Host rewriting an absolute URL in the page, but redirects, CORS headers, CSP, and script sources are all in play.

Crusader surfaces this as a header-poison candidate when a cacheable response (a) carried one of the routing headers it watches and that header isn't in Vary, or (b) reflected that header's value into Location or Access-Control-Allow-Origin. The scanner module reports the same class — it extracts the reflected value, checks it actually appears in the body (raw, URL-encoded, or HTML-encoded), and labels the result explicitly:

# scanner verdict for an unkeyed-header poisoning candidate
X-Forwarded-Host value `evil.example` appears in a cacheable
response, and Vary does not include X-Forwarded-Host. This is a
passive-only indicator: replay with an attacker-controlled value
to confirm whether the shared cache absorbs it.

There is no active cache-poisoning engine. Crusader will not send a poisoned request, will not plant a payload, and will not auto-verify the bug — by design. It points you at the surface; you prove it.

07Confirm it for real

Indicators become findings when you reproduce them. The repeatable loop, all of it Free:

1. On the finding, read the SAFE CONFIRMATION steps and copy the Proof pack for your notes.
2. Click Repeater to load the captured request into a tab.
3. Prime as one identity, replay as another. For a cross-user leak: send as Identity A, then set the tab's identity to B (or strip auth entirely) and send the same URL with no cache buster. Compare status, body hash, ETag, Age, and any A-specific markers. For deception: add the static suffix and check whether private content becomes cacheable. For poisoning: send your unique routing-header value, then re-request as a clean client and see whether your value persists in the cached response.
4. If the cached object crosses the trust boundary, you have a real bug. Promote it into your report from the proof pack.

A few honesty notes to keep your reports clean: the inferred cache-key columns are derived from observed captures, not active probing, so treat them as leads to test rather than proof. Vary-based reasoning assumes the upstream honors it. And matching to your saved Identities sharpens the "real credential vs. analytics cookie" call — set those up on Target scope / Identities before a long session so crossings are scored accurately.

For chained or active follow-up — turning a cache-deception leak into an authorization finding, or running the broader passive scanner across the whole project — see the scanner guide. The passive scanner (including the web-cache module) is Free; active proof replay for the classes that support it is Hunter Pro, and authorized-targets-only.

Want a guide that isn't here yet? Email hello@crusaderproxy.com.