What a Web Application Firewall Actually Does for Your Website

The word firewall is doing a lot of work in modern computing, and it means different things in different places. A web application firewall is not the firewall in your office router, and it is not the one built into your laptop.

Those operate at network level, deciding which connections are allowed at all. A web application firewall works a layer higher — it lets the connection through and then inspects what is actually being asked for.

The distinction that matters

A network firewall can tell you that a request arrived on port 443 from a particular address. That is all it knows.

A web application firewall reads the request itself. It sees which URL is being requested, what is in the form fields, what the headers say, and whether any of it resembles a known attack.

A network firewall asks "is this connection allowed?". A web application firewall asks "is this request trying to do something it should not?"

That difference is why it can block a SQL injection attempt while allowing perfectly normal traffic from the same visitor.

What it blocks

• Injection attempts — requests carrying patterns typical of SQL injection
• Cross-site scripting — script tags and encoded payloads in fields expecting plain text
• Known exploit attempts against specific disclosed plugin vulnerabilities
• Brute force and credential stuffing by rate-limiting login attempts
• Bad bots and scrapers, including vulnerability scanners probing your site
• File inclusion and traversal attempts trying to reach files outside the web root
• Volumetric attacks, if the firewall sits at network edge

Why the timing matters most

This is the argument for having one, and it is more specific than "extra protection".

When a plugin vulnerability is disclosed, the details become public. Automated scanning for it typically begins within days. Meanwhile, most sites take weeks or months to apply the patch.

That gap is where most compromises happen. A firewall with an updated rule set can block exploit attempts against the disclosed vulnerability before you have patched it.

It does not fix the vulnerability. It buys you the time to fix it, which is exactly what you need at the moment you are most exposed.

This is called virtual patching, and it is the single most valuable thing a web application firewall does for a WordPress site.

Where it sits

Cloud-based — before traffic reaches your server

Your DNS points at the provider, they filter, and clean traffic is forwarded on. Cloudflare and Sucuri work this way.

Advantages: malicious traffic never touches your hosting, so it consumes none of your resources. This is the only type that meaningfully absorbs a volumetric attack, and it usually includes a CDN.

Trade-offs: a third party sees your traffic, and DNS changes are required. Misconfiguration can cause problems — a common one being redirect loops from an incorrect SSL mode, covered in our guide to WordPress redirect loops.

Server-level

Running on your host's web server, before PHP executes. Efficient, and often already included on decent managed hosting — worth asking whether yours has it.

Plugin-based

Runs as PHP inside WordPress. Easiest to install and the weakest of the three, because the request has already reached your server and started WordPress before being evaluated.

It still blocks the attack. It just costs you resources to do so, and it can be disabled by an attacker who gains sufficient access.

What it cannot do

Worth being clear, because firewalls get oversold.

It does not clean an infected site. If malware is already present, a firewall does not remove it. Clean first, then protect.

It does not stop a stolen password being used. A valid login from a valid credential looks legitimate. That is what two-factor authentication is for.

It does not catch everything. Novel attacks and cleverly obfuscated payloads get through. Rules match known patterns.

It does not replace updating. Virtual patching is a stopgap measured in days, not a permanent substitute for applying the fix.

It does not protect against you. A nulled plugin you installed yourself carries its backdoor straight past the firewall.

The false positive problem

The genuine downside. Firewall rules occasionally block legitimate requests, and the symptoms are confusing — a contact form that fails for certain messages, a page builder that cannot save, an admin action returning a 403.

The pattern to recognise: something works for you and not for a colleague, or works with simple content and fails with anything containing code or unusual characters.

Most providers offer a learning mode and per-rule exceptions. Budget a little tuning time after deployment rather than assuming it is finished on install.

Is it worth it?

For a low-stakes brochure site with prompt updates and two-factor enabled, it is a reasonable thing to skip. Our honest look at security spending covers that.

It becomes clearly worthwhile when you take payments or hold customer data, when updates cannot always be applied within days, when the site runs many plugins, or when you have been compromised before.

That second point is the practical one. Most businesses cannot patch within 48 hours every time, and a firewall covers the gap between intention and reality.

Where it fits

Think of it as one layer rather than a solution. Prompt patching closes vulnerabilities. Two-factor protects logins. A firewall covers the gaps in both. Monitoring catches what gets through.

Our hardening checklist puts these in priority order — the firewall sits solidly in the second tier, valuable but after updates and two-factor.

If you would rather not configure one

Deployment and tuning are where most of the effort sits. A firewall installed and never tuned either blocks legitimate traffic or gets switched off after the first complaint.

Our security monitoring service includes a managed firewall — configured, tuned, kept current with new vulnerability rules, and with a person handling false positives rather than leaving you to.

Get in touch and we will tell you whether you already have one through your host, and whether it is doing anything useful.