What Is HTTP Parameter Pollution? Web Security Guide | Yrzo AI

What Is HTTP Parameter Pollution?

HTTP Parameter Pollution — commonly abbreviated HPP — is a web application vulnerability that occurs when an attacker injects multiple values for the same HTTP parameter into a request. The attack exploits inconsistencies in how different web technologies parse duplicate parameters, allowing attackers to override application logic, bypass security controls, or manipulate backend behaviour in unintended ways.

The attack surface is wider than most developers expect. HPP affects query strings in GET requests, form fields in POST bodies, REST API endpoints, and any other mechanism through which user-supplied parameters reach your application. Because parameter handling behaviour varies between web servers, frameworks, and languages, the same request can be interpreted differently at different layers of your stack — and attackers exploit that gap.

How HTTP Parameter Pollution Works

Consider a simple example. A web application accepts a GET request like this:

``` GET /transfer?amount=100&to=account_B ```

An attacker crafts a modified request:

``` GET /transfer?amount=100&to=account_B&to=account_C ```

Now the `to` parameter appears twice. What happens next depends entirely on which technology processes the request:

| Technology | Behaviour with duplicate parameters | |---|---| | PHP (`$_GET`) | Last value wins → `to = account_C` | | Node.js (Express / qs) | Returns an array → `to = ["account_B", "account_C"]` | | ASP.NET | First value wins → `to = account_B` | | Java (Servlet) | First value wins → `to = account_B` | | Python (Flask) | First value wins → `to = account_B` | | Python (Django) | Last value wins → `to = account_C` | | mod_wsgi / CGI | Comma-concatenated → `to = account_B,account_C` |

The attack works because the front-end and back-end of an application often use different parsing logic. A Web Application Firewall (WAF) or input validation layer might check the first value and pass it, while the backend processes the last value — giving an attacker a way to slip a malicious value past security checks.

Types of HTTP Parameter Pollution

Server-Side HPP (SSHPP)

In server-side HPP, the attacker injects duplicate parameters that affect how the server processes the request. The web server, application framework, or database query construction picks up the attacker's injected value instead of the legitimate one.

**Example — bypassing a WAF rule:**

A WAF inspects the first occurrence of a parameter for a SQL injection payload. The attacker places a benign value first and the malicious payload second:

``` GET /search?q=shoes&q=shoes' OR '1'='1 ```

If the WAF checks only the first `q` parameter and passes the request, but the backend uses the last value, the SQL injection payload reaches the database undetected.

**Example — overriding a security parameter:**

An application passes a `role` parameter internally:

``` POST /api/update_profile role=user&name=Alice&role=admin ```

If the backend processes the last value of `role`, the attacker has escalated their privilege to admin by injecting an additional parameter after the legitimate one.

Client-Side HPP (CSHPP)

Client-side HPP occurs when a web application reflects duplicate parameters into client-side code — typically JavaScript or HTML links — in a way that alters how a victim's browser interprets a URL or form submission.

**Example — injecting parameters into a generated link:**

An application generates a share URL from a user-supplied parameter:

``` GET /share?url=https://example.com/page ```

The application outputs:

```html <a href="https://example.com/page&utm_source=share">Share this</a> ```

An attacker supplies:

``` GET /share?url=https://example.com/page&redirect=https://evil.com ```

If the application doesn't strip or encode the extra parameter, the generated link now includes the attacker's injected parameter, potentially redirecting users to a malicious site.

Real-World HPP Attack Scenarios

OAuth Token Theft

OAuth 2.0 flows pass state and redirect_uri parameters in GET requests. An HPP attack can inject a duplicate redirect_uri parameter:

``` GET /oauth/authorize? client_id=app123 &redirect_uri=https://legit.com/callback &redirect_uri=https://attacker.com/steal &state=abc123 &response_type=code ```

If the OAuth server validates the first redirect_uri but uses the second for the actual redirect, the authorisation code is delivered to the attacker's server. The attacker can then exchange the code for an access token and take over the victim's account.

This exact class of vulnerability has been found in major OAuth provider implementations and in third-party OAuth integrations. The consequences range from session takeover to full account compromise.

E-commerce Price Manipulation

A checkout system accepts a quantity parameter:

``` POST /cart/add product_id=SKU123&quantity=1 ```

An attacker submits:

``` POST /cart/add product_id=SKU123&quantity=1&quantity=-999 ```

If the backend processes the last value and doesn't validate that quantity must be positive, the attacker might trigger a negative price calculation — receiving a discount rather than paying.

WAF Bypass via Parameter Duplication

Many WAFs inspect the first or a concatenated version of duplicate parameters. An attacker who knows the WAF's parsing behaviour can split a malicious payload across two values of the same parameter:

``` GET /search?q=SELECT&q=+*+FROM+users ```

If the WAF checks each parameter value individually and neither value alone triggers a SQL injection rule, but the backend concatenates them before passing to a query builder, the split payload evades detection.

How to Test for HTTP Parameter Pollution

Manual Testing

For any parameter your application accepts, test the following:

1. Submit the parameter once with a legitimate value — confirm expected behaviour 2. Submit the parameter twice with the same value — confirm consistent behaviour 3. Submit the parameter twice with different values — observe which value the application uses 4. Submit the parameter with a malicious payload as the second value preceded by a benign first value — test whether the malicious value reaches the backend unfiltered

Tools like Burp Suite's Repeater make this straightforward — intercept a request, duplicate parameters in the raw editor, and observe the response.

Automated Testing

Automated web application scanners test for HPP as part of their parameter manipulation checks. Yrzo AI runs continuous automated tests against your application, including HPP test cases for GET parameters, POST body parameters, and API endpoints.

Focus Areas

When testing manually, prioritise:

- **Authentication parameters** — login tokens, session identifiers, role indicators - **Financial parameters** — amounts, quantities, account identifiers - **Security control parameters** — CSRF tokens, API keys passed in query strings - **Redirect parameters** — `redirect_uri`, `return_url`, `next`, `callback` - **Search and filter parameters** — high risk for SQL injection via HPP

Defending Against HTTP Parameter Pollution

Use a Single Parameter Parsing Strategy

Choose a consistent, explicit approach to duplicate parameters at every layer of your stack. If your framework returns an array for duplicate parameters, validate that the array has exactly one element before processing it. Reject requests with duplicate parameters outright where your application logic doesn't require them.

```python # Python / Flask example from flask import request

def get_single_param(param_name): values = request.args.getlist(param_name) if len(values) != 1: raise ValueError(f"Expected exactly one value for {param_name}") return values[0] ```

Whitelist Permitted Parameters

Reject any request that contains parameters your application doesn't expect. An allowlist approach means an injected `role=admin` parameter is rejected immediately if `role` isn't a permitted parameter for that endpoint.

Don't Rely on WAF Position Alone

If your WAF and your backend parse duplicate parameters differently, the WAF protection can be bypassed. WAF rules are a layer of defence, not a substitute for correct application-level parameter handling.

Validate After Parsing

Always validate parameters after your framework has parsed them, not before. Any validation that runs on the raw request string before framework parsing can be bypassed by HPP techniques.

Encode Output

For client-side HPP, ensure that user-supplied values that appear in generated URLs or HTML are properly encoded. A URL-encoded `&` in user input should never become a literal `&` in a generated link.

Security Testing

Include HPP test cases in your automated test suite and in any penetration test scope. HPP is frequently missed by tests that focus on single-parameter injection without considering duplicates.

HPP in the OWASP Context

HTTP Parameter Pollution sits within the OWASP category of Injection (A03:2021) and Input Validation issues. It's closely related to parameter tampering attacks more broadly and often enables other vulnerability classes — particularly WAF bypass and privilege escalation — that wouldn't be possible through direct injection alone.

The OWASP Testing Guide (WSTG-INPV-04) covers HPP as part of the input handling section and includes test cases for both GET and POST parameters.

Summary

HTTP Parameter Pollution is a subtle but high-impact vulnerability class that exploits inconsistencies in how web technologies handle duplicate parameters. It's used to bypass WAFs, manipulate application logic, steal OAuth tokens, and escalate privileges. The fix requires consistent, explicit parameter handling at the application layer — not just at the perimeter.

Yrzo AI's continuous web application scanning tests your endpoints for HPP vulnerabilities automatically, flagging duplicate parameter handling issues before an attacker exploits them.

**[Test your application for HPP vulnerabilities → Start free at yrzoai.dev](https://yrzoai.dev)**