Home / Knowledge hub / HTTP parameter pollution
Knowledge hub
HTTP parameter pollution
Sending the same parameter twice so different layers read different values.
What it means
HTTP parameter pollution (HPP) means sending the same parameter more than once, such as id=1&id=2. The HTTP standard does not say which value an application must use, so frameworks differ. Some take the first, some take the last, and some join them together.
The trouble starts when two components disagree. A filter in front of the app reads one value and the app behind it reads another. The check passes on the harmless copy, and the action runs on the other. That gap between two readers of the same request is the entire attack.
Why it matters
It can turn a rule that looks sound into one that is not. A firewall or WAF rule that checks the first value is useless if the application uses the last. A payment request, a transfer or a permission change can pass validation and then act on different data.
It also shows up when your server calls another service and copies user input into the new request. A duplicated parameter can then change what that downstream call does, which is a close cousin of header injection. The pattern is the same each time: one component approves, another acts.
How it shows up
You meet it in query strings, form bodies and any proxy or gateway sitting in front of an app. A common case is a signed or validated request where the signature covers one copy of a field and the handler reads the other. Another is a URL built by pasting user input in.
To check, send duplicates in different orders and see which one wins at each layer. Then fix it by deciding on one rule everywhere: reject requests with repeated parameters you did not expect, and read parameters in a single place in your code.
Questions people ask
HTTP parameter pollution, answered
Does HTTP forbid repeated parameters?
No. The standard allows a query string to repeat names, and it leaves the meaning to the application. That is the whole reason the problem exists.
Frameworks simply made different choices.
Which value does my framework use?
It depends on the framework and version. Some read the first value, some the last, and some return all values as a list or a comma-joined string.
Test your own stack rather than trusting a table from the internet.
Is it the same as parameter tampering?
They are related. Tampering changes a value the user should not control. Pollution adds a second copy of a value so that different layers disagree about which one counts.
Both come from trusting what the client sends.
Can a WAF stop it?
Only in part. A WAF that reads a different copy from your app can be the very thing that gets fooled.
The reliable fix is to refuse unexpected duplicates in the application itself.
How do we test for it?
Repeat each parameter with different values and in different positions, in the query string and in the body. Watch what the response, the logs and any downstream calls show.
A change in behaviour tells you where two components disagree.
Sources
Where this comes from
Related
Terms that sit next to this one
Parameter tampering
Changing values in a request, such as a price or an id, to alter what happens.
WAF
A filter in front of your application that blocks known bad requests.
Input validation
Checking that what arrives is the shape and range you expected.
HTTP header injection
Slipping line breaks into input so an attacker adds headers to your response.
Untrusted input
Anything that arrived from outside your own code, and is therefore suspect.
Which copy does your app believe?
Repeated parameters, mixed query and body values, and checks that read a different copy than the action does are all things we try. Findings arrive with the request that proved them. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.