How Does A Web Application Firewall Work? | Attacks It Stops

Guide / By

A WAF checks HTTP traffic, blocks risky requests, and lets clean browser actions reach the app.

A web application firewall sits between a visitor and a web app. It reads each HTTP or HTTPS request before the request reaches the origin server. Then it compares that request against rules, app patterns, threat signals, and rate limits.

That makes it different from a network firewall. A network firewall filters traffic by ports, protocols, and IP ranges. A WAF reads the app layer: URLs, headers, cookies, query strings, request bodies, file uploads, and methods such as GET or POST.

The payoff is simple: a WAF can stop many web attacks before your code has to deal with them. It won’t fix weak code, bad passwords, or broken access rules by itself, but it can cut down noise, slow abuse, and block request patterns tied to known exploits.

How A Web Application Firewall Works In Live Traffic

When a browser, bot, or API client sends a request, the WAF becomes a checkpoint. In a cloud setup, that checkpoint often sits at the edge. In a self-hosted setup, it may run as a reverse proxy, appliance, server module, or sidecar near the app.

The WAF parses the request into parts. It checks the IP, country, URL path, query string, headers, cookies, body size, content type, and payload text. If the request matches a block rule, the WAF can deny it before the app sees it.

Many WAFs also score requests. A single odd header may not be enough to block someone. A strange user agent, suspicious payload, repeated login hits, and a risky URL path together can push the request over a risk threshold.

What The WAF Reads

A WAF is strong when it sees the parts of a request that attackers like to abuse. It may inspect:

  • URL paths, such as /admin or /wp-login.php
  • Query strings, such as search terms, filters, and tracking fields
  • Headers, including user agent, host, origin, and referrer
  • Cookies and session tokens
  • POST bodies from forms, logins, carts, uploads, and API calls
  • Request rate from a single IP, subnet, user, or session

This is why WAF tuning matters. A checkout form, login form, CMS editor, and JSON API don’t all behave the same way. Good rules match the way the app is meant to work.

What Happens After A Match

Once the WAF finds a match, it can take several actions. The strictest action is block, which returns a denial page or status code. Softer actions include logging, challenge pages, JavaScript checks, CAPTCHA, rate limiting, header changes, or allowlisting trusted traffic.

Smart teams often start new rules in log mode. That shows what would have been blocked without breaking real users. After reviewing the logs, they switch clean rules to block mode and add exceptions for safe app behavior.

Rule Types That Drive WAF Decisions

Most WAF decisions come from several rule layers working together. OWASP’s WAF definition describes a WAF as a firewall for HTTP apps that applies rules to HTTP conversations. That rule-based model is still the base idea, but current WAFs often add managed threat feeds, bot checks, rate controls, and custom logic.

Managed rules save time because vendors and security groups maintain patterns for common attacks. Custom rules close gaps tied to your own app, such as blocking access to admin paths from unknown countries or rejecting requests with odd content types.

WAF Check What It Looks For Likely Action
SQL Injection Database commands or stacked queries inside form fields, URLs, or cookies Block, log, or challenge
Cross-Site Scripting Script tags, event handlers, encoded payloads, or unsafe HTML in inputs Block or sanitize when available
Path Traversal Attempts to reach files outside allowed directories, such as ../ patterns Block and log
Bad Bots Scraping patterns, fake browsers, missing headers, or odd request pacing Challenge, slow, or block
Login Abuse Repeated password attempts, credential stuffing, or high fail rates Rate limit or challenge
Known Exploit Paths Requests for vulnerable plugin files, admin scripts, or old endpoints Block
Oversized Requests Headers, cookies, or bodies larger than expected for the app Block or send to review logs
Geo Or IP Rules Traffic from regions, networks, or IPs outside the site’s normal pattern Allow, block, or challenge

Managed Rules Versus Custom Rules

Managed rules are prebuilt sets from a WAF vendor or trusted security project. They help with common attacks, and they get updates when new attack patterns appear. Cloudflare Managed Rules are one example of preconfigured WAF rulesets built for common attack classes.

Custom rules are written for your app’s real traffic. A recipe site, bank portal, SaaS dashboard, and game API won’t share the same safe request patterns. Custom rules can block odd admin access, reject unknown API clients, or challenge high-rate traffic to one endpoint.

The best setup usually blends both. Managed rules catch known patterns. Custom rules protect the app’s own weak spots, business rules, and traffic habits.

Where A WAF Fits In Your Stack

A WAF can sit in several places. The location changes latency, visibility, cost, and ease of setup. The common choices are cloud edge WAF, load balancer WAF, reverse proxy WAF, and server plugin WAF.

A cloud edge WAF filters requests before they reach your hosting network. That can reduce origin load during bot spikes. A load balancer WAF filters traffic closer to the app. A reverse proxy gives more control but needs more care from the engineering team.

AWS describes this model through web ACLs, where protected resources forward incoming requests for inspection before a response decision is made. Their AWS WAF web ACL documentation shows how rules attach to resources such as CloudFront, API Gateway, and load balancers.

Placement Good Fit Trade-Off
Cloud Edge Public sites, APIs, stores, and apps hit by global traffic Less control over vendor rule internals
Load Balancer Cloud apps already using managed load balancers Traffic reaches the cloud account before filtering
Reverse Proxy Teams that want tight control over headers, routing, and logs More setup and upkeep work
Server Plugin Smaller apps on known web server stacks Origin still handles more attack traffic

What A WAF Can And Can’t Stop

A WAF is strongest against malicious request patterns. It can block many SQL injection attempts, cross-site scripting probes, file inclusion attempts, path traversal, known exploit scans, and noisy bots. It can also slow brute-force login attempts with rate limits and challenges.

It is weaker when an attack looks like normal app usage. If a logged-in user has access to data they shouldn’t see, that is usually an authorization flaw in the app. If an admin password is stolen, a WAF may spot odd location or device clues, but the real fix is stronger identity controls.

A WAF also needs tuning. Strict rules can block real customers during checkout, search, file upload, or admin editing. Loose rules may let too much through. The right balance comes from logs, safe test traffic, staging checks, and short rule reviews after major app changes.

Good WAF Setup Habits

Start with the app’s riskiest entry points. Login, registration, checkout, search, comment forms, upload forms, and API write endpoints deserve more care than static pages.

  • Run new rules in log mode before blocking.
  • Track false positives by URL, rule ID, user agent, and request field.
  • Add exceptions only where the app truly needs them.
  • Pair WAF logs with app logs so teams can see what happened.
  • Review rules after plugin updates, app releases, and traffic spikes.
  • Use rate limits on costly endpoints such as login and search.

Signals Your WAF Is Doing Its Job

A healthy WAF setup has fewer junk requests hitting the origin, fewer login bursts, clear block logs, and low false positives. The team can explain why a rule exists and what risk it reduces. That matters more than a long list of rules nobody checks.

When a user reports a block, the team should be able to find the event, see the matched rule, inspect the request part, and decide whether to allow, tune, or keep blocking. Good WAF work is steady housekeeping, not a one-time switch.

Final Checks Before You Trust A WAF

A WAF works best as one layer. Keep secure coding, patching, access control, backups, monitoring, and identity checks in place. The WAF reduces bad traffic before it hits the app, but the app still needs to be safe when a request passes.

For most sites, the clean setup is simple: managed rules on, log mode for new changes, custom rules for risky paths, rate limits on abuse-prone forms, and a monthly review of blocks and exceptions. That gives the WAF enough room to stop attacks while real readers, buyers, and users stay on track.

References & Sources