With HTTP Parameter Pollution (HPP) attacks, threat actors can hide scripts and processes in URLs. First discovered in 1999, this technique can also allow threat actors to pollute the parameters in the URL and the request body. This could lead to behavior changes in the app, such as cross-site scripting, privilege changes or granting unwanted access.

HPP remains a risk to watch out for today. Read on to discover how HPP attacks work and how to spot them.

The impact of HTTP parameter pollution

An attacker can use an HPP attack to perform many different unwanted actions. They can override the existing hardcoded HTTP parameters, modify the application behavior and access and exploit the user-uncontrollable variables. HPP attacks also enable people to bypass input validation checks and web application firewall (WAF) rules. It opens up routes to attacks, including cross-site scripting (XSS), structured query language (SQL) injection. HPP attacks can be performed by polluting HTTP GET/POST requests by injecting multiple parameters with the same name holding different values and kept apart by delimiters.

Types of HTTP parameter pollution

HPP can be classified into two types: client side or server side. Different web servers behave in different ways when they receive multiple parameters with the same name since ways to parse parameters vary. Client-side or server-side HPP attacks are possible depending on the way requests are handled.

For example, PHP/Apache-based apps use the last occurrence of the parameter, while Jakarta Server Pages (JSP)/Tomcat-based apps use the first. The table below shows how different languages and web servers manage this.

Technology/HTTP back-end

Overall Parsing Result



All occurrences of the specific parameter



All occurrences of the specific parameter



Last occurrence



Last occurrence


JSP, Servlet/Apache Tomcat

First occurrence


JSP, Servlet/Oracle Application Server

First occurrence


JSP, Servlet/Jetty

First occurrence


IBM Lotus Domino

Last occurrence



First occurrence



First occurrence


Perl CGI/Apache

First occurrence


mod_wsgi (Python)/Apache

First occurrence



All occurrences in list (array)


Scroll to view full table
Source: https://en.wikipedia.org/wiki/HTTP_parameter_pollution

Client-side HPP

A client-side HTTP Parameter Pollution attack is related to the client or user environment, meaning the user’s actions are affected and will trigger a malicious or unintended action without their knowledge. This risk arises when an app embeds user input in URLs in an unsafe manner. An attacker can use this opening to construct a URL that, if visited by another user, will modify URLs within the response by inserting more query-string parameters that override existing ones. This may result in links and forms working in ways they weren’t meant to be used. For example, it may be possible to modify an invitation form using HPP so that the invitation is delivered to a different recipient.

This might have a greater or lesser impact depending largely on what the affected app can do. Even with an app that has no direct impact on its own, an attacker may use it in conjunction with other openings to make the overall attack worse.

Flow Chart of Client-side Parameter Pollution

Example: A movie rating site

Let’s examine a client-side HPP attack in a real-world example.

Consider a movie rating website. People can give ‘likes’ or ‘dislikes’ for a movie. This example website uses two href links (Link A and Link B) containing two parameters, ‘mname’ and ‘mrating’. Mname holds the name of the movie for which the rating is given, and mrating holds the value of either likes or dislikes for any given movie.

URL: http://host/movie.jsp?mname=littlestar

Link A: <a href=”rate.jsp?mname=littlestar&mrating=like“>Likes for LittleStar movie</a>

Link B: <a href=”rate.jsp?mname=littlestar&mrating=dislike“>Dislikes for LittleStar movie</a>

Let’s assume the marketing team wants more likes for the movie “LittleStar”. So, the attacker using HTTP Parameter Pollution creates and shares the trigger URL to the victims: http://host/movie.jsp?mname=littlestar&mrating=like

An attacker injected the polluted parameter ‘mrating’ with a value of ‘like’. When the victims click on the doctored website, they are rerouted to the site which contains two injected links (Link A1 and B1 for the movie “LittleStar”).

Link A1: <a href=”rate.jsp?mname=littlestar&mrating=like&mrating=like”>Likes for LittleStar movie</a>


                                                                  Injected Parameter


Link B1: <a href=”rate.jsp?mname=littlestar&mrating=like&mrating=dislike”>Dislikes for LittleStar movie</a>


                                                                   Injected Parameter

The honest requests Link A and B have been polluted by adding another parameter (mrating) with the respective payloads. In this case, Link A1 and Link B1 become malicious href links. Since the app is designed on JSP in both links A1 and B1, the first occurrence of the similar parameters (the injected parameter) will be returned to the app and the second will be ignored. No matter which links the victim clicks on, the app will consume the mrating=like parameter in both href links, thus rendering more likes to the movie “LittleStar.”

Server-side attacks

So, the goal of the attacker in a client-side attack is to attack other users. In the server-side variant the attacker could use an at-risk web app in several ways. They could access protected data or perform actions that either are not permitted or not supposed to be run on the server side.

Server-side attacks can be done by injecting a similar parameter into existing values or by using parameters not visible to the end user.

Example: Robbing a bank

Let’s examine a classic example of a bank transaction to see how the HTTP Parameter Pollution attack could happen at the server side.

Flow Chart of Server-side Parameter Pollution

In the example, Bob is transferring $10 to Alice by entering a dollar amount and choosing the transfer account.

The request for the transaction will be as shown below:

POST /transfer.php HTTP/1.1

Host: bank.com

Connection: close


There are two parameters in the request sent to the server: the amount to be transferred and the payee. Once the request hits the server, another request is sent from the server to the back-end payment gateway. This is where the actual transaction takes place. Now, the request from the payment gateway looks something like this:


Next step: Add a parameter

This request is similar to the previous one, but there is an additional parameter: payer. The parameter ‘payer’ is not present in the original request from the app, because the attacker could easily modify it and transfer all the money from any account. To prevent this, the server uses the payer’s cookie to get the name and then adds it at the back-end request to avoid changing the value.

The payer value cannot be changed. However, we can still use HTTP Parameter Pollution to inject a similar parameter with a different value. In this example, the payment gateway is written in PHP running on Apache. So, an attacker can add two extra parameters at the end of the existing parameters.

We already know PHP/Apache will consider only the last occurrence of the parameters, and the first occurrence will get ignored.


The payment gateway will see this:


POST /transfer.php HTTP/1.1                                                                200 OK

Host: bank.com                                                                                   Transaction Successful

Connection: close


When the payment transfer happens, the money will be debited from Alice’s account and credited to Bob’s account. Thus, Bob could steal all of Alice’s money through this attack.

Do web application firewalls make a difference?

The attack shown above is a type of direct-server attack where there is no app firewall, such as a web application firewall (WAF), in place. When there are app firewalls in place for protection, attackers can still bypass them.

Some WAFs may check and validate only a single parameter occurrence, either the first or the last one based on the method used. This attack is based on how the server parses the parameters with the same names.

WAF HTTP Parameter Pollution rules could be bypassed under a couple of different cases. It could be done when the server takes the last occurrence of the parameters and the WAF rule is designed to check only the first occurrence, or vice versa. Or, it could happen when the server joins two of the same parameters with different values and the WAF rule is designed to check them one by one.

How HPP bypasses firewall rules

Take the following example. Here, an HTTP Parameter Pollution attack can be used to bypass WAF rules in order to perform cross-site scripting.

To bypass the firewall rule, consider the following URL: http://myapp/vul.cgi?par=val

For HPP to be successful in the above URL/app, an attacker can add an extra parameter at the end of the URL with the same name but with a different value. The request would look like this: http://myapp/vul.cgi?par=val1&par=val2

In this case, since firewall rules are applied, what the app does is not changed. However, this rule can be bypassed by adding an XSS/SQL payload such that the attack could still be performed.

An attacker could split the malicious XSS/SQL payload into two parts and insert the two different values in the same parameters.

http://myapp/vul.cgi?par=”><img src=a onerror=al&par=ert(1)>

The above XSS payload “><img src=a onerror=alert(1)> is accepted and executed by the server after bypassing the firewall.

How to prevent HTTP parameter pollution

There are several ways to protect against HPP. Make sure to perform an extensive and proper input validation. All user-supplied data, which is reflected in the HTML source code of the HTTP response, should be encoded according to the context in which they are reflected. Beware of multiple instances of similar parameters. Lastly, use only common sense safe methods of navigating web technology and languages.

If using a WAF, you should also consider some other safety tips. The easiest solution would be for the WAF to not allow multiple instances of the same parameter in a single HTTP request. This would prevent all types of this attack. This might not be possible in all cases, though, as some apps might need multiple duplicate parameters. They might be designed to send and accept multiple HTTP parameters of the same name in the same request.

To protect these types of apps, the WAF should also interpret the HTTP request in the same way the app would. In addition, be aware of the weaknesses of specific app components and use strict filtering. Staying alert to these openings will help you spot HTTP Parameter Pollution before it hurts.

More from Fraud Protection

Virtual credit card fraud: An old scam reinvented

3 min read - In today's rapidly evolving financial landscape, as banks continue to broaden their range of services and embrace innovative technologies, they find themselves at the forefront of a dual-edged sword. While these advancements promise greater convenience and accessibility for customers, they also inadvertently expose the financial industry to an ever-shifting spectrum of emerging fraud trends. This delicate balance between new offerings and security controls is a key part of the modern banking challenges. In this blog, we explore such an example.…

Remote access detection in 2023: Unmasking invisible fraud

3 min read - In the ever-evolving fraud landscape, fraudsters have shifted their tactics from using third-party devices to on-device fraud. Now, users face the rising threat of fraud involving remote access tools (RATs), while banks and fraud detection vendors struggle with new challenges in detecting this invisible threat. Let’s examine the modus operandi of fraudsters, prevalence rates across different regions, classic detection methods and Trusteer’s innovative approach to RAT detection through behavioral analysis. A rising threat As Fraud detection methods become more and…

Gozi strikes again, targeting banks, cryptocurrency and more

3 min read - In the world of cybercrime, malware plays a prominent role. One such malware, Gozi, emerged in 2006 as Gozi CRM, also known as CRM or Papras. Initially offered as a crime-as-a-service (CaaS) platform called 76Service, Gozi quickly gained notoriety for its advanced capabilities. Over time, Gozi underwent a significant transformation and became associated with other malware strains, such as Ursnif (Snifula) and Vawtrak/Neverquest. Now, in a recent campaign, Gozi has set its sights on banks, financial services and cryptocurrency platforms,…

The rise of malicious Chrome extensions targeting Latin America

9 min read - This post was made possible through the research contributions provided by Amir Gendler and Michael  Gal. In its latest research, IBM Security Lab has observed a noticeable increase in campaigns related to malicious Chrome extensions, targeting  Latin America with a focus on financial institutions, booking sites, and instant messaging. This trend is particularly concerning considering Chrome is one of the most widely used web browsers globally, with a market share of over 80% using the Chromium engine. As such, malicious…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today