Web Application Firewall: Does a Small Business Need One? (October 2026)

A web application firewall is a checkpoint for web traffic: it opens each request to your website, checks what's inside against rules for known attacks, and blocks or challenges the bad ones before they reach your site's code. Picture a condo guard who opens the parcels as well as checking who's at the gate.

The firewall your office IT vendor talks about is different. A network firewall decides by address and port: who may connect, and through which door. A WAF reads the request itself, meaning the web address, cookies, form fields and any uploaded file. So it can catch things like:

• a contact form submission stuffed with database commands (SQL injection)
• 2,000 password guesses at /wp-login.php from one address in an hour
• a request shaped like a known exploit, such as the PHP2Shell patterns WAF vendors wrote rules for this week

Writing a rule for a newly disclosed flaw, so attacks get blocked while you wait for the real fix, is called virtual patching. It's why a WAF matters this week. Where the WAF runs decides what it can see:

Only a WAF that runs before PHP, meaning a cloud WAF such as Cloudflare or Sucuri or one built into the web server, can stand between PHP2Shell and your site; a WordPress firewall plugin like Wordfence is PHP code itself, so it can't be relied on against this bug.

The reason is in PHP's own advisory. It rates the risk highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." Application code means WordPress, your theme and every plugin, the firewall plugin included.

I'm not knocking Wordfence. Its firewall documentation explains that in Extended Protection mode it loads through a PHP setting called auto_prepend_file, so its rules run before WordPress starts. But that's still PHP running a script, and PHP has already read and unpacked the incoming request by the time any script runs. The flaws sit in that unpacking.

One vendor said as much about its own product. Sansec, which sells a PHP-level firewall for Magento stores called Shield, told customers the PHP2Shell code paths run inside PHP ahead of both the store's code and Shield, and not to wait for a Shield rule.

• Wordfence Free gets new firewall rules 30 days late. Its pricing page says so. Real-time rules start with Premium at US$149 a year. For a flaw being probed on day one, a month is a long wait.
• Plugins still earn their place against WordPress attacks. A plugin knows who's logged in, which plugin a request targets and which files changed overnight. Login protection, two-factor and malware scans are worth keeping. Just don't count on a plugin for flaws in PHP or the server underneath it.

My WordPress security checklist puts the security plugin where it belongs: behind a supported PHP version and regular updates.

Cloudflare says it switched on PHP2Shell rules for every customer using its WAF, Free plan included, at 3:02am UTC on 21 October 2026, about nine hours before the flaws went public, and Sucuri added virtual-patching rules across its firewall network the same day. Both told customers to update PHP anyway.

Here's what Cloudflare's post says it deployed:

• Free plan: seven new rules called "Generic Rules - Anomalous Execution" in the Free Managed Ruleset. Free customers didn't need to do anything.
• Pro, Business and Enterprise: the same seven rules in the paid Cloudflare Managed Ruleset, with a request to check the ruleset is set to block. That matters: a ruleset left on logging records the attack and lets it through.
• Every plan: a new rule that checks your server's response as well as the request, which Cloudflare calls full transaction detection. It can stop a bad response reaching the attacker, but Cloudflare says it can't undo anything already done on your server.
• Attackers adapting: Cloudflare said it watched attackers change their payloads to get past the rules, and is updating them as variations appear. Its CTO, Dane Knecht, posted that Cloudflare was "seeing early attacks emerging", as Tenable's FAQ records.

In the dashboard these rules don't mention PHP by name yet. Blocked attempts show up under Security Analytics, in Events.

Sucuri's write-up says its existing rules were already blocking some of the attack patterns and that it has added more refined rules for the known exploit paths. It's blunt about the limit: an attacker who can reach your server directly skips the firewall. Its checklist asks you to block direct IPv4 and IPv6 access, retire old DNS records and spare hostnames that point at the server, and lock down staging and backup copies. Patchstack made the same point about Cloudflare: the rules help only if your server takes traffic from Cloudflare and nothing else.

No: a web application firewall lowers the chance of a PHP2Shell attack reaching your server, but only a patched PHP build (8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor backport) removes the flaw. PHP's release notes say "There are no complete mitigations, updating is the only safe choice." Patched builds from Linux vendors such as Ubuntu or CloudLinux can show a lower version number, so go by your host's changelog rather than the number alone.

CISA puts the WAF in the same place. Its alert of 21 October offers a firewall only as interim cover, and tells anyone who can't patch straight away, or who runs PHP 8.1 or older, to take PHP systems offline until they can. Singapore's Cyber Security Agency published its own alert the same day, updated on 22 October: update immediately, starting with internet-facing systems, and treat PHP's temporary measures as reducing exposure to specific attack paths, nothing more.

Not everyone rates the danger the same way. Red Hat scores the first flaw Important (CVSS 3.1 8.1) rather than critical, and says remote code execution is hard to pull off on PHP-FPM, which standard Red Hat servers use. Sansec said on 22 October that mass exploitation looked less likely than first feared, that public exploit code failed against a default PHP install, and that stores didn't need to go offline, which runs against CISA's advice. CSA, meanwhile, reports widespread exploitation attempts. I'd patch now either way. It's a version update, and the argument is only about how bad waiting could get.

Four ways a WAF falls short here:

1. Your server's real address leaks. On shared cPanel hosting, a mail.yourcompany.sg record often points at the same server as the website, outside the WAF. Cloudflare's guidance on protecting your origin warns about exactly this, and about public DNS history that kept your server's address from before you joined. Anyone with that address can talk to PHP directly.
2. Attackers change the request. Cloudflare has already seen them try. Rules catch the shapes they know.
3. Blocking a response comes late. A response rule acts after PHP has handled the request.
4. Old PHP has no patch to wait for. PHP 8.1 and older get no update from the PHP project. A WAF in front of a PHP 7.4 site buys you time to plan the upgrade, and that's all.

So the order is: find out which PHP version actually serves your site (my guide to checking your website's PHP version takes five minutes), get it patched, then keep the WAF on for the next one.

A web application firewall for a small business website costs from US$0 on Cloudflare's free plan to about US$20 to US$25 a month for Cloudflare Pro or a Sucuri firewall plan, with business-grade plans from US$200 a month. These are list prices I checked on each vendor's site on 23 October 2026, charged in US dollars.

One catch with Cloudflare Free and Pro: your domain's nameservers move to Cloudflare. For a .sg or .com.sg domain that's a change at your registrar (Vodien, Exabytes, GoDaddy or wherever you bought it), and Cloudflare then answers all your DNS, email records included. Keeping your existing DNS provider needs Business. Sucuri makes more sense if you'd also like malware clean-ups for a fixed yearly fee.

Your small business needs a web application firewall if your website runs on PHP (WordPress, WooCommerce, Joomla, Drupal, Magento, Laravel), and it gets the most from a paid one if it takes payments, has customer logins or sits on a server you manage. Hosted builders and static sites mostly don't need one.

On shared hosting, the host matters more than the WAF. SiteGround says it rolled out server-level mitigations before PHP2Shell was public and patched every server on 21 October, so its customers had nothing to do. Other hosts may have done the same. Check, don't assume.

A web application firewall is wasted money when there's nothing behind it to protect, or when it's bought instead of fixing the thing it's guarding. These are the five I'd watch for:

1. Paying for a WAF on Wix, Shopify or a static site. There's no PHP or database of yours on the server for it to guard.
2. Paying for Cloudflare Pro while the server takes direct traffic. If mail.yourcompany.sg points at the web server and the server answers anyone, the paid rules only cover the polite attackers.
3. Paid rules left on log. Cloudflare had to remind paid customers to check their Managed Ruleset is set to block. Logging an attack doesn't stop it.
4. A WAF instead of an upgrade. A site pinned to PHP 7.4 because "one plugin breaks on PHP 8" will never get a PHP2Shell fix from the PHP project. The money goes further on the upgrade.
5. Stacking. Sucuri in front of Cloudflare in front of Wordfence Premium, on a five-page brochure site. One cloud WAF and one plugin is plenty.

Setting up Cloudflare's free WAF on a WordPress site takes about an hour: add the domain to Cloudflare, check the DNS records it copies across, switch your nameservers at the registrar, set encryption to Full (strict), then test every form. Do it on a quiet weekday morning, not the night before a sale.

1. Screenshot your current DNS records at your registrar or host. If anything goes wrong, this is how you put it back.
2. Create a Cloudflare account, turn on two-factor login, and add your domain on the Free plan. Cloudflare scans your existing records and copies them in.
3. Check every record. The website records (yourcompany.sg and www) should be proxied, shown as an orange cloud. Mail records stay DNS only. If your mail record points at the same IP address as your website, that's the leak from earlier: ask whether email can move to Google Workspace, Microsoft 365 or a separate server.
4. Change the nameservers at your registrar to the two Cloudflare gives you. Cloudflare emails you when the domain is active, usually within a few hours.
5. Set SSL/TLS to Full (strict) once your host's certificate is valid. Flexible sends traffic to your server unencrypted and often causes redirect loops on WordPress.
6. Open the WAF settings under Security and confirm the managed rules are on. On Free there's nothing to switch for PHP2Shell. Add one custom rule that challenges visitors to /wp-login.php and /xmlrpc.php from outside the countries you serve.
7. Test the site end to end: send yourself an enquiry, place a test order, log in to wp-admin, save a page. If a rule blocks something real, the Events log shows which one, and you can skip that rule for that one path.
8. Ask your host whether the server can accept web traffic only from Cloudflare's IP ranges. On a VPS it can. On shared hosting it usually can't, which is why the host's PHP patch still matters most.

If you'd rather hand it over, this is work I do for clients, and it starts with a free PHP check. Send me your web address and I'll check which PHP version it runs, what it's built on and how old its theme and plugins are, and tell you what I find. If your host has already patched it, I'll say so, and you won't need me.

If it does need the update, you get a fixed price in writing before I start, covering the PHP update and anything it breaks, from SGD 850. Cloudflare set-up can go into the same quote. If the site is old enough that a rebuild might make more sense, I'll quote that alongside so you can compare (prices are in the next section). To keep it patched afterwards, my content retainer is SGD 550 a month, month to month, and covers updates, backups and security plus five hours of changes. Details are on my website maintenance page. If you're already seeing strange admin users or spam pages in Google, read what to do when a WordPress site is hacked first, because a firewall can't undo what's already happened.

A static website usually doesn't need a separate web application firewall, because there's no PHP, database or public admin login on its server for attackers to reach; the host's built-in protection covers the basics. The risk moves to your accounts instead.

My own site is the example. terris.sg is about 1,900 pages built ahead of time with Astro and served from Vercel, and I don't pay for a WAF. Vercel has DDoS mitigation on by default and lets you add custom firewall rules (3 on the free plan, 40 on Pro). PHP2Shell had nothing to aim at. What I guard closely is the domain registrar, the Vercel and GitHub logins and the small functions behind the contact forms. My post on static vs dynamic websites covers that list.

That's the second option, and it suits sites that are mostly pages about the business. MET Interior moved 176 pages off WordPress onto a statically rendered Astro site this way. My website packages run from Starter at SGD 2,535 for up to 10 pages, through the One Week Website at SGD 3,545, to Growth from SGD 7,585 with a CMS you edit yourself. If you run WooCommerce with live stock, a membership area or a booking system with real logic, a well-kept WordPress with a cloud WAF in front is often the better answer, and patching is the right call.

Yes, Cloudflare's free plan includes a real web application firewall: the Free Managed Ruleset, five custom rules and one rate-limiting rule, and it's the ruleset that received the PHP2Shell rules on 21 October 2026. What it doesn't have is the larger Cloudflare Managed Ruleset and the OWASP Core Ruleset, which start on Pro.

For a brochure site that's enough. A shop, or a site with customer logins, gets more from Pro's broader rules, as long as someone sets them to block and checks the Events log now and then.

Yes, a web application firewall can block real visitors, or your own admin work, when a rule mistakes a normal request for an attack, which is called a false positive. The usual victims are contact forms, checkout pages, page-builder saves and file uploads, so test all four on the day you switch it on.

When it happens, don't turn the whole WAF off. Find the blocked request in the Events log, note the rule, and skip that rule for that one page or path. On Cloudflare Free that uses one of your five custom rules.

Keep Wordfence or a similar security plugin alongside Cloudflare if your WordPress site has logins, because the plugin handles what a cloud WAF can't see well: password guessing, two-factor, changed files and malware scans. Just don't rely on it for flaws in PHP itself, like PHP2Shell.

One security plugin is enough. Two usually means two sets of rules tripping over the same requests, and twice the alerts nobody reads.

Once PHP is updated, the web application firewall is no longer what stands between PHP2Shell and your site, but it's still worth keeping, because the next flaw will be public before your host or developer has patched it. PHP has put out security releases five times in 2026 so far.

PHP's release archive lists them: 7 May, 2 July, 30 July, 24 September and 21 October. A free WAF covers the gap between a flaw going public and your server being patched.