Web Application Firewalls (WAF) Explained for Website Owners

A web application firewall, or WAF, sits between visitors and your website and inspects HTTP requests. It looks for patterns that indicate an attack, such as attempts to inject database commands or upload malicious files, and blocks or challenges them before they reach your application. It is different from a network firewall, which filters traffic by IP address and port and does not understand web requests.

What a WAF protects against

The threats a WAF is designed for are mostly the common application-level attacks that appear in the OWASP Top 10 list of web security risks:

• SQL injection: requests that try to run database commands through form fields or URLs.
• Cross-site scripting (XSS): attempts to inject script into pages that other users will view.
• Path traversal and file inclusion: requests trying to read or run files they should not reach.
• Known exploit attempts for popular software, including vulnerable plugins.
• Abusive bots, scanners and credential-stuffing tools hitting your login pages.
• Request floods to expensive endpoints, when rate limiting is part of the WAF.

How a WAF decides

There are three common approaches, and most products combine them.

1. Signature rules: the WAF matches requests against a database of known attack patterns. This is the foundation of rule sets such as the OWASP Core Rule Set.
2. Reputation and behaviour: requests from known malicious IP addresses or clients behaving like bots are challenged or blocked.
3. Positive security: only requests matching a defined, expected format are allowed. It is strict and accurate but needs careful setup, so it is rare on small sites.

Types of WAF

Type	How it works	Consider
Cloud / CDN-based	Traffic passes through the provider's network first	Easy setup, also absorbs floods; depends on provider and plan
Server-based (such as ModSecurity)	Runs inside the web server	Full control and no extra hop; needs tuning and server access
Plugin-based (for example for WordPress)	Runs inside the application	Simple to install, but requests reach your PHP before being filtered

The earlier in the chain a request is blocked, the less load it puts on your server, so network- or server-level WAFs generally have an advantage over plugins that run inside the application.

Limits to understand

• It is not a substitute for updates. A WAF can reduce exposure to known exploits, but virtual patching is not complete. Keep software current.
• False positives happen. Rules can block legitimate requests, such as a form containing certain characters or an editor saving HTML content.
• It cannot fix logic flaws. A WAF does not understand your business rules, such as an order endpoint that lets users change prices.
• Determined attackers can sometimes evade rules, especially with unusual encodings.

Think of a WAF as one layer in a set of defences, alongside updates, strong authentication, backups and least privilege.

Setting one up sensibly

1. Start in monitor or log-only mode, if available, and review what would be blocked before enforcing.
2. Turn on the managed rule set for your platform, such as WordPress, and enable rate limiting for the login page.
3. Test critical journeys: contact form, checkout, login, search, admin editing and any API or webhook.
4. Add exceptions narrowly. If a rule blocks a legitimate action, exempt that rule for that URL, not the whole WAF.
5. Review logs regularly. Rule hits show you what attackers are trying and which of your pages get most attention.
6. Allow your own services, such as payment webhooks and monitoring tools, so they are not blocked.

Choosing

For most small business websites, a WAF included with a CDN is the simplest and most cost-effective route, with a plugin as an extra layer on WordPress if you want application-aware rules and login protections. If you run your own VPS, ModSecurity with a maintained rule set is a common option, though it takes time to tune. Be wary of marketing that promises to "stop all hackers"; no product does.

A word on virtual patching

Vendors often advertise "virtual patching": a rule that blocks attempts to exploit a newly discovered vulnerability before you have installed the software update. It is a genuinely useful stopgap, especially in the hours after a flaw is published, when attackers begin scanning widely. But it relies on the vendor writing a rule that matches the exploit, and variations can slip past. Treat it as buying time to update, never as a reason to postpone updates indefinitely.

Questions to ask before you pick a WAF

• Does it support logging and let you see exactly why a request was blocked?
• Can you exempt a single rule for a single URL, without disabling everything?
• Does it include rate limiting and bot management, or are those extra?
• Where does the inspection happen, and what happens to HTTPS traffic?
• Who updates the rules, and how quickly after a new vulnerability appears?
• What is the plan if the WAF itself has an outage?

Answers to these matter more than the length of a feature list. A simple WAF you understand and monitor beats a complicated one nobody reviews.

Layered protection on your hosting

Zebra Hosting Cloud offers Cloudflare CDN on hosted sites, which places a filtering layer in front of your origin. For a broader view of how the platform approaches protection, visit the security page.