HTTP Parameter Pollution: How Duplicate Parameters Break Application Security Logic

What Is HTTP Parameter Pollution?

HTTP Parameter Pollution (HPP) happens when a web application receives multiple values for the same parameter name and processes them in ways the developer didn’t anticipate. The HTTP specification doesn’t define what to do with duplicate parameters — different frameworks, servers, and intermediary systems each make their own choice, and those choices don’t agree.

Send GET /search?role=user&role=admin to your application and what happens? Your framework might return the first value (user), the last value (admin), an array of both (["user", "admin"]), or a concatenated string (user,admin). If your authorisation check only sees user, but your downstream service sees admin, you have a problem.

How Different Frameworks Handle Duplicate Parameters

The inconsistency is the attack surface. Here’s how common backends behave by default:

Platform	Duplicate GET param behavior
PHP	Last value wins ($_GET['x'] = last)
Node.js (Express / qs)	Array (req.query.x = ['a','b'])
Python (Django)	Last value wins (request.GET.get('x') = last)
Python (Flask)	First value wins (request.args.get('x') = first)
ASP.NET	Comma-joined string ("a,b")
Java (Servlet)	Array (request.getParameterValues("x"))
Ruby on Rails	Last value wins
Apache Tomcat	First value wins

This matters because your application stack is rarely a single technology. A request might pass through a WAF, a CDN edge, a reverse proxy, and then your application server — each with different duplicate parameter handling. An attacker who understands the table above can craft payloads that look safe to the intermediary but execute maliciously at the destination.

Attack Scenarios

WAF Bypass

Web Application Firewalls typically inspect individual parameter values. If your WAF checks each parameter value independently and stops at the first clean value, splitting a payload across two instances of the same parameter can bypass signature matching.

Assume a WAF blocks q=<script>alert(1)</script>. With HPP:

GET /search?q=hello&q=<script>alert(1)</script>

If the WAF inspects only the first occurrence (hello, which is clean) and the application uses the last value (<script>alert(1)</script>), the XSS payload reaches the application unblocked. Whether this works depends heavily on the specific WAF and application framework — but it’s a documented bypass technique against WAFs that don’t normalise duplicate parameters before inspection.

For SQL injection, a similar split approach can work when the WAF checks values individually. The technique is most reliable when you know the WAF processes one value and the backend aggregates them differently.

OAuth and Authentication Flow Manipulation

OAuth flows frequently use redirect_uri parameters to control where the authorisation server sends the user after authentication. Duplicate redirect_uri parameters can manipulate this:

GET /oauth/authorize
  ?client_id=legit_app
  &redirect_uri=https://legitimate.com/callback
  &redirect_uri=https://attacker.com/steal
  &response_type=code
  &scope=read

If the authorisation server validates only the first redirect_uri but redirects to the last, an attacker can redirect the authorisation code to their own endpoint. This is a real vulnerability class — CVE entries exist for OAuth implementations that failed to handle this correctly in major identity providers.

Similar patterns apply to state parameters (CSRF protection bypass), scope parameters (privilege escalation), and response_type parameters.

Backend Logic Abuse

Consider an e-commerce application that processes discounts:

POST /checkout
item_id=12345&discount_code=SUMMER10&discount_code=STAFF50

If the checkout handler iterates over all discount codes and applies each, an attacker might stack discounts that should be mutually exclusive. If the backend validates only one code but applies all, the result is unintended price reduction. This category of HPP attack is highly application-specific — whether it works depends entirely on how the backend processes multiple values.

Server-Side Request Forgery via HPP

In applications where user-controlled parameters are assembled into internal requests, HPP can inject additional parameters:

GET /proxy?url=https://internal.api/data&url=https://attacker.com/data

If the proxy concatenates the URL values or takes the last, and the proxied service is the internal API, this can redirect the proxied request to attacker-controlled infrastructure.

Detection and Testing

Manual testing for HPP:

1. Identify all input parameters — query string, POST body, cookies, JSON properties (though JSON has defined handling for duplicate keys)
2. Duplicate each parameter and observe application behaviour — does the response change? Does it error?
3. Test different positions — first-wins and last-wins are the most common, but try both orderings
4. Test server vs. client handling — if client-side code processes the parameter differently from server-side code, there may be a discrepancy worth exploiting

Automated tools including Burp Suite’s active scan and OWASP’s ZAP scanner have HPP test cases, though manual testing is more reliable for business logic scenarios.

Prevention

Explicit parameter extraction: Don’t rely on your framework’s default duplicate parameter behaviour. If you expect a single value, extract it explicitly and fail loudly if duplicates are present.

# Flask — explicit single-value extraction with duplicate detection
def get_single_param(request, name):
    values = request.args.getlist(name)
    if len(values) > 1:
        abort(400, f"Duplicate parameter: {name}")
    return values[0] if values else None

// Express/Node.js — detect and reject duplicates in middleware
app.use((req, res, next) => {
    for (const [key, value] of Object.entries(req.query)) {
        if (Array.isArray(value)) {
            return res.status(400).json({ error: `Duplicate parameter: ${key}` });
        }
    }
    next();
});

WAF normalisation: Configure your WAF to normalise duplicate parameters before inspection — most enterprise WAFs support this. If your WAF applies policies after normalisation, HPP-based bypass attempts fail because the WAF and the application both see the same normalised value.

OAuth parameter handling: In OAuth authorisation servers, reject requests with duplicate redirect_uri, response_type, or state parameters outright. There is no legitimate use case for duplicating these parameters.

Input validation at boundaries: Validate inputs at every system boundary, not just at the application entry point. A downstream microservice receiving a parameter from an upstream service has no guarantee that the upstream service didn’t introduce HPP through parameter aggregation.

Security testing: Add HPP test cases to your application’s security test suite. For each parameter your application accepts, test what happens when it appears twice. If the behaviour is anything other than an explicit error or consistent use of a single value, review the handling.

HPP is in the category of vulnerabilities that look trivial but create real exploits when they align with business logic, WAF rules, or OAuth flows. The inconsistency across frameworks is the constant — your defence is removing that inconsistency by making duplicate parameter handling explicit and predictable.