My host says their firewall is enough: is that true

What an application firewall actually does

An application firewall sits between the visitor and your shop and reads requests before they reach your code. It works on three fronts. It recognises known, catalogued attack patterns and refuses requests that resemble them. It rate-limits, capping how many requests one source can send in a given window. And it blocks whole sources, by address or reputation, when they behave like automated tooling rather than customers.

That is not nothing, and the volumes show it. On a critical flaw in a WordPress forms extension patched in March 2026, Wordfence blocked more than 29,300 exploitation attempts. On a flaw in an email connector installed on roughly 100,000 sites, the total exceeds 17 million attempts, peaking at over 4 million blocked requests in a single day on 6 and 7 June 2026. On an authentication bypass in a statistics extension, more than 7,400 attacks were blocked in 24 hours. When this filtering works, it absorbs a great deal of noise and, sometimes, a compromise.

Nor is it a fringe position. After the wave of SQL injection attacks aimed at third-party PrestaShop modules, the recommendations published by the project explicitly list deploying an application firewall — alongside updating every native and third-party module, using a custom database prefix, and keeping regular backups. The firewall appears as one item on a list, not as the list.

What it cannot do

A firewall recognises shapes. When exploiting a flaw looks exactly like normal use of the site, there is no shape left to recognise. This is the key point of the page, and it is documented: on a pop-up module for PrestaShop, the advisory notes that attempts appear in site logs as ordinary POST / requests, and are therefore very hard to tell apart without dedicated tooling. That same advisory recommends firewall rules — but in addition to updating the module, never instead of it.

Three further situations escape it by design:

• An extension already tampered with. When malicious code arrives through the publisher’s own distribution channel and runs server-side, there is no suspicious inbound request to filter.
• A leak through a legitimate but poorly protected endpoint. A log directory left publicly readable, or an API endpoint that answers without checking permissions, responds to a perfectly well-formed request. Nothing to block, as far as the filter is concerned.
• Access obtained with valid credentials. A firewall cannot tell a legitimate administrator from an attacker using that administrator’s password.

Across the ecosystem this is quantified. The Patchstack report covering 2025 states that fewer than 26% of attacks are blocked by hosting providers’ protections. That is a real share; it is not coverage.

Where it genuinely decides the outcome: the window before the patch

There is one situation where filtering really does change the result: between a flaw becoming public and the moment you can apply the fix. That window is not theoretical. The same report puts the median time to mass exploitation at 5 hours, with roughly half of high-impact vulnerabilities exploited within 24 hours of disclosure. No shop updates in five hours: you back up, apply, test, and check the checkout still works.

This is where a stopgap makes sense. For the emergency WordPress update released on 17 July 2026, Tenable listed among interim measures blocking the affected batch REST API endpoint at the application firewall, and monitoring attempts against it. The important word is interim: you block a door while the lock is fitted; you do not call the door repaired. WordPress.org went further and enabled forced automatic updates on the affected versions, which says plainly enough what actually solves the problem.

A firewall buys you time, and that time is worth something when you cannot update immediately — because the fix breaks a module, because maintenance is scheduled, or because no fix exists yet. It buys you nothing at all if you never intend to update afterwards.