Cybersecurity glossary
What is a Web Application Firewall (WAF)?
Learn what a Web Application Firewall (WAF) is, how it filters HTTP attacks, where it sits in the architecture, limits of WAFs, and how to combine WAF with secure coding.
Definition
A Web Application Firewall (WAF) is a security control that monitors, filters, and blocks HTTP/HTTPS traffic to and from a web application based on rules and models designed to detect attacks such as SQL injection, XSS, and known exploit patterns.
Why WAFs are widely deployed
Web apps face constant automated probing for SQLi, XSS, path traversal, and known CVEs. A Web Application Firewall (WAF) adds a shared detection layer in front of many services—especially useful when patching lags or legacy apps cannot change quickly.
A WAF is valuable. It is not a magic shield.
Where a WAF sits
Client sends HTTP(S)
Browsers or APIs call your public hostname.
Traffic hits the WAF
Cloud proxy, CDN edge, or reverse-proxy module inspects the request.
Rules evaluate the request
Signatures, scoring, bot signals, and custom policies decide allow/block.
Allowed traffic reaches the app
Blocked requests never hit vulnerable code paths.
What WAFs typically cover
Injection patterns
Common SQLi, XSS, command injection, and path traversal signatures.
Protocol abuse
Malformed requests, oversized headers, and some HTTP smuggling symptoms.
Known exploits
Virtual patching for published CVEs while you roll real fixes.
Rate and bot controls
Throttle credential stuffing and noisy scanners (often adjacent features).
Strengths and limits
| Strength | Limit |
|---|---|
| Fast virtual patching | Bypasses and false positives require tuning |
| Shared defense for many apps | Blind to encrypted app-layer logic bugs |
| Visibility into attack traffic | Logs can be noisy without good baselines |
| Complements secure coding | Cannot replace authz and business-logic fixes |
- Deploy WAF in front of public web and API entry points.
- Start with established rule sets (e.g., OWASP CRS) and tune carefully.
- Use detect/log mode before aggressive blocking on sensitive apps.
- Create exception processes that do not silently disable broad protection.
- Integrate WAF alerts into SOC workflows with clear severity.
- Track false positives so developers are not trained to ignore the WAF.
- Pair WAF with patching SLAs—virtual patches are temporary.
- Test bypasses periodically; do not assume signature coverage is complete.
The practical takeaway
A WAF filters dangerous HTTP traffic before it reaches your application. Use it as layered defense—especially for virtual patching—while you fix root causes in code.
If the WAF is your only application security control, you are one creative bypass away from an incident.
Related security terms
Frequently asked questions
What is a WAF in simple terms?
It is a filter that sits in front of your website or API and tries to block malicious HTTP requests before they reach the application.
Does a WAF replace secure coding?
No. A WAF is defense in depth. Fix vulnerabilities in code; use the WAF to reduce exploitability and buy response time.
Where does a WAF run?
Commonly as a cloud reverse-proxy service, a CDN feature, an appliance, or software (e.g., ModSecurity) on a reverse proxy.
What is the OWASP CRS?
The OWASP Core Rule Set is a maintained collection of generic attack-detection rules used by many WAF deployments.
Can attackers bypass WAFs?
Yes. Encoding tricks, logic flaws, and novel payloads can evade signatures. Tuning and app fixes remain essential.
Will a WAF stop business logic abuse?
Usually not reliably. Logic flaws need application design fixes and targeted rules or bot controls.
References
Explore authoritative guidance and frameworks related to web application firewall (waf).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.