WAF evasion through double encoding exposes API security gaps

At a glance

What this is: Salt examines how double-encoded payloads can slip past WAF inspection in API traffic, with path traversal and local file inclusion used as the example attack pattern.

Why it matters: This matters because API security teams that rely on signature matching alone can miss attacks hidden by encoding tricks, while identity and access controls at the application layer never get a chance to compensate.

Context

A web application firewall can only help if it interprets traffic the same way the backend application does. When decoding rules, parser behaviour, and request normalisation differ across layers, attackers can hide malicious intent inside apparently harmless syntax and move past perimeter controls. That creates a governance gap for API protection because the security control is measuring the wrong representation of the request.

This article sits at the intersection of API security and emerging agentic AI risk. Human attackers can already use double-encoding to probe defence gaps, and AI agents raise the speed and scale of that testing by automating evasion attempts. The underlying issue is not just filtering bad strings, but governing how requests are understood, normalised, and evaluated before execution.

Key questions

Q: What fails when a WAF only decodes API input once?

A: The failure is a canonicalisation gap. A payload can look harmless after one decode pass and still become malicious later when the application decodes it again. That means the edge control and the backend are judging different request forms, so the WAF blocks syntax while the application executes intent.

Q: Why do double-encoded payloads increase API risk?

A: They exploit differences in how layers normalise requests. If a gateway, WAF, and backend do not interpret encoding consistently, the attacker can hide path traversal or similar behaviour inside apparently valid input. The risk rises because the control meant to stop the attack is evaluating the wrong representation of the request.

Q: What signs indicate API traffic is being used for evasion?

A: Look for repeated encoding, odd payload symmetry, sudden changes in path or parameter structure, and requests that are technically valid but operationally unusual for the endpoint. Those signals matter because evasion often shows up as behaviour that is inconsistent with normal client use, not as an obvious exploit string.

Q: How should teams respond when perimeter filtering misses malicious API input?

A: Treat it as a control-design issue, not a one-off bypass. Validate request decoding at each layer, add behavioural detections for suspicious payload structure, and enforce business-logic checks on the final canonical form before sensitive operations occur. That reduces the chance that upstream filtering and backend execution disagree.

Technical breakdown

How double-encoding defeats request inspection

Double-encoding turns a malicious sequence into a representation that one layer of the stack may decode differently from another. A WAF often inspects traffic after a single decode step, so %252e%252e%252f can appear harmless even though the backend later decodes it again into ../. The problem is not the character sequence alone, but the mismatch between inspection time and execution time. In API environments, that mismatch becomes especially dangerous because requests often pass through gateways, caches, proxies, and application middleware before they reach the code that enforces business logic.

Practical implication: validate that gateway parsing and application parsing produce the same canonical form before relying on WAF decisions.

Why signature rules miss intent in API traffic

Signature-based controls look for known bad strings, patterns, or regular expressions. That works only when attacker input reaches the control in the same form that the rule expects. Once payloads are encoded, split, or normalised in layers, the signature can be bypassed without changing the underlying malicious intent. Behavioural detection looks at request structure, sequence, payload anomalies, and context across the API interaction, which gives defenders a better chance of spotting evasion that is syntactically disguised but operationally suspicious.

Practical implication: supplement signatures with behavioural detections that compare request patterns, not just tokenised content.

How API security gaps widen when control logic sits in the wrong layer

The deeper issue is architectural. If the first meaningful security decision happens only at the edge, the backend inherits requests that may already have crossed trust boundaries. In API security, that means the application and WAF can disagree about what the request contains, leaving canonicalisation bugs, local file inclusion attempts, and path traversal payloads to be judged too late. This is also where NHI and agentic AI concerns emerge: automated clients can rapidly test many encodings, and service-to-service trust may let malformed requests travel further than a human session would.

Practical implication: move key validation closer to business logic and treat canonicalisation as a control requirement, not a convenience.

Threat narrative

Attacker objective: The attacker wanted to bypass perimeter inspection and reach sensitive files or internal resources through the API.

1. Entry occurred through a public-facing catalog API where the attacker submitted path traversal and local file inclusion payloads disguised by double-encoding.
2. The WAF decoded the payload only once, which made the malicious sequence look benign enough to pass inspection.
3. The backend decoded the request again, allowing the traversal payload to resolve into executable malicious input.
4. The impact was potential access to sensitive files and a bypass of the organisation's intended API protection layer.

Breaches seen in the wild

• Imperva breach 2019: An AWS API key stolen from an exposed Imperva test instance let an attacker copy Cloud WAF customer data, including API keys and SSL certificates.
• Capital One breach 2019: A misconfigured firewall handed over its cloud role credentials, and an over-privileged role exposed data on 106 million people.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Double-encoding is a canonicalisation failure, not just an input-validation problem. The security issue is not that the payload exists, but that different components interpret the same request differently. That creates a control gap between detection and execution, which is exactly where API defence fails in practice. Practitioners should treat canonical form consistency as a governance requirement for API gateways, parsers, and backend services.

WAF-only protection creates a false boundary for API risk. WAFs can reduce exposure, but they do not resolve whether the backend will later reinterpret the request in a more dangerous form. When inspection happens at the edge and enforcement happens later, attackers can exploit the gap between those two interpretations. Teams need layered controls that validate intent at the application boundary, not just syntax at the perimeter.

Intent-aware API security is now a machine-speed problem. The article's example is human-driven, but the same evasion pattern can be automated by AI agents that test large numbers of encodings and request shapes. That makes request normalisation and anomaly detection part of NHI and agentic AI governance as well as API security. The practical conclusion is that parser alignment and behavioural analysis are becoming core controls, not optional enhancements.

API attack-surface governance needs to account for transformation risk. Security teams often inventory endpoints, auth patterns, and schemas, but overlook how a request transforms as it moves through proxies and application layers. That transformation risk is the real weakness here. The next step for practitioners is to govern the full request journey, from edge intake to backend execution, as one control plane.

From our research library:

• 60% of healthcare organisations do not assess a vendor's security before signing a contract that grants access to protected health information, according to Ponemon Institute's 2023 Third-Party Risk in Healthcare report.

What this signals

Canonicalisation drift: When the WAF and the backend disagree on what a request means, the attacker does not need a new exploit, only a different representation of the same one. That is why API governance has to cover decoding, parsing, and transformation steps end to end.

The operational takeaway for practitioners is to move beyond signature confidence and ask where the request becomes trusted in the stack. If that trust boundary sits too early, public APIs remain exposed even when the dashboard says the perimeter is clean.

For practitioners

• Align canonicalisation across the request path Test how the WAF, gateway, middleware, and application each decode the same API request, then remove any mismatch that lets malicious input change form between layers.
• Add behavioural detections for anomalous payload structure Detect encoded traversal patterns, unusual repetition, and request shapes that deviate from normal client behaviour rather than relying on static malicious strings alone.
• Validate backend enforcement on decoded input Make sure the application validates the final canonical form before file access, routing, or downstream execution occurs.
• Review API security controls for parser gaps Map where API request content changes representation, then confirm each transition has explicit inspection and enforcement, especially where public APIs handle files or paths.

Key takeaways

• Double-encoding can turn a familiar API exploit into a request that slips past edge inspection while still reaching dangerous backend logic.
• The key weakness is inconsistent normalisation between security controls and the application, not the payload alone.
• Teams should verify canonicalisation, add behavioural detection, and enforce validation on the final decoded form before sensitive operations run.

Key terms

• Canonicalisation: Canonicalisation is the practice of normalising output into a consistent, predictable form before it is exposed to callers. In privacy and security design, it helps remove hidden entropy, reduce ambiguity, and prevent internal implementation details from becoming externally observable signals.
• 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.
• Path Traversal: A bug where crafted path segments such as ../ allow input to escape an intended directory boundary. In practice, it turns a normal file operation into a boundary break, which is especially dangerous when the affected service runs with non-human identity privileges and touches production data or secrets.
• Local File Inclusion: Local file inclusion is a vulnerability where an application accepts a path or file reference that lets an attacker access unintended local files. It usually results from weak input validation and can expose configuration, code, or other sensitive server-side content.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.