What Is a WAF (Web Application Firewall)?

A Web Application Firewall (WAF) protects web applications from attacks that slip right past traditional firewalls.

The difference is what they're looking at. A network firewall controls access—it checks IP addresses, ports, and protocols. A WAF reads content—it examines what's actually inside HTTP requests.

A network firewall sees a POST request and asks "Is port 443 allowed?" A WAF sees the same request and asks "Is this SQL injection?"

The Blind Spot Traditional Firewalls Can't See

Traditional firewalls excel at controlling network access. They block unwanted connections, filter by IP address, and manage which ports can receive traffic.

But they're blind to attacks that arrive as normal web traffic.

When someone sends a POST request to your login form on port 443, a network firewall sees legitimate HTTPS traffic and lets it through. It doesn't examine what's being POSTed. It can't tell if that form submission contains '; DROP TABLE users; -- instead of a username.

Attacks targeting web applications exploit this blind spot. They arrive through allowed ports, using allowed protocols, looking exactly like normal traffic—until you read the content.

How WAFs Work

A WAF sits between browsers and your web server, inspecting every HTTP request before it reaches your application.

When a request arrives, the WAF examines:

• URLs and query parameters
• HTTP headers
• POST data and request bodies
• Cookies
• Uploaded files

It compares what it finds against patterns that indicate attacks. When something matches, the WAF can block the request, sanitize dangerous content, log it for analysis, or challenge the user with a CAPTCHA.

Deployment options include reverse proxy (clients connect to the WAF, which forwards requests to your servers), inline (traffic flows through the WAF), or cloud service (DNS routes traffic through the provider's infrastructure).

What WAFs Catch

SQL Injection — An attacker enters '; DROP TABLE users; -- into your login form, hoping your application executes it as a database command. The WAF recognizes SQL syntax where usernames belong and blocks the request.

Cross-Site Scripting (XSS) — An attacker submits a comment containing <script>alert(document.cookie)</script>, hoping your application displays it to other users and steals their sessions. The WAF detects script tags in user input and blocks them.

Path Traversal — A request contains ../../../etc/passwd, attempting to navigate up directory structures to access sensitive files. The WAF recognizes directory traversal patterns and blocks them.

Command Injection — User input contains shell commands like ; rm -rf / hoping the application passes it to a system call. The WAF detects command syntax and blocks execution.

Cross-Site Request Forgery (CSRF) — Tricks authenticated users into performing unintended actions. WAFs validate CSRF tokens and detect suspicious request patterns.

XML External Entity (XXE) — Exploits XML parsers to access local files or internal systems. WAFs inspect XML payloads for entity declarations that shouldn't be there.

Blacklists vs. Whitelists

WAFs use two security models with different trade-offs.

Negative security (blacklisting) blocks traffic matching known attack patterns. Easier to deploy, less likely to break legitimate functionality. But it only catches known attacks—novel techniques may slip through.

Positive security (whitelisting) defines exactly what's allowed and blocks everything else. Stronger protection that can catch unknown attacks. But it requires detailed knowledge of legitimate application behavior and risks blocking valid requests if your definitions are incomplete.

Most WAFs combine both: blacklisting for broad threat coverage, whitelisting for critical functions.

Virtual Patching

This is where WAFs prove their worth.

You discover a vulnerability in your application. The right fix is changing the code. But code changes need development, testing, and deployment—a process that takes weeks.

Attackers won't wait weeks.

A WAF can block exploitation attempts immediately. You create rules targeting the specific vulnerability, buying time while you develop the real fix.

This matters especially for legacy applications that are painful to modify, or third-party software where you don't control the source code. The vulnerability exists, you can't fix it directly, but you can prevent its exploitation.

Rate Limiting and Bot Protection

Beyond specific attack patterns, WAFs protect against abuse.

Rate limiting restricts how many requests a client can make in a time period. This stops brute force attacks on login forms, API abuse, and application-layer denial of service.

Bot detection distinguishes automated traffic from humans. Block malicious bots (vulnerability scanners, spam bots) while allowing legitimate ones (search engine crawlers).

CAPTCHA challenges verify human interaction when activity looks suspicious.

API Protection

Modern WAFs extend to APIs, not just traditional web pages.

API-specific protections include schema validation (rejecting requests that don't match expected structures), authentication enforcement, payload inspection for API-specific attacks, and granular rate limiting per endpoint or client.

As more functionality moves to APIs, this protection becomes essential.

The Tuning Problem

WAF deployment isn't plug-and-play.

The challenge: distinguishing attacks from legitimate-but-unusual traffic.

A developer searching your documentation for "SQL syntax" might trigger SQL injection rules. A user with an apostrophe in their name might look like a quotation attack. These false positives block real users.

Effective deployment requires tuning:

1. Start in detection-only mode—log potential attacks without blocking
2. Analyze logs to identify false positives
3. Adjust rules to exempt legitimate patterns
4. Gradually enable blocking
5. Continue monitoring and refining

Well-tuned WAFs achieve high security with minimal disruption. But tuning requires expertise and ongoing attention. It's not a set-and-forget technology.

Deployment Models

Hardware appliances — Dedicated devices in your datacenter. High performance, complete control. Requires capital investment and maintenance.

Virtual appliances — VMs in your infrastructure. Flexible, integrates with virtualized environments. Shares resources with other workloads.

Cloud-based WAFs — Traffic routes through the provider's infrastructure. Rapid deployment, automatic scaling, no hardware. Creates dependency on the provider.

Embedded WAFs — Integrated into web servers or application platforms. Tight integration, simple deployment. May offer less comprehensive protection than dedicated solutions.

What WAFs Can't Do

WAFs are powerful but not complete solutions.

They mitigate exploitation but don't fix vulnerable code. The underlying weakness remains.

They have limited visibility into business logic flaws that don't involve recognizable attack patterns. If your application lets users transfer money to any account without verification, a WAF won't catch that—there's no malicious payload to detect.

They can't protect against client-side attacks or anything that doesn't flow through HTTP/HTTPS.

WAFs work best as one layer in defense-in-depth: secure coding, regular security testing, prompt patching, strong authentication, and comprehensive monitoring.

Compliance Requirements

Many compliance frameworks require or recommend WAFs.

PCI DSS requires WAFs for Internet-facing payment applications. The requirement can technically be met through code review and testing instead, but WAFs are usually more practical.

Other regulatory frameworks recommend WAFs as best practice for applications handling sensitive data.