Firewall and DDoS Protection for Small Business Websites

Every public website gets attacked, just usually not by a person

It's easy to assume a small local business website isn't a target — why would anyone bother attacking a five-page site for a plumbing company? In practice, the vast majority of attacks against small business sites aren't targeted at the business at all. They're automated bots scanning the entire internet for known vulnerabilities in common software (outdated WordPress plugins, exposed admin panels, weak login credentials), and they hit every publicly reachable site eventually, regardless of size or perceived importance.

This changes what "enough" security looks like. You don't need enterprise-grade protection built for a target actively under attack from a determined adversary. You need protection against the automated, opportunistic scanning that hits everything indiscriminately — and a relatively small set of tools covers that well.

What a web application firewall actually does

A web application firewall (WAF) sits between incoming traffic and your website, inspecting requests before they reach your server and blocking ones that match known attack patterns — SQL injection attempts, cross-site scripting payloads, known malicious IP ranges, and suspicious request patterns like a single source hitting your login page hundreds of times in a minute.

For most small business sites, a WAF doesn't need to be custom-built. Cloudflare offers a WAF as part of its free and low-cost plans, and it's genuinely effective against the common automated attack patterns that make up most of what hits a small site. If you're on WordPress, plugins like Wordfence add WAF-style protection at the application level as well, layering with a network-level WAF like Cloudflare for defense at two different points.

Rate limiting stops brute-force attempts cold

A large share of automated attacks against small sites are brute-force login attempts — bots trying common username and password combinations against your admin login or any exposed authentication endpoint. Rate limiting caps how many requests a single source can make in a given time window, which makes brute-forcing impractical without needing to identify or block the attacker individually.

Setting rate limits on login pages specifically (rather than the whole site) is usually the highest-value place to start, since login endpoints are disproportionately targeted compared to the rest of a typical site. Most WAF services and several WordPress security plugins support this without custom configuration.

DDoS protection: what it protects against and what it doesn't

A Distributed Denial of Service (DDoS) attack floods a server with traffic from many sources simultaneously, aiming to overwhelm it so it can't respond to legitimate visitors. For most small business sites, large-scale targeted DDoS attacks are rare — they require an attacker with a specific motive and real resources. What's more common is a smaller-scale traffic flood from a botnet doing indiscriminate scanning, which can still knock over an unprotected small server even without deliberate targeting.

Services like Cloudflare and other content delivery network (CDN) providers absorb this kind of traffic before it reaches your origin server, because they sit in front of your site across a globally distributed network built to handle traffic spikes. This is usually included in the same free or low-cost tier as the WAF, which makes it one of the higher-value, lower-effort security additions available to a small business site.

What this setup does not cover

Firewall and DDoS protection reduce the odds of a successful automated attack; they don't eliminate all risk, and they don't replace other basics. Keeping software (CMS core, plugins, themes, server operating system) updated closes the specific vulnerabilities that attacks are trying to exploit in the first place — a firewall can only block known-bad patterns, not every possible flaw in outdated software. Strong, unique admin credentials and two-factor authentication on your login remain necessary even with a WAF in place, since credential stuffing (trying leaked username/password pairs from other breaches) doesn't always match obvious attack patterns a WAF would catch.

And as covered in our guide on backup strategy, no amount of firewall protection replaces having a tested recovery plan. Security reduces the odds of an incident; backups are what get you back online if one happens anyway.

Setting realistic expectations

For a typical small or mid-size business website, a reasonable security setup is: a CDN-based WAF like Cloudflare in front of the site, rate limiting on login and form endpoints, current software versions across the stack, strong unique credentials with two-factor authentication where supported, and tested backups. This isn't an exhaustive enterprise security program — it's the set of measures that address the actual, common threat small business sites face, which is automated opportunistic attack, not a determined targeted adversary.

FAQ

Do small business websites actually get attacked?

Yes, routinely, but almost always by automated bots scanning for common vulnerabilities rather than a person specifically targeting the business. This makes basic protection against automated patterns effective even for a very small site.

Is a free web application firewall good enough?

For most small business sites, yes. Services like Cloudflare's free WAF tier block the common attack patterns — SQL injection attempts, known malicious IPs, brute-force login attempts — that make up the majority of what hits a typical small site.

What's the difference between a firewall and DDoS protection?

A web application firewall inspects and blocks individual malicious requests based on known attack patterns. DDoS protection absorbs large volumes of traffic aimed at overwhelming the server, typically by routing traffic through a distributed network before it reaches your origin server.

Does a firewall mean I don't need to update my software?

No. A firewall blocks known attack patterns but can't protect against every vulnerability in outdated software. Keeping your CMS, plugins, and server software current closes the underlying weaknesses that attacks are trying to exploit.

Is rate limiting only useful for login pages?

Login pages are the highest-value place to start since they're disproportionately targeted, but rate limiting is also useful on contact forms and any other public endpoint that could be abused by automated submissions.