What a Web Application Firewall Does for a Small Site

A web application firewall inspects each request before it reaches your site and blocks the ones that look like attacks — injection attempts, credential stuffing, probes for vulnerable plugins. This guide explains what a WAF does and does not protect on a small site, and how to enable one without blocking real visitors.

This guide focuses on the checks a small-site owner can make safely. It also points out where a host, registrar, email provider, or developer needs to take over. Read how to choose a web host if you need the broader setup, and our migration guide before changing live infrastructure.

What is a WAF and where does it sit?

A WAF is a filter in front of your web server. Some run at your host or CDN edge, others as a server module or a plugin, and the layer matters when you need to find a blocked request later. It pairs with, but is not the same as, DDoS protection, which handles floods of traffic rather than crafted requests.

Before enabling one, protect the account that controls it — DNS, billing, and server access — with a unique password and multi-factor authentication. A firewall rule cannot compensate for a stolen control-panel login.

What a web application firewall blocks — and what it doesn't

A WAF can block malicious traffic that matches known attack patterns: SQL injection, cross-site scripting attempts, and bots probing for outdated software. It cannot patch a vulnerable plugin, and it does not replace backups.

So keep backups outside the production account and practice a restore. A backup that has never been opened is a hope, not a recovery plan — and it is what saves you when an attack gets past the filter.

Test the result like a visitor

Enable new firewall rules in log-only or monitoring mode first where it is offered, and review what they would have blocked before enforcing them. When an incident happens, preserve the evidence, restrict access, and work from a known-good copy rather than making a string of unexplained changes.

Test the normal path first, then the part that has the most consequence. A rule that blocks checkout or your contact form costs more than the attacks it stops, so submit a real order or form message after enforcing anything.

When to stop and ask for help

Stop when the next action could overwrite data, change production mail, or remove access to the account. Send support the domain, time in UTC, exact error, and the changes you made. Include a screenshot when it shows the error, but do not include private keys, passwords, or full payment information.

Let's Encrypt documentation has useful background on the HTTPS layer a firewall sits alongside: Let's Encrypt documentation. Use it to understand the terms, then return to the small, reversible next step.

A sensible maintenance habit

Put the final configuration and the result in a short maintenance note. Firewall problems repeat because nobody remembers which ruleset was enabled or which rule was relaxed for a plugin last time. A dated note turns the next incident into a lookup instead of an investigation.

Keep the change auditable

Use a short before-and-after record. Write the rule you changed, its old state, the exact time you changed it, and the result of the test. If the change has a delay, such as a cache expiry at the edge, write the time you expect the new behavior to be visible. This record is useful even when everything works. A few months later, it tells you why a rule has an unusual exception.

Do not confuse an account dashboard with evidence from the live site. A dashboard can show that a ruleset is active. The visitor still needs to receive the page you intended, and the attacker still needs to be refused. Test from outside the account, and use a second connection if a cached answer could mislead you.

If you hand the task to someone else, give them the record rather than a conclusion. "The firewall broke the site" is hard to investigate. "Checkout returns a 403 since this ruleset was enforced, and the block appears in the firewall log at this time" gives the next person a useful starting point.

One last check

Before you close the ticket or move to the next task, browse the site the way a visitor would: load key pages, log in, submit the main form. If anything is refused, note the rule that fired and keep troubleshooting from that point. A quiet confirmation now is much easier than discovering blocked customers during a launch.

Leave a useful handoff

Save the final ruleset and test result with the date and account involved. If someone else needs to revisit the work, they should be able to see what is enforced without reconstructing the whole setup from browser history.

Bottom line

A web application firewall is a sensible default for a small site: it can block malicious traffic cheaply and quietly. Enable it in monitoring mode, enforce it once the log looks clean, and keep backups and updates in place for whatever gets through.

Frequently asked questions

Do I need to turn on every WAF rule at once?

No. Enable one ruleset at a time, test it, and keep the previous configuration until you know real visitors are not being blocked.

What should I send my host when the firewall blocks something it shouldn't?

Give the domain, exact URL, UTC time, the error or block message text, and steps already tried. That is usually enough for support to find the rule that fired.

Should I keep a backup even with a web application firewall?

Yes. A firewall filters traffic; it does not protect your files or database. Download or verify a recent backup before edits that affect files, databases, email, DNS, or software versions.