Why WAFs Help, But Aren’t Enough for API Security

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. 

TL;DR

‍WAFs are perimeter security tools designed to block common web threats but are not built for API security. With 29% of all web attacks targeting APIs, WAFs missing 35% of enterprise APIs, and business logic attacks bypassing WAF detection entirely, proactive API security is the only reliable path forward.

Shift in Attack Surface: WAF Configurations Fall Short

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.

Incomplete Coverage and WAF Blind Spots

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.

Long-Term Implications of WAF Dependency

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.

Automated API Security Platform Levo.ai

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!

Conclusion

WAFs were built for a different threat landscape. Attackers have moved on to API business logic, authorization flaws, and internal endpoints that WAFs cannot see.

Levo.ai discovers every API, tests over 1,000 payloads per endpoint, and maps every vulnerability to the exact code responsible without changing a single configuration.

See Levo.ai in action

FAQs

What is a WAF and why does it fall short for API security?

WAFs are signature based tools built for HTML and XML, not modern APIs. They inspect surface level traffic and miss business logic attacks, internal APIs, and third party endpoints that account for 35% of enterprise APIs.

What API attacks do WAFs completely miss?

BOLA attacks where a valid JSON request exploits authorization flaws bypass WAF detection entirely because the structure looks legitimate. WAFs catch what looks wrong, not what behaves wrong.

Why do WAFs cause false positives and alert fatigue?

WAFs pattern match at the perimeter, flagging legitimate API traffic as threats. In a real fintech POC a WAF triggered a full breach alert that was entirely false, causing panic across the DevSecOps team and immediate disqualification.

What blind spots do WAFs leave in enterprise API ecosystems?

Internal and third party APIs accounting for 35% of enterprise APIs never pass through the WAF perimeter. The Optus breach proved this when an unmonitored internal API exposed millions of sensitive records without triggering a single WAF alert.

How does proactive API security outperform WAF based security?

Proactive security tests business logic, authorization flows, and insecure code in pre production before deployment. WAFs react at the perimeter after threats arrive. Catching vulnerabilities before production means fewer alerts, faster fixes, and a stronger security posture.