What Is Web Application Firewall (WAF)?

A WAF sits in front of an application and inspects HTTP traffic, blocking what matches known attack patterns or deviates from expected behaviour. It is genuinely useful and it is routinely sold as something it is not: a substitute for fixing the application.

The honest framing is that a WAF buys time. It blocks opportunistic and automated attacks, and it can hold the line on a known vulnerability while a fix is developed and deployed. It does not make a vulnerable application safe.

What it catches, and what walks straight through

The reason is structural. A request that reads another customer's record by changing an identifier is a perfectly valid HTTP request from an authenticated user. There is no payload to match and no anomaly to detect — the application is doing exactly what it was asked.

Running one well

• Start in detection mode. Blocking from day one generates false positives that break legitimate traffic and destroy confidence in the control.
• Tune against real traffic for several weeks before enforcing, and expect application-specific exceptions.
• Log to the SIEM. A WAF is a rich detection source and is frequently deployed with nobody reading its output.
• Use virtual patching deliberately — when a flaw is known and a fix is weeks away, a targeted rule is exactly the right tool.
• Review exceptions periodically, because a broad exception added to unblock a release tends to become permanent.

Where it fits in the stack

A WAF is a compensating control, not a primary one. It belongs alongside secure development, not instead of it — and the compliance frameworks that reference one generally accept it as mitigation rather than remediation.

Rate limiting deserves a mention here because it is often configured on the same device and addresses a different problem: abuse of legitimate functionality, such as credential stuffing or enumeration through a password reset. See rate limiting in practice.

Managed rules, and the illusion of coverage

Most deployments run a vendor-managed rule set, which is sensible: maintaining signatures is specialist work and the vendor does it full time. It also creates a quiet assumption that coverage is someone else's responsibility.

Managed rules protect against known, general attack patterns. They know nothing about your application — which endpoints are sensitive, which parameters carry identifiers, what a normal request volume looks like for a given user. The rules that would catch abuse specific to your business are ones only you can write, and most organisations never write any.

The practical middle ground is to keep the managed set for baseline coverage and add a small number of custom rules around the handful of endpoints that matter most: authentication, password reset, payment, bulk export. Those five or six rules typically deliver more real protection than the rest of the configuration combined.

Where to start

Check whether your WAF is in blocking or detection mode, and whether anyone reads its logs. A substantial proportion of deployed WAFs are in detection mode indefinitely and feeding a log nobody monitors, which provides the compliance artefact and none of the protection.

See application security and API security. GuardsArm delivers application penetration testing.