What is HTTP parameter pollution (HPP)?

HTTP parameter pollution (HPP) is a web attack technique that manipulates duplicate or encoded HTTP parameters to change how an application processes input. Because different servers, frameworks, proxies, and client-side components may interpret repeated parameters differently, attackers can exploit these inconsistencies to bypass validation, alter application behavior, or interfere with security controls.

In simple terms, HPP works by sending multiple values for the same parameter – or by injecting additional parameters through encoding tricks – and relying on the application stack to handle them in unexpected ways, similar to other forms of parameter tampering.

HTTP parameter pollution is often used alongside other vulnerabilities such as cross-site scripting (XSS), SQL injection, and authentication bypass, where manipulating parameters can help bypass input validation or alter application logic. It was first formally described by Stefano Di Paola and Luca Carettoni in their 2009 OWASP AppSec research and remains highly relevant today because modern applications rely on multiple layers that may not interpret input consistently.

How HTTP parameter pollution works

Modern web applications process parameters across URLs, forms, cookies, headers, and APIs. When the same parameter appears more than once in a request, the application stack must decide how to handle it – and different components often make different choices.

Take a simple request with two parameters, both called id:

https://example.com/profile?id=123&id=999

Depending on the technology and implementation, the application may:

• Use the first value (123)
• Use the last value (999)
• Combine both values into a single string
• Treat the values as an array

This becomes a security issue when validation logic and application logic do not align. For instance, a security control might validate the first occurrence while the application processes the last.

Why parsing differences matter for parameter pollution

In practice, parameter handling typically falls into four patterns:

• First occurrence wins: Only the first parameter value is used
• Last occurrence wins: Later values override earlier ones
• Concatenation: Values are combined into a single string
• Array handling: Values are stored and processed as a list

Because different layers – such as proxies, frameworks, and backend code – may apply different rules, attackers can craft requests that are interpreted differently at each stage.

How different technologies handle duplicate parameters

The following behaviors are simplified examples. Actual handling depends on framework configuration and how application code accesses parameters – for example, whether values are read as scalars or arrays.

Duplicate parameter handling overview

Such inconsistencies are at the core of HPP attacks. If one component validates input in one way while another processes it differently, attackers can exploit the gap.

Client-side vs server-side parameter pollution

HTTP parameter pollution can occur on both the client side and the server side, often within the same request flow.

Client-side parameter pollution

Client-side HPP targets how browsers or front-end code process parameters before sending requests or rendering content. A client-side parameter pollution flow might be:

• A JavaScript application reads a parameter value from the URL
• It uses one interpretation for UI logic
• The server later processes the same parameter differently

This mismatch can lead to manipulated workflows or injection into client-side logic.

Server-side parameter pollution

Server-side HPP affects how backend systems interpret parameters after a request reaches the application. Possible impacts in this case include:

• Authentication and authorization bypass attacks
• Manipulation of business logic
• Interference with database queries

Server-side HPP is generally more severe because it directly affects how the application processes data.

HTTP parameter pollution examples

A simple example involves overriding a parameter with a different value:

https://example.com/account?role=user&role=admin

If validation checks the first value (user) but the application processes the last value (admin), an attacker may gain elevated privileges.

The logic flow for this mismatch would be:

• Validation layer evaluates role=user and allows access as a regular user.
• Application logic processes role=admin and allows elevated access.
• The result is a validation bypass due to inconsistent parsing.

Another example involves injecting additional parameters through encoding, as in:

https://example.com/search?q=term%26admin=true

Without decoding, this looks like one parameter q with the value of term%26admin=true. If the encoded ampersand delimiter (%26) is decoded at a later stage, the request may be interpreted as two separate parameters q and admin:

q=term&admin=true

This works because some intermediary layers such as proxies or web application firewalls evaluate the request before decoding, while backend components might decode the value later. As a result, the injected parameter may bypass earlier validation or WAF rules and only appear once the application processes the decoded input.

This is conceptually similar to mass assignment vulnerabilities in that both involve unexpected input reaching application logic, though the underlying mechanisms are different. HPP exploits parsing inconsistencies across layers, while mass assignment stems from frameworks automatically binding input to object properties.

Why HTTP parameter pollution still matters

HTTP parameter pollution is far from a legacy issue. In fact, it is becoming even more relevant in modern architectures because applications are no longer single-layer systems. A typical request may pass through:

• Browsers and front-end frameworks
• Content delivery networks (CDNs)
• Reverse proxies and load balancers
• Web application firewalls (WAFs)
• API gateways and backend services

Each layer may parse parameters differently, potentially opening up pollution opportunities.

In API-driven architectures, query parameters are widely used, and inconsistencies between API gateways and backend services can introduce new attack paths.

While JSON request bodies are less susceptible to classic HPP because they are structured differently, HPP still affects modern API stacks in several ways. Query parameter pollution remains common in REST endpoints, including API authorization bypass scenarios where inconsistent parameter handling affects access control decisions. Inconsistencies can also arise between API gateways and backend services, and some frameworks merge query parameters with request bodies or headers. All such behaviors can allow unexpected input to reach application logic even when individual components appear to validate requests correctly.

Single-page applications (SPAs) further increase complexity by processing parameters on the client side before sending requests to the server. The overall result is a broader attack surface where HPP exploits differences between layers rather than flaws in any single component.

How to detect HTTP parameter pollution

Detecting HPP requires testing how an application handles duplicate and encoded parameters across all layers. Key techniques include:

• Sending requests with repeated parameters and observing differences in responses
• Testing encoded delimiters to see if parameters are split at later stages
• Comparing how input is handled by proxies, WAFs, and backend systems
• Identifying inconsistencies between validation logic and execution logic

In practice, this often involves comparing how the same request is interpreted at different stages – for example, how a WAF processes a request before decoding versus how the backend application handles the decoded input.

Because these issues depend on runtime behavior, dynamic application security testing (DAST) approaches are particularly effective for identifying them.

How to prevent HTTP parameter pollution

Preventing HPP requires consistent parameter handling and robust input validation across the entire application stack. Key practices include:

• Reject unexpected duplicate parameters where they are not required
• Normalize parameter handling consistently across proxies, gateways, and application code
• Apply validation after normalization to ensure consistent interpretation
• Use strict allowlists for accepted parameters and formats
• Ensure client-side and server-side logic interpret parameters the same way
• Include APIs and hidden endpoints in security testing

For example, in a Node.js/Express application, you can explicitly reject duplicate parameters in middleware:

app.use((req, res, next) => {
 const query = req.query;
 for (const key in query) {
   if (Array.isArray(query[key])) {
     return res.status(400).send('Duplicate parameters are not allowed');
   }
 }
 next();
});

At the infrastructure level, similar controls can be enforced in reverse proxies. For example, an NGINX configuration can reject requests with duplicate query parameters:

# Simplified example for id
if ($query_string ~ "(^|&)id=.*&id=") {
   return 400;
}

In practice, implementations vary, but enforcing consistent parameter handling at the gateway level helps prevent inconsistencies from reaching application code.

Test your applications for HTTP parameter pollution

HTTP parameter pollution is often overlooked or downplayed because it depends on subtle inconsistencies in how applications process input. These issues are difficult to identify without testing real application behavior.

The Acunetix DAST scanner helps you detect vulnerabilities such as HTTP parameter pollution, input validation flaws, and other exploitable issues in web applications and APIs – including parameter parsing issues that can lead to HPP attacks. By testing running applications from the outside, it shows how attackers can manipulate requests in real-world conditions.

See how Acunetix identifies parameter handling issues and other exploitable vulnerabilities in your applications – request a demo to see how it works.

Frequently asked questions about HTTP parameter pollution