X-BUR
Burp Param Miner
PortSwigger's free BApp Store extension that discovers hidden, unlinked HTTP parameters and web cache poisoning vectors.
OVERVIEW
Param Miner is PortSwigger's official Burp extension (BApp Store, or github.com/PortSwigger/param-miner) for finding parameters and headers that an application reads but never exposes in its visible forms or JavaScript — a large curated wordlist is sent against a target endpoint and any request that produces a different response than the baseline is flagged as a likely hidden input.
Its 'Guess headers' and 'Guess params' scans are also the standard way to find web cache poisoning vectors: it specifically looks for unkeyed inputs (headers or parameters not part of the cache key) that change the response, which is the precondition for poisoning a shared cache. It works from within the same proxy workflow as the base Burp Suite entry on this site.
USE CASES
Practical use cases
- 01
Brute-forcing hidden request parameters an endpoint silently accepts but never renders in a visible form.
- 02
Finding unkeyed headers (X-Forwarded-Host, X-Forwarded-Scheme, etc.) that influence the response — the setup for web cache poisoning.
- 03
Surfacing debug or feature-flag parameters left enabled in production (e.g. a hidden 'admin=true' style switch).
- 04
Feeding discovered inputs back into manual testing with Repeater or an automated Intruder attack.
QUICK START
Once an endpoint is mapped, to brute-force for unlinked parameters and headers it silently accepts — a common source of cache poisoning and hidden functionality.
- Confirm the target endpoint and the volume of extra requests a full parameter/header guess will generate are within scope.
- Install Param Miner from the BApp Store.
- Send the target request to the extension (right-click > Extensions > Param Miner > Guess params / Guess headers).
- Review flagged parameters and headers, then confirm each manually in Repeater before treating it as a finding.
BEFORE YOU RUN IT
What to check before running it
A full guess scan sends a large wordlist against the target — thousands of requests — so treat it like any other volumetric scan and clear it with the client first.
Flagged differences can be noise (caching, load balancing, session state) rather than a real hidden parameter — verify manually before reporting.
Any confirmed cache-poisoning vector affects every visitor sharing that cache, not just the tester — coordinate a safe proof-of-concept that doesn't leave a poisoned response live in production.