What a Web Application Firewall Does

What it actually does

It sits between the visitor and your site, examining each request. Requests matching known malicious patterns are blocked before your site processes them.

The distinction from a conventional firewall matters. A network firewall decides which connections are permitted at all. A web application firewall looks at the content of web requests specifically, at the level of what is being asked for.

That lets it catch things a network firewall cannot: an attempt to inject a database command through a form field, a request for a known vulnerable file, or a login attempt pattern that indicates automated guessing.

What it catches

• Automated vulnerability scanning, which every site receives continuously and which forms the bulk of what a firewall blocks.
• Injection attempts aimed at forms and query strings.
• Requests for known vulnerable paths, including files from plugins you may not even have.
• Brute force login attempts, by rate limiting or blocking after repeated failures.
• Known malicious sources, from reputation lists maintained by the provider.
• Volume floods, where the service includes that protection.

The most valuable of these for a small business is the first. Automated scanning is the mechanism behind most small site compromises, since it finds the site with the outdated plugin rather than targeting it deliberately.

What it does not catch

Being clear about this prevents the false confidence that is the main risk of installing one.

It does not help against a weak or reused password on an account with valid access. It does not help if someone is phished and their credentials are used legitimately. It does not fix outdated software; it only makes the vulnerability harder to reach.

It also does not stop a compromise that arrives through a route it does not inspect, such as a hosting account login or an infected file uploaded through legitimate access.

So it is one layer. A site with a firewall and an unmaintained content system, an administrator password reused from another site, and no two-factor authentication is still exposed, and the firewall may make that feel less urgent than it is.

The forms it comes in

The differences matter. Network based stops traffic before it consumes any of your server resources, which is why it also mitigates volume attacks. Plugin based has already used your resources by the time it decides, which limits what it can protect against.

For a small business, a network-based service is frequently already available bundled with a content delivery network, which means the firewall may be a setting to enable rather than a product to buy.

The false positive problem

The practical cost, and the one that causes support calls.

Rules that block malicious patterns sometimes block legitimate ones. The common symptoms are a form submission rejected because the message contained something resembling code, an administrator unable to save a page, or a file upload refused.

These are frustrating because the failure is silent from the visitor's perspective. An enquiry that was blocked simply never arrives, and nobody knows.

Two protections: start in a monitoring mode where the firewall logs what it would have blocked without blocking it, and check the blocked log periodically for anything that looks like a real customer.

That second habit is worth building, because a firewall quietly rejecting enquiries is worse than not having one.

Whether a small site needs one

It depends more on what the site runs than on its size.

A hand-built static site with no database, no login, and no forms has very little for a firewall to protect. The attack surface is close to nothing.

A site running a content management system with plugins, a login, and forms is the standard target for automated scanning, and a firewall is genuinely useful there. That covers most small business sites.

The honest ordering is that updates, strong unique passwords, and two-factor authentication matter more, and a firewall is a worthwhile addition once those are in place rather than a substitute for them.

What to check before enabling one

• Whether your host already provides it, since many do and it is unused.
• Whether it runs before or after your server, which determines what it can protect against.
• Whether there is a monitoring mode to run first.
• Where the blocked log is and how to read it.
• What happens if the service is unavailable, for a network-based option where all traffic routes through it.
• Whether it interferes with your forms, tested deliberately after enabling.

That last test is the one to do the same day. Submit your own form with a long message containing punctuation and confirm it arrives, since the alternative is finding out weeks later that enquiries stopped, which is the same silent-failure category as anything else that breaks without an error, as covered in the day after a site is compromised.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.