A web application firewall, or WAF, sits in front of a website or web application and inspects every request before it reaches your code. Its job is to recognise and block attacks that look like ordinary web traffic: injection attempts, malicious bots, abuse of login forms and probes for known vulnerabilities. For many businesses it has become a standard layer of protection, but it works best when you understand what it is good at and where its limits are.
How a WAF differs from a network firewall
A traditional network firewall decides which connections are allowed, based on IP addresses and ports. It might allow anyone to reach port 443 for HTTPS and block everything else. Once a connection is allowed, it does not look at what is inside.
A WAF works one level higher. It understands HTTP, so it reads the address, headers, cookies and form data of each request and judges whether the content is malicious. A request to your search page containing a SQL injection payload passes a network firewall without question; a WAF can stop it.
| Network firewall | Web application firewall | |
|---|---|---|
| Looks at | IP addresses, ports, protocols | HTTP requests and responses |
| Stops | Unwanted connections to services | Attacks hidden inside web traffic |
| Typical example | Only allow ports 80 and 443 | Block a request containing a script injection |
You need both. The network firewall reduces what is exposed; the WAF protects what has to be exposed.
What a WAF protects against
- Injection attacks such as SQL injection and command injection.
- Cross-site scripting (XSS), where attackers try to plant scripts in pages other users will view.
- Known vulnerabilities in popular software. When a flaw in a common CMS or plugin is published, WAF vendors often add a rule within hours, protecting you until you can update.
- Brute-force and credential-stuffing attacks on login pages, through rate limiting.
- Bad bots scraping content, filling forms with spam or hunting for weaknesses.
- Application-layer denial of service, where floods of expensive requests aim to exhaust your server.
How WAFs decide what to block
Most WAFs combine several methods:
- Signature rules match known attack patterns. The OWASP Core Rule Set is a widely used open-source collection.
- Anomaly scoring adds up suspicious traits in a request and blocks it once the score passes a threshold, which reduces false alarms compared with single strict rules.
- Rate limits cap how many requests a client can make to a given page in a given time.
- Reputation and bot detection use data about IP addresses and browser behaviour seen across many sites.
- Custom rules that you write, such as restricting an admin area to your office IP addresses.
Deployment options
Cloud WAF
Your DNS points visitors to the provider's network, which filters traffic and forwards clean requests to your server. Setup is quick, there is no hardware to manage, and it usually comes with a CDN and DDoS protection. The trade-off is that your traffic passes through a third party, and you must make sure attackers cannot bypass it by reaching your server's real IP address directly.
Server-based WAF
Software such as ModSecurity runs on the web server itself, often alongside Apache or Nginx. Many hosting control panels include it. It costs little, but it uses your server's resources and needs someone to maintain the rules and handle false positives.
Platform WAF
Major cloud platforms offer WAF services that attach to their load balancers and gateways. They suit applications already hosted on that platform and integrate with its logging and access controls.
What a WAF cannot do
- It does not fix your code. A WAF reduces the chance that a vulnerability is exploited; the vulnerability is still there.
- It cannot see business-logic flaws. If your application lets one customer view another's invoice by changing a number in the address, each request looks perfectly normal.
- It can block real users. Overly strict rules can reject legitimate form submissions, for example a support message that quotes code. Plan time to review blocks and tune rules.
- It does not replace updates. Virtual patching buys time; it is not a reason to skip the real patch.
Getting started sensibly
- Start in monitoring or log-only mode for a week or two to see what would be blocked.
- Review the results, add exceptions for legitimate traffic, then switch to blocking.
- Protect login, password reset and contact forms with rate limits.
- If you use a cloud WAF, allow only its IP ranges to reach your origin server.
- Check your response headers afterwards with the HTTP header checker to confirm the WAF and your security headers are in place.
Key takeaways
- A WAF inspects web requests and blocks attacks a network firewall cannot see.
- It is especially useful against injection, known CMS vulnerabilities, bots and login abuse.
- Cloud, server-based and platform WAFs suit different setups and budgets.
- It complements secure code and timely updates; it does not replace them.