Rich Murphy
Global Sales Director at Levo
.svg)
When you’ve been selling enterprise security products for over 20 years, like me, you can tap into hundreds of customer conversations and POCs to validate or disprove a few theories about what works and what doesn’t.
Today, I'd like to share a story that validates such a theory.
A fintech giant was evaluating proactive security platforms like ours against a WAF-based competitor.
Within the first few days, the WAF solution set off major panic across their entire DevSecOps team.
The WAF flagged what it deemed to be a massive breach in progress—one that supposedly endangered sensitive customer data resulting in regulatory fines.
Naturally, the Fintech’s DevSecOps team scrambled to investigate. Then, the problem came into focus: a false positive.
The WAF solution was swiftly eliminated, reinforcing what we’ve known for some time, which is that Proactive Modules built as an afterthought on top of WAFs don’t work for API security.
Read through the blog to understand why.
The attack surface in the enterprise has fundamentally shifted. While traditional web attacks persist, attackers increasingly target APIs rather than web interfaces. Today, 29% of all web attacks target APIs, and over 85% of web traffic is API-driven.
WAFs are built to block common web threats, such as SQL injection or XSS, using predefined signatures and patterns. However, they aren’t well-suited for preventing API attacks, which primarily target business logic around AuthN and AuthZ.
WAFs were initially designed for traditional web formats like HTML or XML, with rule sets optimized for detecting threats in those contexts. They may identify structural anomalies in a payload but fail to recognize subtle malicious behavior within API transactions.
For instance, an attacker might exploit an API by manipulating a JSON field that appears normal but leads to unintended consequences, such as unauthorized data access or execution of unauthorized operations.
Consider a Broken Object Level Authorization (BOLA) attack: the attacker submits a legitimate-looking API request with valid JSON fields that request data from another user's account. Because the JSON structure adheres to expected API behavior and it’s properly authenticated, a WAF—even with API-specific rules—would allow it through, missing the inherent authorization flaw.
WAFs focus on superficial inspection, detecting surface-level anomalies while missing malicious activity in the deeper logic layer. API attacks often exploit the business logic of the API itself, bypassing WAF protections entirely.
Attackers, aware that WAFs block known attack signatures and patterns, manipulate APIs in ways that appear valid but exploit internal logic flaws.
Even WAFs with API-specific rulesets struggle to keep up with modern API ecosystems' complexity and scale.
As attackers constantly evolve their tactics, WAF configurations lack the agility to adapt to APIs' ever-changing flows and functions.
WAFs, by design, inspect traffic at the edge while guarding your network perimeter, which means a majority of internal API traffic doesn’t go through the WAF at all.
WAFs completely miss internal and third-party APIs, which typically account for about 35% of an enterprise's APIs.
Internal APIs communicate across private networks or use protocols not routed through the WAF, leaving them vulnerable to lateral movement attacks.
For example, during the Optus breach, an unauthenticated internal API exposed millions of sensitive records. Since the API never touched the WAF perimeter, it remained unmonitored and unprotected.
Similarly, third-party APIs, connecting your systems to external services, often bypass WAFs because they deal primarily with outbound traffic. This creates a gateway for attackers to exploit your systems via third-party vulnerabilities.
The limitations of WAFs for API security extend beyond missing attacks—they also result in costly inefficiencies.
Relying on WAFs to block production attacks increases cloud costs and alert fatigue.
Operating at the perimeter level, WAFs often generate false positives, as seen in the fintech POC.
Many API vulnerabilities stem from insecure code, which WAFs can't detect or address. Addressing these issues in pre-production environments through security testing proves far more effective.
By proactively identifying and resolving these gaps, enterprises can significantly reduce their vulnerabilities before deployment and ensure the security of their applications and data.
Proactive security measures will allow the teams to have detection rules only for signature-based attacks, resulting in much fewer alerts. This will allow security teams to focus on real threats rather than wasting time on false positives or benign anomalies.
Given the complexity and scale of modern API ecosystems, manual security testing is no longer feasible. This is where Levo.ai steps in, offering:
Book a demo through this link!
.png){kind=logo}
.svg)
.svg)
