Why I Stopped Relying on WAF Alone (And Added an API Firewall)

A couple of years ago, I sat through a post‑mortem that changed how I think about application security. We had a WAF in place—properly configured, signatures up to date, running in reverse proxy mode. Still, an attacker managed to walk right through. They just found an internal API endpoint that wasn’t properly protected and started pulling data that should have never been accessible.

A WAF is great at stopping the noisy, obvious attacks, but it has a blind spot. It doesn’t really understand your API’s business logic, and it won’t stop someone who’s playing by the rules of HTTP but breaking the rules of your application.

Today, web applications and APIs are the main entry points for almost any business. Transactions, customer data, partner integrations—everything flows through them. And as the number of services grows, so does the attack surface. What used to be mass automated scans is now giving way to something more subtle: carefully crafted requests that look legitimate but exploit flaws in how your API handles authorization or business logic.

I’ve seen this trend play out in real incidents. According to recent industry reports, API‑related attacks have skyrocketed—some sources cite a 630% increase in 2024 alone, and a huge chunk of corporate applications carry API vulnerabilities that traditional web filters miss.

That’s why, over the past year, I’ve moved to a two‑layer approach: a WAF at the front door, and an API Firewall that sits closer to the actual services. They’re not redundant; they cover different things. In this post, I’ll walk you through how I think about both, why they work better together, and what I’ve learned from running them in production.

TL;DR

• A WAF alone won’t protect your APIs—it’s built for web forms and HTTP, not business logic.
• API attacks are growing fast; I’ve seen BOLA, mass assignment, and schema abuse slip right past a WAF.
• An API Firewall uses a positive (allowlist) model: if the request doesn’t match your spec, it’s blocked.
• Running both creates a two‑layer defense: WAF catches the noisy web attacks, API Firewall handles the subtle API‑layer abuse.
• Track incident trends, false positives, and MTTR—not just how many requests you block.
• Yes, maintaining specs takes work, but it’s cheaper than cleaning up a breach.

What a WAF Actually Does (And Where It Falls Short)

If you’ve ever deployed a WAF, you know it’s basically a gatekeeper that sits between the internet and your application. It inspects every incoming HTTP request—headers, parameters, the body, even the context—and decides whether to let it through or drop it on the spot.
A traditional firewall works at lower levels: IP addresses, ports, protocols. It’s great for segmenting networks or blocking traffic from a known bad IP. But a WAF operates at the application layer. It understands HTTP, and that’s its superpower. For example, a firewall in a platform like BILLmanager lets you implement classic network screening—blocking unwanted traffic based on protocol, source IP, and destination address.

I’ve run WAFs in a few different ways depending on the infrastructure.

The most common setup is reverse proxy mode: all traffic hits the WAF first, gets inspected, and only then is forwarded to the backend. It gives you centralized control, but you do take a latency hit—though in practice, it’s usually negligible if you size things right. Transparent proxy is another option; the WAF doesn’t change the destination address, so the client feels like it’s talking directly to the server. Bridge mode is a more low‑level option—it sits inline at the link layer—and passive mode just gets a copy of traffic for analysis, which is fine for monitoring but won’t block anything.

In my experience, reverse proxy strikes the best balance for most setups unless you have strict latency requirements or legacy constraints.

How It Decides What to Block

Under the hood, a WAF uses a mix of techniques. The oldest is signature‑based detection: it looks for known attack patterns—SQL injection strings, XSS payloads, that kind of thing. This is fast and effective for known threats, but it’s a cat‑and‑mouse game. Attackers tweak their payloads, and if your signatures aren’t constantly updated, things slip through.

Behavioral analysis is a step up. The WAF learns what normal traffic looks like for your application—typical request rates, common parameters, expected user journeys—and flags anything that deviates. It’s more flexible, but it takes time to tune. I’ve spent weeks adjusting thresholds to avoid false positives that would otherwise block legitimate users.

Some modern WAFs also use machine learning models to detect anomalies that don’t match any known signature. When it works, it’s impressive. But I’ve seen it go wrong when the training data is noisy or the model doesn’t understand the application’s actual behavior. It’s not a magic bullet.

In practice, I rely on all three: signatures for the low‑hanging fruit, behavioral rules for weird patterns, and ML as a catch-all—but always with manual oversight.

Once the WAF makes a decision, it can do a few things: block the request outright, drop the source IP into a quarantine list, or even sanitize the request (strip out malicious parts) and forward it. It’s a lot like an antivirus, but for web traffic. A good WAF also integrates with other tools—SIEM, identity systems, maybe an anti‑fraud service.

Before putting any WAF into production, I run a few sanity checks. Functional tests to make sure it doesn’t break legitimate traffic, load tests to see how it behaves under peak traffic, and failover tests because the last thing you want is a WAF outage taking down your app. But the most interesting tests are the red‑team style ones: I try to bypass it with obfuscated payloads, or see if it catches subtle API abuse. That’s often where you find the gaps—and why I eventually added an API Firewall to the mix.

The Missing Piece—API Firewall

APIs are tightly coupled with business logic. They process sensitive data and are often exposed to the outside world. Any mistake in an API can be extremely costly.

Industry data shows a sharp rise in attacks targeting APIs.

• 40,000+ API incidents observed in H1 2025 across 4,000+ environments, 44% of advanced bot activity now targets APIs.
• 87% of surveyed organizations reported experiencing an API-related security incident in 2025, the average number of daily API attacks rose 113% year over year.

An API Firewall is designed specifically to protect APIs. It inspects every incoming call, evaluating its structure, frequency, context, and compliance with the security policy.

Unlike solutions built for general web traffic, an API Firewall understands application‑layer protocols—REST, SOAP, GraphQL, gRPC, JSON‑RPC, and others. It doesn’t just look at headers; it analyzes the request body, schema, data types, parameters, and even client behavior. This makes it possible to catch attacks that slip past classic filters: BOLA, mass assignment, schema poisoning, and more.
So if an API Firewall is so good, why keep the WAF? Because they cover different threats. The WAF catches SQL injection attempts, XSS, and other classic web attacks that still come in through forms and front‑end endpoints. The API Firewall catches the more subtle, logic‑level abuse that targets the service layer. Running both gives you two layers of defense: the WAF filters the noise, and the API Firewall ensures what’s left still plays by the rules.

WAF + API Firewall: Why I Run Both

Let me give you a concrete example. Imagine you have an e‑commerce site. There’s a web frontend for desktop users and a mobile app that talks directly to APIs.

When an attacker tries to inject SQL through a search box on the website, the WAF sitting in front of the web server spots the malicious pattern and blocks it. Classic. WAF earns its keep.
But what happens when the attack comes through the mobile app? Say someone discovers they can call an API endpoint like /api/v2/payments without proper authorization and start pulling transaction data. The WAF sees an HTTPS request—nothing obviously malicious. No SQL, no XSS. It passes.

This is where the API Firewall steps in. It checks whether that endpoint is supposed to be accessible, whether the request schema matches what the API expects, and whether the user token has the right permissions. If anything’s off, it blocks the call. Data stays safe.

Different Focus Areas

WAF and API Firewall operate at different levels. Here’s how I think about the split:

	WAF	API Firewall
What it understands	HTTP, web forms, URLs	REST, GraphQL, gRPC, others
What it blocks	SQL injection, XSS, known exploits	BOLA, mass assignment, schema violations, rate abuse
Best at protecting	Frontend apps, traditional websites	APIs, microservices, mobile backends
Blind spots	Business logic, API-specific flaws	XSS, CSRF, classic web attacks

If you only run a WAF, your APIs are essentially unprotected against the kinds of attacks that exploit business logic. If you only run an API Firewall, your frontend forms are sitting ducks for injection attacks.

Modern applications aren’t just plain HTML forms anymore. I’m seeing more WebSocket connections for real‑time features, gRPC for internal microservices, and GraphQL endpoints that aggregate data from multiple sources. These technologies speed up development, but they also open new attack surfaces that traditional WAFs weren’t designed for. That’s why the two need to work together—not just coexist, but actually share context.

Two Ways to Think About Blocking

When I started combining WAF and API Firewall, I realized I was actually using two fundamentally different security models. Understanding the difference helped me tune each tool for what it does best.

Negative Model (Denylist)

This is the classic WAF approach. The rule is simple: everything is allowed unless it matches a known bad pattern. You maintain a list of signatures for SQL injection, XSS, brute‑force attempts, and so on. As long as a request doesn’t trip any of those rules, it gets through.

When I use it: For the web frontend—the public‑facing site where traffic is diverse and attackers throw all kinds of exploits. The negative model covers a broad range of threats without me having to specify exactly what good traffic should look like.
What I’ve learned: It’s quick to set up, but it’s only as good as your signature database. If you miss an update, or if the attacker uses a variant that isn’t yet in the rules, you’re exposed. Also, false positives can be annoying—legitimate users sometimes trigger rules because they typed something that looks like an attack. Tuning it takes time.

Positive Model (Allowlist)

This is the philosophy I use with the API Firewall. Instead of listing what’s bad, I define exactly what’s allowed. The API Firewall validates each request against a strict specification. Anything that doesn’t match is rejected.

Why I like it for APIs: Once you have a solid spec, the positive model is incredibly precise. It blocks requests that have extra parameters, wrong data types, or call endpoints that don’t exist. It also makes it trivial to enforce rate limits per endpoint, because the rule is “this client can call this path at this frequency.”
The catch: You need an up‑to‑date spec. If your API documentation lags behind the actual code, the positive model will start blocking legitimate traffic.

For the frontend applications, I stick with a WAF in negative model. It’s the right tool for catching the spray‑and‑pray attacks that still hit every public‑facing site.

For the APIs—especially those handling payments, user data, or core business logic—I use the API Firewall with a positive model. It gives me the confidence that even if an attacker figures out the endpoint names, they still can’t send malformed requests or abuse authorization.

When I run both together, I get the best of both worlds. The WAF blocks the noisy stuff; the API Firewall enforces strict contracts. I’ve stopped thinking of them as competing products and started treating them as complementary layers.

How I Measure Whether This Tandem Is Actually Working

Eventually, I settled on a few metrics that actually tell me whether the setup is improving security without breaking the user experience.

• Incident Trends
  This is the obvious one, but I look at it in a specific way. Instead of counting all blocked requests, I track successful attacks that reached the application. When I first added the API Firewall, that number dropped by about 80% over two months. Not because the WAF got worse, but because the API Firewall caught the stuff the WAF wasn’t designed to see.

• MTTR (Mean Time to Respond)
  When something does slip through, I measure how long it takes to detect and contain. With both layers feeding into a centralized log (SIEM), I’ve cut my MTTR roughly in half. The API Firewall provides structured data about which endpoint was hit, what the payload looked like, and whether the token was valid. That context saves hours of digging through WAF logs.

• False Positives
  False positives are the silent killer of security tools. If a WAF blocks a legitimate user, you lose trust. If an API Firewall rejects a valid call because the spec is outdated, someone will eventually ask to “just turn it off.”

I track false positive rates separately for each layer. For the WAF, I monitor how many requests get blocked that later turn out to be legitimate (usually from support tickets or user complaints). For the API Firewall, I look at rejected calls that match a known, authorized client. If the rate goes above 0.5% on either, I dig in.

• Attack stop ratio A more subtle metric I’ve started tracking is attack stop ratio—how many attacks are stopped by the WAF versus how many reach the API Firewall.

I’ve aggregated all of this into a simple dashboard—nothing fancy, just a few graphs and a weekly summary. It shows trends over months, not just real‑time spikes. That way I can see if a new API deployment introduced more false positives, or if a signature update actually reduced incident rates.

The point isn’t to hit arbitrary numbers. It’s to know, with data, whether the two layers are working together or just adding complexity. So far, the tandem has paid off, but only because I keep an eye on these metrics and tune accordingly.

Layered Defense Isn’t Just a Buzzword

After running this tandem for over a year now, I’ve come to see it as less of a “nice to have” and more of a necessity. The days when you could put a WAF at the edge and call it done are over. Modern applications are too distributed, and APIs have become the primary way data moves between services and clients.

The WAF is my outer perimeter. It handles the noise—the automated scans, the injection attempts, the obvious probes. It keeps the attack surface manageable. The API Firewall understands the contracts my services expect, enforces them, and stops the requests that look perfectly fine to a generic HTTP filter but violate how my application is supposed to behave.

When they work together, they cover both ends of the spectrum: the technical exploits and the logic‑level abuse.

What I’ve Learned

If I had to distill this into practical takeaways:

• Don’t assume your WAF sees your APIs. Most WAFs were built for web forms and HTML. If you expose GraphQL, gRPC, or even REST with complex JSON schemas, you need something that speaks those protocols.
• Positive model for APIs is a game changer. It requires maintaining specs, but the precision it gives you is worth the overhead. I’d rather update an OpenAPI file than chase a data breach.
• Metrics matter. I track false positives, incident trends, and layer efficiency. It helps me tune without breaking things.
• One tool won’t cover everything. I tried both extremes: WAF alone, then API Firewall alone. Both left gaps. The combination is what actually moved the needle.

What About You?

I’m curious how others are handling this. Are you still running just a WAF? Have you added API‑specific protection? What’s been your experience with false positives or deployment complexity?

If you’re working with microservices, mobile backends, or anything that exposes APIs to the outside world, I’d love to hear what your stack looks like. Drop a comment—I’m always looking to learn from how other teams solve these problems.