Notifications
Clear all
Topic starter
02/08/2026 12:03 pm
TL;DR: A global healthcare technology customer saw path traversal and local file inclusion payloads slip past a WAF because attackers double-encoded malicious input, while Salt says behaviour-based detection caught the anomaly and enabled a custom blocking rule. Signature-only API defence can leave a false sense of safety when payload syntax, not intent, becomes the bypass path.
NHIMG editorial — based on content published by Salt: The "Good Enough" Trap
By the numbers:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%).
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a WAF only inspects API payloads once?
A: A single inspection pass can miss malicious input that changes meaning after additional decoding in the backend.
Q: Why do encoded API attacks remain effective against mature controls?
A: They remain effective because many controls are tuned to known strings, not to the decoding chain that reconstructs the exploit.
Q: How do security teams know if API abuse controls are working?
A: Security teams know API abuse controls are working when repeated credential use drops, abnormal request volume is detected early, and hostile client behaviour is blocked before backend systems see sustained load.
Practitioner guidance
- Test normalisation consistency across the full request path Recreate the same payload at the edge, gateway, and application layer to confirm each component decodes input the same way.
- Add behavioural detection for API abuse patterns Track unusual encoding depth, repeated parameter mutation, and traversal-like request shapes alongside standard WAF alerts.
- Create a traversal-specific regression test suite Maintain malicious test cases for double encoding, triple encoding, and Unicode obfuscation in pre-production validation.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- The exact double-encoded payload pattern used to bypass the WAF and the decoding sequence that made it effective
- The custom regex rule the customer applied to catch the traversal pattern at the WAF layer
- How the alert data was integrated into Cloudflare, Splunk, and Wiz workflows for detection and prevention
- How the posture governance engine was used to identify and remediate API security gaps as the attack surface expanded
👉 Read Salt's analysis of double-encoded API attacks and WAF evasion →
Double-encoded API attacks: what WAF-only defence misses?
Explore further
02/08/2026 1:09 pm
Green dashboards create a false governance signal: a passing WAF does not mean an API is safe if inspection stops at the first decoding layer. The control failure is not just technical, it is procedural, because teams often treat signature coverage as equivalent to security assurance. In practice, API governance must evaluate normalisation, backend parsing, and abuse detection together.
A question worth separating out:
Q: Should organisations rely on WAF rules alone for public APIs?
A: No. WAF rules are useful, but they should be one layer in a broader control set that includes behavioural analytics, request normalisation testing, and application-side validation. For APIs used by service accounts or automation, this layered approach is essential.
👉 Read our full editorial: WAF evasion through double encoding exposes API security gaps
