# My host says their firewall is enough: is that true

> An application firewall blocks a share of attacks, and that share is measurable. Knowing what it catches — and above all what it lets through — stops you building your whole security posture on a tick-box in a hosting panel.

- Source canonique : [https://allaux.fr/en/securite/le-pare-feu-de-mon-hebergeur-suffit-il](https://allaux.fr/en/securite/le-pare-feu-de-mon-hebergeur-suffit-il)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Ask your host exactly what the protection covers: application rules, rate limiting, reputation-based blocking, and how often the rules are refreshed. Keep in mind what no filter sees: an exploit shaped like an ordinary POST request to the site root looks like normal use. A firewall complements updating, it never replaces it.

## 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.

| Valeur | Description |
|---|---|
| under 26% | of attacks blocked by hosting providers’ protections |
| 11,334 | new vulnerabilities recorded across the WordPress ecosystem in 2025 |
| 5 hours | median time to mass exploitation of a disclosed flaw |

Source : Patchstack, State of WordPress Security in 2026 (2025 figures)

## 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.

## Questions to put to your host

1. **Is it an application firewall or network protection?** — Network protection filters volume and flooding attacks. An application firewall reads the content of HTTP requests. Both are useful and they solve different problems; one is often presented in place of the other. Ask for the product name, not the words "site protected".
2. **How often are the rules updated?** — Signature-based filtering is worth exactly as much as the freshness of its rules. Ask who publishes them, and how quickly after a flaw is disclosed. A rule set frozen long ago protects against last year’s attacks.
3. **Do I get access to the block logs?** — Without logs you will never know whether the firewall blocked three requests or three hundred thousand, nor what it blocked. A filter whose output you cannot see gives you nothing usable — neither reassurance nor evidence after an incident.
4. **Who steps in when a rule breaks an integration?** — An over-strict filter can block a payment gateway callback, a carrier webhook or a marketplace feed. Ask who diagnoses it, who adjusts it, and how fast. This is the question that separates a service from a tick-box.
5. **What happens when a flaw hits a component I use?** — Does anyone push a specific rule, and how quickly? Am I told? The answer decides whether you are covered during the window before the patch, or whether you find out from your error logs.

## The order matters: update, reduce the surface, then filter

> Updating removes the flaw. Reducing the surface removes the component that might have one: an uninstalled module needs no filtering. Filtering only delays exploitation of whatever is left. A firewall bolted onto a shop whose modules go untracked fixes nothing; it moves the date of the problem. The other way round, a shop that is up to date and stripped of unused components gains real value from filtering: it covers precisely the period when nothing else can be done. The firewall is neither useless nor sufficient — it comes third.

## Related reading

- **Abandoned modules and extensions** — Reduce the surface before filtering: the component nobody updates remains the most common way in. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Tracking flaws that affect your store** — How to get warned during the window when filtering is your only protection. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Choosing e-commerce hosting** — What to check in an offer beyond the words "site protected". ([/guides/choisir-hebergement-ecommerce](/guides/choisir-hebergement-ecommerce))
- **Checking whether your site is compromised** — The checks to run when you want to know if something already got through. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))

## FAQ

### My host’s panel says "site protected". Is that enough?

No, and it has been measured: fewer than 26% of attacks are blocked by hosting providers’ protections, according to the Patchstack report covering 2025. The label says nothing about the type of protection, nor whether the rules are current. Ask for the product name and access to the block logs.

### Do I need an application firewall on top of my host’s?

It depends on what yours already does. If you have no logs, no updated rules and nobody to call when a flaw drops, then yes — specialist filtering adds coverage you do not have. If you have all three, a second layer ranks below keeping your modules updated.

### Can a firewall break my site?

Yes, it happens. An over-strict rule can block a payment gateway callback, a webhook or a feed import. That is why "who adjusts the rules, and how fast" matters as much as "do you have one".

### Does a firewall help if my site is already infected?

No. A filter reads inbound requests; it knows nothing about the state of your files or your database. Malicious code already installed runs server-side without passing through the filter again. A compromise is dealt with by cleaning and patching, not by filtering.

### How do I know whether the firewall has done anything on my shop?

Through the block logs, and only through those. You need to see how many requests were refused, of what kind, and when. Without that access there is no way to tell an active filter from an inactive one.