Cache key & Vary
Ce contenu n’est pas encore disponible dans votre langue.
Probes what actually varies the cache key, rather than trusting the declared Vary header alone.
How it works
Section titled “How it works”For each of Accept-Encoding, Accept-Language, User-Agent, and a custom header, the check sends a request that varies only that input and compares the response against a baseline (a different cdn-detected cache-status value, or a different response body counts as “keyed”).
Why User-Agent needs special handling
cache-detective’s own probe transport (harnessx/probe) deliberately overwrites the User-Agent header on every request for consistent identification. Varying User-Agent on purpose therefore bypasses that transport for just this one probe (checkbase.DoRaw instead of checkbase.Do) — every other probe in cache-detective goes through the standard transport.
Findings
Section titled “Findings”| Finding | Severity | Meaning |
|---|---|---|
Undeclared cache-key input: <dimension> | medium | Varying this input changed the response, but it’s not declared in Vary — a cache-poisoning surface if the value is attacker-controlled |
Declared Vary dimension has no observed effect: <dimension> | info | Declared in Vary, but varying it produced no observable difference — likely inflates cache fragmentation for no benefit |
Request budget
Section titled “Request budget”This check issues extra requests to the live target but is not gated behind --aggressive — it’s read-only from the target’s point of view (it never plants content a poisoned cache would later replay; that’s Cache poisoning & deception’s job). It still respects --max-aggressive-requests as a hard cap on probe count per resource.