WAF

A WAF is a reverse proxy that every request to your application passes through. It reads the full HTTP request (URL, headers, cookies, query string, and body) and decides whether to allow it, block it, or flag it before the request ever touches your application code.

The key difference from a normal network firewall is the layer it works at. A network firewall operates at layers 3 and 4, so it only sees IP addresses, ports, and protocols. A WAF operates at layer 7, the application layer, so it can read that a form field contains the string ' OR 1=1-- and recognize it as a SQL injection attempt.

WAFs are most often described in terms of the OWASP Top 10, the industry list of the most common web vulnerabilities. A good WAF ships with rules that cover injection, broken access patterns, XSS, and similar categories out of the box, then lets you add your own rules on top.

A WAF inspects requests using two broad strategies. A negative security model (a blocklist) looks for known-bad patterns: signatures and regular expressions that match attack payloads. The widely used OWASP Core Rule Set is a negative model with hundreds of these rules. A positive security model (an allowlist) does the opposite and only permits requests that match a known-good schema, rejecting everything else.

Each rule typically carries a score rather than an instant block. The OWASP Core Rule Set, for example, adds points for each suspicious signal a request triggers, and only blocks once the total crosses a threshold (commonly 5). This anomaly scoring reduces false positives, since one weak signal alone will not get a legitimate user blocked.

Modern WAFs add layers beyond signatures: rate limiting to stop brute force and scraping, bot detection, geo and IP reputation lists, and managed rule sets that the vendor updates as new attacks appear. Many run in two modes, detection (log only, no blocking) so you can tune rules safely, and prevention (actively block), which is what you switch to once tuned.

Use a WAF when you have a public web application or API that accepts user input, especially if you handle logins, payments, or personal data. It is also a fast way to satisfy compliance requirements: PCI DSS, the payment card standard, effectively requires either a WAF or regular code review for public-facing apps.

A WAF is not a replacement for secure code. It is a layer of defense in depth. Attackers find encodings and edge cases that slip past signatures, so a WAF that catches 95 percent of attacks still lets the other 5 percent through if your code itself is vulnerable. Treat it as a safety net, not the whole net.

The main costs are latency and false positives. Every request now passes through an extra hop and inspection step, usually adding single-digit milliseconds with a cloud WAF but more if self-hosted poorly. False positives are the bigger operational pain: an over-aggressive rule can block real customers, so teams almost always run in detection mode first and tune for days before turning on blocking.

Say your app has a search box that builds a SQL query. An attacker submits the search term ' UNION SELECT password FROM users--. Without a WAF, that string reaches your code, and if the query is not parameterized, the attacker dumps your password table.

With a WAF in front, the request is inspected first. The OWASP rule for SQL injection matches the UNION SELECT pattern and the comment sequence --, the anomaly score crosses the threshold, and the WAF returns a 403 Forbidden. Your application never sees the request, and the event is logged so your security team can see the source IP and block it.

In practice you would deploy this by pointing your DNS at the WAF (as with Cloudflare or AWS) or running it as a module in front of your servers (as with ModSecurity on Nginx), then watching the logs in detection mode before flipping to active blocking.