HTTP parameter pollution

When it applies

A request passes through more than one component that parses parameters — a WAF/gateway, then the app; or a frontend that builds a backend request. If they resolve a duplicated parameter differently, you can show one value to the guard and another to the logic.

Why it works

There is no single rule for ?x=a&x=b: PHP/Apache take the last, ASP/IIS concatenates (a,b), classic JSP takes the first, Node/Express makes an array. When the validator and the consumer sit on different stacks, a value that passes validation isn't the value that's used.

Method

1. Map the parsing: send ?p=1&p=2 (and body dups) and observe which value the response reflects or acts on — that tells you first/last/concat/array.
2. Split a blocked payload: if a WAF blocks q=<svg onload=..>, try q=<svg&q=onload=..> where the backend concatenates — the signature never appears whole to the WAF.
3. Override server-side params: append your own copy of a param the app also sets internally (e.g. role, amount, redirect_uri) so your last-wins value overrides the trusted one.
4. Access control / logic: pollute IDs or flags where the auth check reads one occurrence and the data layer reads another.
5. Client-side HPP: when a link/form is built from your input, inject &-encoded params to add fields to the generated request.

Gotchas

• Behaviour is stack-specific — always confirm the parsing empirically before relying on it.
• Body vs query vs path params may parse differently in the same app; test each channel.
• Concatenation (a,b) can corrupt the payload — order the duplicates to land valid syntax.

Verify success

The duplicated parameter produces a different outcome than the single one — a filter is bypassed, an internal value overridden, or a logic/authz decision changes — reproducibly.

References

OWASP Testing Guide (HPP); PortSwigger notes on parameter parsing; framework parameter-precedence tables.