If DDoS defense is crowd control at the gate, a WAF is the guard who searches each bag for weapons. One stops too many people; the other stops the dangerous ones. This post covers what a WAF is, the attacks it blocks, and how you actually run one.
What a WAF is (and isn't)
WAF = Web Application Firewall. It inspects web traffic and blocks malicious requests before they reach your app.
| It IS | It ISN'T |
|---|---|
| A filter for web request content | A network firewall (ports/IPs) |
| A blocker of injections, XSS, bad bots | A replacement for writing secure code |
| Working at the application layer | Working at the network layer |
Where it sits
User → [ WAF ] → Your App
↑ inspects every request BEFORE it reaches you
Everything passes through the guard first.
The attacks it blocks (the OWASP "greatest hits")
OWASP publishes the famous list of the worst web vulnerabilities. Here are the big ones a WAF catches, in plain words:
| Attack | Plain meaning | Example |
|---|---|---|
| SQL Injection | Sneaking database commands through an input box | Typing '; DROP TABLE orders;-- into search |
| XSS | Injecting malicious JavaScript into a page | A review with <script> that steals cookies |
| CSRF | Tricking you into an action you didn't intend | A hidden form placing an order as you |
| Path traversal | Escaping to files you shouldn't reach |
../../etc/passwd in a URL |
| Bad bots / scraping | Automated abuse | A bot copying every menu on the site |
How WAF rules work
There are two philosophies, plus who maintains them:
| Model | How it works | Trade-off |
|---|---|---|
| Blocklist | Block known-bad patterns | Misses brand-new attacks |
| Allowlist | Allow only known-good | Very safe, lots of upkeep |
| Managed rules | Vendor keeps the rule set updated | Easiest, less control |
| Custom rules | Your own (block a region, rate-limit an IP) | Flexible, you maintain it |
How it decides to block
| Method | How |
|---|---|
| Signatures | Match a known attack pattern |
| Anomaly scoring | Each suspicious trait adds points; over a threshold → block |
| Rate rules | Same IP over N requests/min → throttle |
The two modes (this trips everyone up)
| Mode | What it does | When to use |
|---|---|---|
| Detection | Logs threats, blocks nothing | Brand-new WAF — watch and learn first |
| Prevention | Actively blocks | After tuning, once you trust it |
Golden rule: always start in Detection. Study the logs. Then switch to Prevention. Flip to "block" too early and you'll lock out real customers.
Tuning — the real day-job
- A false positive = the WAF blocks a legitimate request (e.g. a valid order that happens to contain an odd character).
- You fix it with exclusions — "don't apply this rule to that field."
- A WAF is never set-and-forget. It's tuned continuously as your app changes.
On Azure
| Front Door WAF | App Gateway WAF | |
|---|---|---|
| Scope | Global (edge) | Regional |
| Best for | Public, global sites | Internal / regional apps |
WAF vs DDoS — the difference in one table
| DDoS defense | WAF | |
|---|---|---|
| Blocks | Too much traffic | Dangerous requests |
| Question | "Are there too many?" | "Is this one harmful?" |
| Analogy | Crowd control | Bag search |
They work together: DDoS defense stops the flood, the WAF searches whatever gets through.
The whole thing in one line
A WAF reads every web request and blocks the malicious ones — injections, scripts, bad bots. Start it in Detection mode, tune out the false alarms, then let it block.
Top comments (0)