Cybersecurity glossary
What is HTTP Parameter Pollution (HPP)?
Learn what HTTP Parameter Pollution (HPP) is, how duplicate query and body parameters confuse parsers, why WAFs and frameworks disagree on precedence, and how to validate input safely.
Definition
HTTP Parameter Pollution (HPP) is an attack technique that submits duplicate or split HTTP parameters—often in the query string or form body—to exploit inconsistent parsing between proxies, frameworks, and backends, bypassing filters or altering application logic.
Why HPP matters
Web platforms are stacks of parsers. The CDN, WAF, API gateway, framework, and microservice each receive the same HTTP message—and may disagree on what ?user=alice&user=attacker means.
HTTP Parameter Pollution (HPP) weaponizes that disagreement. Attackers duplicate, reorder, or split parameters so defensive layers see a benign value while business logic acts on a malicious one. The result can be WAF bypass, open redirects, or privilege changes without classic injection syntax.
How HPP works
An attacker crafts a request with repeated parameter names or encodings that survive normalization differently per hop. Downstream code reads whichever instance its library chooses—often not the same one security tools inspected.
Attacker crafts polluted URL
Duplicate keys, mixed encoding, or query/body overlap target ambiguous handlers.
Edge security inspects one view
WAF or proxy may evaluate first, last, or concatenated values depending on config.
Framework parses differently
Application code binds another instance to variables used in authorization or redirects.
Logic branch diverges
Filters pass while business rules execute on the attacker-chosen value.
Impact realized
Bypass, open redirect, mass assignment, or cache poisoning follow from the mismatch.
Forensics show subtle URLs
Logs may record only one parameter value, hiding the duplicate in incident review.
Common HPP techniques
Duplicate query keys
role=user&role=admin—frameworks disagree on first vs last precedence.
Query and body overlap
Same name in query string and POST body; servers may merge unpredictably.
Array syntax confusion
id[]=1&id[]=2 vs id=1&id=2 parsed differently across stacks.
Encoding tricks
Mixed percent-encoding or semicolon separators alter what each parser sees.
Redirect parameters
next=safe&next=evil where validation reads a different instance than redirect().
Gateway normalization
API gateway collapses duplicates before the origin microservice sees the raw request.
Parser behavior across layers
| Layer | HPP risk | Mitigation |
|---|---|---|
| WAF rule engine | Inspects first value only | Normalize duplicates before inspection; alert on repeats |
| Reverse proxy | Rewrites query order | Preserve original order; document normalization |
| Node / Express | query may object-map last-wins | Reject duplicates on sensitive keys |
| PHP $_GET | Last value typically wins | Explicit allowlists; avoid relying on superglobal order |
| Java Servlet | getParameter returns first; getParameterValues returns all | Use getParameterValues and enforce single value |
| JSON REST API | Lower unless form-encoded gateways sit in front | Accept application/json only on mutation routes |
HPP prevention checklist
- Define one canonical parsing rule for duplicate parameter names and enforce it at the edge.
- Reject requests with duplicate keys on security-sensitive fields such as role, price, and redirect.
- Align WAF, API gateway, and application framework on first-wins vs last-wins behavior.
- Prefer JSON bodies with schema validation for APIs instead of ambiguous form fields.
- Use allowlists for redirect targets; never trust a url parameter without server-side mapping.
- Log all values when duplicates are detected to support detection and incident response.
- Test OAuth and SSO callbacks with polluted state and redirect_uri parameters.
- Document framework defaults in code reviews so new endpoints inherit safe parsing.
Limits and pitfalls
HPP is context-dependent. A duplicate page=2 on a read-only listing may be harmless; the same pattern on isAdmin=true is not. Prevention is about sensitive parameters and consistent stacks, not banning all repeated keys globally.
Structured JSON reduces but does not eliminate risk. Gateways that translate JSON to form data reintroduce ambiguity. Test the full path, not only the framework handler.
The practical takeaway
HTTP Parameter Pollution (HPP) exploits inconsistent handling of duplicate HTTP parameters across security tools and application code. It is a logic and parser alignment problem that enables bypasses without exotic payloads.
Canonicalize input once, reject ambiguous duplicates on critical fields, and verify that your WAF and framework read the same value—because the attacker only needs one layer to disagree.
Related security terms
Cross-Site Request Forgery (CSRF)
Cross-site abuse that HPP can amplify when servers trust the wrong parameter instance.
Open Redirect
Redirect flaws attackers sometimes trigger by polluting url or next parameters.
Business Logic Flaws
Category of bugs HPP exploits when price, role, or state parameters are mishandled.
API Abuse
Broader misuse of endpoints where ambiguous parameter handling enables abuse.
Frequently asked questions
What is HPP in simple terms?
HPP happens when an attacker sends the same parameter name twice—like id=1&id=2—and different parts of the stack pick different values. If a WAF sees one value and the app uses another, filters can be bypassed.
Where does parameter pollution appear?
Most often in query strings and application/x-www-form-urlencoded bodies. JSON APIs are less affected unless they are converted to form data at a gateway. HTTP/2 header splitting is a related but distinct class.
Why do frameworks parse duplicates differently?
Some take the first value, some the last, some collect arrays, and some concatenate. Proxies and caches may normalize URLs differently than the origin framework.
Can HPP bypass a WAF?
Yes. If the WAF inspects only the first role=guest while the application reads the last role=admin, an attacker slips malicious input past the filter. Consistent canonicalization across layers prevents this.
Is HPP the same as SQL injection?
No. HPP is about ambiguous parameter handling and logic confusion. It may enable injection or authorization bugs but is not itself SQL syntax abuse.
How do you prevent HPP?
Reject duplicate keys where semantics are singular, canonicalize parameters once at the edge, align framework and WAF parsing rules, and use structured JSON with schema validation for sensitive APIs.
References
Explore authoritative guidance and frameworks related to http parameter pollution (hpp).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.