What Is a Web Application Firewall (WAF)?

What Does a Web Application Firewall Actually Do?

A web application firewall (WAF) is a reverse proxy that reads each HTTP request before it reaches your site and decides whether to allow, block or challenge it. It filters at the application layer, Layer 7, on URLs, headers, cookies and form data, so it catches SQL injection and cross-site scripting that a network firewall cannot inspect.

Traffic resolves to the WAF first. It terminates TLS or reads the decrypted stream, inspects the request line, path, query string, headers, cookies and body up to a configured size, then forwards what passes to the application. A match returns a 403, a CAPTCHA, a JavaScript challenge or a log entry, depending on the mode the rule runs in.

What it cannot see matters as much as what it can. The WAF has no view of your database queries or session state, so a well-formed request that is wrong for your business logic passes. It also only scores what its rules describe, which is why a rule set from last year misses this month's plugin exploit.

How Is a WAF Different From a Firewall and DDoS Protection?

A network firewall decides by address and port, a WAF decides by the content of the HTTP request, and DDoS protection decides by traffic volume and rate. They sit at different layers and fail in different ways, which is why a site under real threat usually runs more than one.

Two neighbouring products get confused with it. Antivirus scans files on a machine for known malware, and a CDN caches static responses closer to visitors. Neither reads a request for intent, so neither replaces a WAF. An DDoS protection service absorbs volume, and its Layer 7 rate limits overlap with what a WAF can do, but a WAF alone will not survive a volumetric flood.

Which Attacks Does a WAF Block, and Where Does It Fail?

It blocks the request shapes behind SQL injection, cross-site scripting, local and remote file inclusion, path traversal, command injection, XML external entities and server-side request forgery. It also handles credential stuffing and brute force against wp-login.php or xmlrpc.php as a rate-and-pattern problem rather than a code problem.

Mapped to the OWASP Top 10, a WAF covers most of A03 Injection and A07 Identification and Authentication Failures, and part of A01 Broken Access Control when the attack arrives as a recognisable request. It cannot fix A06 Vulnerable and Outdated Components, because only an update does that.

Three limits are worth stating plainly. A vulnerable plugin still runs after the WAF lets a valid-looking request through. Business-logic abuse, such as editing a price field in a cart, looks like normal traffic. And a zero-day has no signature until someone writes one. A WAF is a filter, not a patch: it buys the days between disclosure and your update, which is the window that hacked WordPress sites usually fall through.

Managed WAF Rules vs Self-Hosted Rules

Managed rules are written, tested and updated by a vendor, and you choose the rule set plus its exceptions. Self-hosted rules are files you install and maintain yourself, usually ModSecurity with the OWASP Core Rule Set. The difference is who carries the update work when a new CVE lands.

• Managed: signatures arrive without your patch window. Your control is limited to exclusions, and cloud vendors often bill per request or per domain.
• Self-hosted: ModSecurity with CRS is free to license and fully editable. You own the updates, the tuning and the CPU and RAM it consumes on your own server.
• Host-level: the middle case most shared accounts get. The host runs ModSecurity with a vendor-maintained set such as Imunify360 and applies per-account exclusions on request.

Imunify360 and ModSecurity both run inside the web server, so they need no DNS change and add no extra network hop. A cloud WAF sits in front of the site and needs the domain pointed at it. Neither is automatically better; the choice follows who on your side will read an alert at 2 a.m.

How Do You Tune a WAF Without Blocking Real Customers?

Start in detection-only mode and fix the rule that fires, not the whole rule set. Most false positives come from one rule ID matching a legitimate field, such as a long comment box or the JSON body from your own checkout.

• Run the new rule set in log-only mode for a week and collect the blocks it would have made.
• Read the audit log entry for the exact rule ID, the URI and the field that matched.
• Disable that rule ID for that path, or exclude the field, rather than turning off the category.
• Retest checkout, login, search, file upload and the admin screens, then re-enable blocking.

After each change, watch the 403 count and the support inbox together. A rule that blocks scanners also blocks the occasional customer on an old browser, and only the inbox tells you which one happened.

Where Does a WAF Sit on a WebJi® Hosting Account?

On WebJi® cPanel accounts the filtering runs at the server level through ModSecurity or Imunify360, so there is no appliance to install and no DNS change to make. The people who tune it sit behind our website security services in India.

Rule reviews and custom exclusions are quoted by email before any payment. WordPress security services cover the plugin and update side that a WAF cannot. Email support@webji.services with the URL and the block you are seeing.