HTTP Parameter Pollution
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints.tools list includes semgrep, owasp-zap, and burpsuite — all specialist security tools requiring deliberate configuration and testing. Standard linters and compilers won't surface duplicate parameter handling issues; active security scanning or manual code review is required to detect the misuse.
Closest to 'simple parameterised fix' (e3). The quick_fix describes explicitly normalising how $_GET and $_POST values are consumed — always taking the first or last value deliberately. This is a small, localised code change at each parameter access point rather than a single one-liner, but it doesn't require cross-file architectural changes. Common mistakes point to a pattern-level fix (deduplication/normalisation at ingestion) applied within one component.
Closest to 'localised tax' (b3). The applies_to scope is web and API contexts, which is fairly broad, but the actual debt is localised — it manifests at input handling boundaries rather than spreading across the entire codebase. Teams need to be aware of parameter parsing conventions, but the remediation doesn't impose a persistent productivity tax on unrelated work streams.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field explicitly captures this: developers assume duplicate parameters are either ignored or follow a universal 'last wins' rule, but behaviour is inconsistent across runtimes and components (PHP uses last, some WAFs check first). This contradiction between how the WAF and the application parse the same URL is a documented cross-system gotcha that directly enables security bypass — a competent developer would confidently guess wrong about the parsing behaviour.
Also Known As
TL;DR
Explanation
HTTP Parameter Pollution (HPP) sends the same parameter multiple times in a request (?id=1&id=2). Different frameworks handle this differently — PHP uses the last value, others use the first, some concatenate. Attackers exploit these inconsistencies to bypass WAF rules, override security parameters, or manipulate application logic that processes parameters differently at different layers. Prevention: explicitly choose which occurrence of a duplicated parameter to use and document that choice.
Common Misconception
Why It Matters
Common Mistakes
- Assuming $_GET['param'] is always a single value — PHP treats param[]=a¶m[]=b as an array.
- Security filters that inspect one instance while the application processes another.
- Constructing URLs from user input and not normalising duplicate parameters before passing to downstream services.
- WAF rules that check the first occurrence of a parameter while the backend processes the last.
Code Examples
// PHP uses last value for duplicate params
// ?role=user&role=admin → $_GET['role'] = 'admin'
$role = $_GET['role']; // silently picks 'admin'// Validate after parsing — don't assume only one value arrived
$role = $_GET['role'] ?? 'user';
if (!in_array($role, ['user', 'editor'], true)) {
$role = 'user'; // safe default
}
// Awareness: different frameworks handle duplicate params differently
// PHP: last value wins | Flask: first value wins | ASP.NET: comma-joins
// Always validate the result, regardless of framework