# Web Application Firewall (WAF) Explained
A traditional network firewall decides which ports and IPs can talk to your servers. It knows nothing about HTTP. A Web Application Firewall (WAF) works one layer up — it inspects the actual HTTP requests and responses flowing to your application and blocks the malicious ones. This guide explains what a WAF does, what it catches, and where its limits are.
Where a WAF sits
A WAF is a reverse proxy in front of your application. Every request passes through it:
Client → CDN/Edge → WAF → Load balancer → Your appBecause it terminates and parses HTTP, it can read headers, query strings, cookies, and bodies — and decide to allow, block, challenge, or log each request before your code ever runs.
What a WAF protects against
The canonical reference is the OWASP Top 10. A WAF is particularly good at catching:
- SQL injection — requests containing
' OR 1=1--and similar payloads. - Cross-site scripting (XSS) —
and event-handler injection in parameters. - Path traversal —
../../etc/passwdstyle attempts. - Remote code execution probes — known exploit signatures (Log4Shell-style payloads).
- Bad bots and scrapers — clients that do not behave like real browsers.
- Application-layer DDoS — floods of HTTP requests, often paired with rate limiting.
How a WAF decides
There are two broad detection models, and modern WAFs blend them.
Negative security model (blocklist)
Match requests against a library of known-bad signatures. The OWASP Core Rule Set (CRS) is the open-source standard here, used by ModSecurity and many commercial WAFs. Pros: works out of the box, catches known attacks. Cons: signatures lag novel attacks and can produce false positives.
Positive security model (allowlist)
Define what *good* traffic looks like — expected paths, methods, parameter types — and reject everything else. Far stricter and fewer false negatives, but high maintenance because every legitimate change needs a rule update.
Many teams run CRS in the negative model and layer a few positive rules around sensitive endpoints like /admin or /login.
Detection rule example
A simplified ModSecurity-style rule blocking an obvious SQLi pattern:
SecRule ARGS "@detectSQLi" \
"id:1001,\
phase:2,\
block,\
msg:'Possible SQL Injection',\
severity:CRITICAL"In practice you rarely write these by hand — you enable a managed ruleset and tune exceptions.
The false-positive problem
The single biggest WAF challenge is blocking legitimate traffic. A rule that flags SQL keywords might block a user whose blog comment contains the word SELECT, or a developer pasting a SQL snippet into a support form.
The safe rollout pattern:
- 1Deploy in detection-only / log mode. Watch what *would* have been blocked.
- 2Tune exceptions for the false positives you see (specific paths, parameters).
- 3Switch to blocking once the noise is gone.
- 4Keep monitoring — new features create new false positives.
Never flip a fresh WAF straight into blocking mode on production. You will page yourself.
What a WAF does NOT do
Be clear-eyed about the limits:
- It is not a substitute for secure code. Parameterized queries stop SQLi at the source; a WAF is a backstop.
- It cannot fix business-logic flaws (e.g. letting a user change another user's order ID).
- It does little against volumetric L3/L4 DDoS — that needs upstream network capacity.
- It can be bypassed by novel or heavily obfuscated payloads.
Think of a WAF as one layer of defense in depth, not the whole castle.
Managed vs self-hosted
| Self-hosted (ModSecurity/Coraza) | Managed (cloud WAF) | |
|---|---|---|
| Control | Full | Provider-defined |
| Maintenance | You patch and tune | Provider updates rules |
| Scale | Your infra | Provider's edge network |
| Cost | Compute + your time | Subscription/usage |
Most teams are better served by a managed WAF at the edge — rule updates and global scale come for free, and you spend your time on app-level fixes.
WAF on PandaStack
PandaStack includes a web application firewall and DDoS protection in front of deployed apps, running at the Cloudflare/Kong edge before traffic reaches your container. You get managed protection without standing up your own ModSecurity fleet, and you still own the in-app hardening — parameterized queries, input validation, and least-privilege access — that no WAF can replace.
References
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [OWASP Web Application Firewall page](https://owasp.org/www-community/Web_Application_Firewall)
- [Cloudflare: What is a WAF?](https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/)
---
A WAF is a powerful backstop, but it works best as one layer alongside secure code and edge DDoS protection. PandaStack bundles a WAF with every deployment — try it free at [dashboard.pandastack.io](https://dashboard.pandastack.io).