Double Encoding

Double encoding is a technique where an attacker encodes the same characters more than once so different layers interpret the payload differently. In API attacks, the edge may see benign text after one decode pass while the backend restores the malicious string and executes the exploit.

Expanded Definition

Double encoding is a request manipulation technique in which the same input is encoded more than once so that one security layer decodes it differently from another. The result is a mismatch between what is inspected at the edge and what is finally interpreted by the application, API gateway, or backend service. This matters in web security, API security, and identity workflows because filters often validate the first decoded form, while the target component may later restore the original malicious characters.

In practice, double encoding is often used to bypass input validation, path normalisation, WAF rules, and routing logic. It is closely related to canonicalisation problems, but it is not the same as simple URL encoding. The issue is not encoding itself; the issue is inconsistent decode order across components. Guidance for handling this class of weakness aligns with secure processing expectations in NIST Cybersecurity Framework 2.0, especially where systems must validate, normalise, and protect data before trust decisions are made.

The most common misapplication is treating a single successful validation step as sufficient when the edge proxy, application server, and downstream library do not apply the same decoding rules.

Examples and Use Cases

Implementing request handling rigorously often introduces normalisation overhead, requiring organisations to weigh strict canonicalisation against application compatibility and developer convenience.

• An attacker submits a path such as a doubly encoded directory traversal sequence so a gateway sees harmless text, but the backend decodes it again and reaches restricted files.
• A web application checks for blocked characters after one decode pass, but a downstream framework restores the original payload and passes it into a command or SQL context.
• An API endpoint receives a token or parameter that appears safe to an upstream filter, yet a later component decodes it into a control character sequence that changes routing or query logic.
• An identity or session workflow mishandles encoded redirect URLs, allowing a crafted value to bypass validation and send a user to an unintended destination.
• A security test reveals that inconsistent decoding between reverse proxy, application code, and logging pipeline causes the same request to appear benign in one layer and malicious in another.

Testing for this issue usually requires comparing how each layer handles input, not just whether one layer blocks it. OWASP guidance on input handling and canonicalisation is useful when confirming whether a control is checking the final interpreted form rather than a partially decoded variant.

Why It Matters for Security Teams

Double encoding matters because it turns trusted middleware into an attack surface when validation and execution do not share the same interpretation of input. Security teams often focus on blocklists, WAF signatures, or edge filtering, but those controls fail if downstream services re-decode parameters, rewrite paths, or normalise values differently. The risk is especially important in API environments, microservices, and identity-adjacent workflows where a single request passes through multiple parsers before it reaches a sensitive action.

For defenders, the practical challenge is consistency: every layer must apply the same canonicalisation rules before authorisation, routing, logging, and execution. That aligns with secure-by-design thinking reflected in OWASP input validation guidance and with resilient control mapping under the NIST Cybersecurity Framework 2.0. Teams also need to verify that error handling does not leak whether a payload was blocked before or after decoding, because that feedback helps attackers tune evasion attempts.

Organisations typically encounter the operational impact only after a bypass, log discrepancy, or unexpected backend action, at which point double encoding becomes unavoidable to investigate and fix.

Related resources from NHI Mgmt Group

• What is the difference between training engineers and encoding expertise into delivery?
• What do security teams get wrong about double extortion ransomware?
• Why do double blind age checks matter for identity governance?
• What breaks when a double-free vulnerability exists in an internet-facing web server?