What Is a Web Application Firewall (WAF)?
A web application firewall (WAF) sits in front of or inside your web server and inspects every HTTP request, blocking SQL injection, cross-site scripting, path traversal and brute-force logins before they reach your code. Unlike a network firewall, it reads the URL, headers and form data. It complements, but never replaces, updates and secure code.
For site owners and developers deciding how a WAF fits with firewalls, DDoS protection and updates, and how to fix false-positive blocks.
knowledge
- Read time
- 5 min
- Sections
- 6
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 14 November 2026.
What does a web application firewall actually do?
A web application firewall (WAF) inspects each HTTP request before it reaches your application and allows, blocks, challenges or logs it based on rules about the URL, headers, cookies and body. It works at Layer 7, so it can see an SQL injection string inside a form field that a network firewall, which only sees IPs and ports, lets through on port 443.
The WAF either runs inside the web server (ModSecurity on Apache, LiteSpeed or Nginx) or as a reverse proxy in front of the site (a cloud WAF that your DNS points to). In both cases it reads the decrypted request, compares it with its rule set and, on a match, returns a 403, a CAPTCHA or JavaScript challenge, or just a log entry, depending on the rule's mode.
What it cannot see matters as much. A WAF has no view of your database, session logic or prices, so a well-formed request that abuses business logic passes. It also knows only what its rules describe.
How is a WAF different from a network firewall and DDoS protection?
A network firewall decides by address and port, a WAF decides by request content, and DDoS protection decides by volume and rate. They sit at different layers and fail in different ways, which is why a business site often uses more than one.
| Control | Layer | Inspects | Stops | Misses |
|---|---|---|---|---|
| Network firewall | 3–4 | Source IP, port, protocol, connection state | Port scans, closed services, blocked IP ranges | SQL injection on allowed port 443 |
| Web application firewall | 7 | URL, headers, cookies, request body | SQL injection, XSS, path traversal, bad bots, known exploit paths | Packet floods; logic flaws with no rule |
| DDoS protection | 3–7 | Packets and requests per second, connection counts | SYN, UDP and HTTP request floods | A single valid-looking malicious request |
Antivirus and CDNs are often confused with a WAF too. Antivirus scans files on disk for known malware, and a CDN caches responses near visitors; neither judges a request's intent. Volume attacks are covered in what DDoS protection is, and the difference between appliance and server firewalls in hardware vs software firewalls.
Which attacks does a WAF block, and where does it fail?
A WAF blocks request patterns behind SQL injection, cross-site scripting, file inclusion, path traversal, command injection, XML external entities and server-side request forgery, and it rate-limits brute-force logins. In OWASP Top 10 terms, it is strongest against the Injection and Authentication Failures categories.
- Blocks well:
' OR 1=1--style payloads,<script>injections,../../etc/passwdtraversal, probes for known plugin exploit paths. - Slows down: credential stuffing against
wp-login.phpandxmlrpc.php, aggressive scrapers and vulnerability scanners. - Cannot fix: an outdated plugin, a weak admin password, a misconfigured server or a flaw in your own checkout logic.
- Zero-days: no signature exists until someone writes one, though generic injection rules sometimes catch new exploits anyway.
Think of a WAF as the buffer between a vulnerability's disclosure and your update, not as the update. Most compromised sites in cleaning a hacked website were running a known-vulnerable component.
ModSecurity and the OWASP Core Rule Set: how a self-hosted WAF works
ModSecurity is the open-source WAF engine most hosting servers run, and the OWASP Core Rule Set (CRS) is the free rule set loaded into it. ModSecurity moved from Trustwave to the OWASP Foundation in 2024; CRS version 4 is the current major release.
CRS uses anomaly scoring: each rule that matches adds points, and the request is blocked only when the total crosses a threshold (5 by default for inbound requests). A paranoia level from 1 to 4 controls how strict the rules are; level 1 is the default and produces the fewest false positives.
# modsecurity.conf: log matches without blocking while you tune
SecRuleEngine DetectionOnly
# switch to blocking once false positives are handled
SecRuleEngine On
# CRS setup: keep paranoia level 1 for most sites
SecAction "id:900000,phase:1,pass,nolog,setvar:tx.paranoia_level=1"Cloud WAFs work on the same principle but the vendor writes and updates the rules. The choice is mostly about who maintains them: a managed rule set needs a DNS change and is often billed per domain or request, while a server-level WAF adds no network hop but uses your server's CPU and RAM.
How do you tune a WAF without blocking real customers?
Run new rules in detection-only mode first, then exclude the single rule ID that misfires on a specific path or field instead of switching off a whole category. Most false positives are one rule matching something legitimate, such as a long comment, a rich-text editor or your checkout's JSON body.
- Run the rule set in log-only mode for about a week and collect what it would have blocked.
- Read each audit-log entry for the rule ID, URI and matched variable.
- Write a narrow exclusion for that rule on that path, for example:
SecRule REQUEST_URI "@beginsWith /checkout/" "id:10001,phase:1,pass,nolog,ctl:ruleRemoveTargetById=942100;ARGS:order_notes" - Retest login, checkout, search, file upload and admin screens, then enable blocking.
Watch the 403 count and the support inbox together after each change. Scanners do not email you; blocked customers do. For WordPress-specific hardening alongside the WAF, use the WordPress security checklist.
Where does a WAF sit on a WebJi® hosting account?
On WebJi® cPanel hosting, filtering runs at server level through ModSecurity or Imunify360, so there is nothing to install and no DNS change to make. If a rule blocks a legitimate form, email support@webji.services with the URL, the time and the 403 message; support replies 24/7 in Hindi and English. Rule reviews and custom exclusions through WebJi® website security services are quoted before payment, and WordPress security services cover the updates a WAF cannot.
Frequently asked questions
Does a WAF replace secure coding against SQL injection?
No. Parameterised queries and output encoding in the application are the real fix. A WAF is a second line that catches payloads the code fails to handle, and it can be bypassed by unusual encodings, so it should never be the only protection.
Is Cloudflare a WAF?
Cloudflare is a reverse proxy that includes a cloud WAF among its features; it is one vendor in the category, not the category itself. Using it means pointing your DNS through Cloudflare, and it can be combined with a server-level WAF such as ModSecurity.
Will a WAF slow down my website?
Usually only by milliseconds. A cloud WAF adds a short network hop but may also cache content. A server-level WAF uses CPU and RAM on each request, so on a small plan the rule set's size and paranoia level matter more than the WAF's existence.
What does a ModSecurity 403 Forbidden error mean?
A rule matched your request and the engine blocked it. The server's audit log records the rule ID and the field that triggered it. Share the URL and time with your host so they can add a targeted exclusion; other causes of 403 are in the 403 Forbidden fix guide.
Checked 14 November 2026 against the OWASP ModSecurity and Core Rule Set documentation · Reviewed by the WebJi® team, Jaipur.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.