Web Application Firewalls Explained

Your website is under attack more often than you think. Most of it is automated, bots scanning for known vulnerabilities in WordPress plugins, outdated PHP versions, or misconfigured login pages. A WAF sits between the internet and your website and decides what gets through. That sounds simple. The implementation is anything but.

What a WAF does

A standard network firewall monitors traffic at the IP and port level. It can block traffic from certain IP addresses or limit which ports are open. It has no understanding of what’s actually inside a web request.

A WAF operates at the application layer, HTTP and HTTPS traffic specifically. It reads the content of incoming requests: the URL, the headers, any data in the request body. It looks for patterns that match known attack signatures and blocks requests that look malicious before they reach your web application.

The key difference is understanding. A network firewall sees “traffic came from this IP to this port.” A WAF sees “this request contains a SQL injection attempt in the query string” and acts accordingly.

What a WAF blocks

SQL injection. Attackers try to insert SQL code into input fields (search boxes, login forms, contact forms) to manipulate your database. A successful SQL injection can expose user data, delete records, or give an attacker access to your entire database. WAFs detect the patterns these attacks follow and block them.

Cross-site scripting (XSS). An attacker injects malicious JavaScript into a page that gets executed in other users’ browsers. This can steal session cookies, redirect visitors to malicious sites, or capture keystrokes. WAFs filter out script injection attempts from request parameters.

Remote file inclusion and local file inclusion. Attacks that try to get your server to load and execute files from external locations or expose files it shouldn’t. Common against older, poorly maintained PHP applications.

Brute force attacks. A WAF can detect and throttle repeated login attempts from a single source, cutting off credential stuffing attacks before they get anywhere.

Bad bots and scrapers. Not all bots are malicious, but many are. Content scrapers, spam bots, and vulnerability scanners constantly crawl the web looking for targets. A WAF can identify and block non-legitimate bot traffic based on patterns and signatures.

Distributed Denial of Service (DDoS) at the application layer. Network firewalls handle volumetric DDoS. WAFs handle layer 7 DDoS, where attackers flood your site with legitimate-looking HTTP requests designed to exhaust your server resources rather than your bandwidth.

OWASP Top 10 threats. The Open Web Application Security Project maintains a list of the ten most critical web application security risks. Most commercial WAFs are built to cover all of them.

Types of WAF

There are three main deployment models.

Cloud-based WAF. The WAF sits between your visitors and your server as a cloud service. Traffic passes through the WAF provider’s infrastructure before reaching your hosting. Cloudflare, Sucuri, and Imperva are examples. This is the most common model for websites because it requires no changes to your server setup. You point your DNS to the WAF provider, and it handles the filtering. Most also provide CDN and DDoS mitigation as part of the package.

Host-based WAF. Installed directly on your web server, usually as a module for Nginx or Apache. ModSecurity is the most widely used open source option. It runs on your server and inspects traffic before it reaches your application. More flexible but requires server access to configure and maintain.

Plugin-based WAF for WordPress. Plugins like Wordfence and Sucuri Security include a WAF component that runs inside WordPress. These are easier to set up than server-level options but less effective, because malicious traffic still reaches your server before being blocked. They also add processing overhead because PHP has to load before the WAF kicks in.

Cloudflare WAF

Cloudflare’s WAF is probably the one most website owners encounter. It’s included in Cloudflare’s free plan in a limited form, with more comprehensive rule sets on paid plans.

The Cloudflare WAF uses managed rule sets maintained by Cloudflare’s security team that update automatically as new threats emerge. You can also write custom rules: block traffic from specific countries, require JavaScript challenges for suspicious IP ranges, or allow specific requests that the managed rules might otherwise flag.

Because Cloudflare sits in front of your site at the DNS level, all traffic passes through it. You can enable it without touching your server. The downside is that your real server IP address must be protected. If attackers can find it and connect directly, bypassing Cloudflare, the WAF does nothing.

False positives

A WAF is a pattern matching system. It’s looking for requests that match known attack patterns. Sometimes legitimate requests match those patterns too. This is called a false positive.

For example, a WAF rule that blocks SQL keywords in query parameters might block a legitimate search for “INSERT INTO” on a database documentation site. Or a security plugin rule might block a logged in admin user performing a legitimate action that looks like a malicious request from the WAF’s perspective.

False positives are why WAFs have different operating modes. “Detection mode” logs what would be blocked without actually blocking it. “Prevention mode” actively blocks matching requests. Most security professionals recommend running in detection mode first to identify false positives before switching to prevention.

If your WAF is too aggressive, it can block your own edits to your WordPress site, payment gateway callbacks, or legitimate API requests. Getting the rule set right takes some calibration.

What a WAF can’t do

A WAF is not a complete security solution. It’s one layer of defence among several.

It can’t protect against vulnerabilities inside your application if an attacker sends valid, non-malicious looking traffic that exploits a logical flaw. It can’t protect against stolen credentials. It can’t fix a WordPress admin password that’s still “password123.” It won’t catch malware that’s already on your server.

Think of a WAF as a security guard at the door. It checks people coming in and turns away anyone who looks suspicious. It doesn’t protect against someone who already has a key, or against problems that start from inside the building.

Do you need a WAF for your website?

If you’re running a WordPress site, a WAF is worth having. WordPress is the most targeted CMS on the internet because it’s everywhere. Attackers automate scans for known plugin vulnerabilities and run them constantly. A WAF won’t make you invulnerable, but it will block the majority of automated attacks before they get near your site.

For a simple static site with no user input, a WAF matters less. There’s less attack surface.

For an e-commerce site handling payment information, or any site collecting user data, a WAF is close to non-negotiable. The liability of a breach is too high not to have one.

The practical starting point for most WordPress site owners: enable Cloudflare (free tier, at minimum), turn on the WAF, and optionally install Wordfence for a second layer at the WordPress level. That combination blocks the vast majority of automated attacks without costing anything significant.

Frequently Asked Questions

Is a WAF the same as a regular firewall? No. A standard network firewall controls traffic at the network layer based on IP addresses and ports. A WAF operates at the application layer, reading the content of HTTP requests to detect and block web-specific attacks. Most production web servers use both.

Does Cloudflare’s free plan include WAF? Cloudflare’s free plan includes some WAF protection, but the managed rule sets with comprehensive coverage require a paid plan starting at $20 per month. The free plan does include DDoS protection and basic threat intelligence.

Can a WAF slow down my site? A cloud-based WAF like Cloudflare can actually speed up your site due to its CDN functionality. A host-based WAF like ModSecurity adds a small amount of processing overhead per request. Plugin-based WAFs add the most overhead because they run inside PHP. For most sites the impact is minimal compared to the security benefit.

What is ModSecurity? ModSecurity is the most widely used open source WAF. It runs as a module for Apache, Nginx, and IIS. It uses rule sets (the most common being the OWASP Core Rule Set) to detect and block attacks. Many hosting providers pre-install ModSecurity on their servers.