Back to scan results
Check 28 of 45

HTTP Parameter Pollution

We compare direct and duplicated query-string parameters in both orders. This reveals whether the application consistently chooses one value, combines values, changes validation behavior, or fails when a parameter appears more than once.

What this check probes

The scanner tests three common public GET parameters: q, id, and page. Each receives a unique safe marker and an inert custom HTML element using three requests:

  1. The inert marker as a single parameter value.
  2. The safe value first and inert marker second.
  3. The inert marker first and safe value second.

A fail requires a meaningful difference: the inert markup is not returned raw when sent directly, but is returned raw when hidden behind a duplicate parameter. That is evidence the duplicate changed validation or encoding behavior.

Concatenating both values, inconsistent first/last precedence, or duplicate-only server errors produce a warning for manual review. Consistently using the first value or consistently using the last value is recorded as normal behavior, not automatically called a vulnerability.

The marker contains no JavaScript, event handlers, external resources, or executable URL. The nine requests are GET-only and do not attempt to change application data.

Why this matters for PCI DSS

HTTP Parameter Pollution becomes dangerous when a CDN, cache, WAF, reverse proxy, framework, and application disagree about which duplicate value is authoritative. An attacker may place an allowed value where one component looks and a malicious value where another component looks.

This can bypass input validation, authorization checks, request signatures, cache keys, redirect allowlists, or output encoding. PCI DSS secure-development requirements expect applications to validate input after it has been decoded and canonicalised.

A pass covers only these public query-string probes. POST bodies, JSON, multipart requests, authenticated routes, and framework-specific array syntax need application-aware testing.

How to fix it

Reject duplicate scalar parameters. Decide which parameters may contain multiple values and reject duplicates everywhere else before authorization or business logic runs.

// ASP.NET Framework / Web Forms
string[] values = Request.QueryString.GetValues("id");
if (values == null || values.Length != 1)
{
    Response.StatusCode = 400;
    Context.ApplicationInstance.CompleteRequest();
    return;
}

string id = values[0];

Do not rely on Request.QueryString["id"] without first checking multiplicity; frameworks may join multiple values or choose one according to framework-specific rules.

Canonicalise and decode once, validate the canonical value, and ensure the CDN, WAF, proxy, cache, and application all use the same duplicate-parameter policy. Include duplicated, reversed, encoded-name, array, query/body, and mixed-case variants in automated security tests.

Fixed it? Re-run the scan to confirm.

Run scan again