Web Application Firewall
A Web Application Firewall (WAF) sits between users and your app, inspecting HTTP traffic to block SQL injection, XSS, DDoS and known bot signatures on the fly.
Complement Your WAF
Add advanced bot protection to your WAF strategy
What is a Web Application Firewall (WAF)?
A web application firewall inspects HTTP traffic between the internet and your application, and blocks requests that match patterns it recognises as attacks. It sits at layer 7, so unlike a network firewall it can read URLs, headers, cookies and request bodies.
A WAF is good at one job: stopping requests that are malformed or that carry a known attack payload. It is weak at a different job that people often expect of it, which is telling a bot from a customer.
How it decides
Three mechanisms, usually running together:
| Mechanism | What it does | Where it fails |
|---|---|---|
| Signature rules | Matches request content against known attack patterns, as in the OWASP Core Rule Set | Novel payloads, and encodings the rules do not normalise |
| Positive security model | Allows only requests matching a declared schema | Needs an accurate schema and breaks when the API changes |
| Anomaly scoring | Adds up suspicion across several weak rules before blocking | Threshold tuning, and the false positives that follow |
Deployment is either a reverse proxy in front of the application, a module inside the web server, or a cloud service your DNS points at. The trade is the usual one: the cloud option is quickest and terminates your TLS, the in-process option keeps traffic local and gives you the configuration work.
A WAF reads content; bot traffic is a pattern
Being precise here matters, because this is where buyers get caught.
A WAF reads the content of a request. A bot problem is rarely about content. A credential stuffing attempt is a perfectly well-formed login POST, a scraper's GET is a perfectly well-formed GET, and an inventory-hoarding script uses the same add-to-basket call your customers do. There is no payload to match, because nothing about any single request is wrong — the problem is the pattern across thousands of them, and the absence of a human behind them.
Most WAF products now ship a bot module for exactly this reason, and those modules are the part of the bundle to scrutinise: they need signals a network vendor has no particular reason to collect, such as browser behaviour over the session. The cost is also usually bundled, which makes it hard to compare against a standalone quote — see our enterprise pricing comparison for how that works out in practice.
Using both
The two layers answer different questions, and a reasonable setup runs both:
- The WAF rejects malformed and malicious payloads — injection attempts, path traversal, known exploit signatures
- A bot layer decides whether a well-formed request has a person behind it, using behavioural analysis and, where it is needed, a challenge-response check
Run a WAF in monitoring mode first. Signature rules in blocking mode on day one will break something real, and the fix is always to learn which rules misfire on your own traffic before they can reject a customer.