WAF or security plugin: what actually separates them

The question comes up at every setup: “I already have a security module on my site — do I need anything else?” The answer is not a feature list. It comes down to where the filtering runs.

The difference in one sentence

Everything else follows. For a plugin to inspect a request, your server must accept it, open a connection, start the interpreter, load the CMS core, then load the plugin. Filtering happens at the end of that chain. A firewall placed upstream refuses the request before the first of those steps.

Four concrete consequences

A plugin does not protect against load

Ten thousand hostile requests per minute cost your hosting ten thousand interpreter starts, whether the plugin blocks them or not. That is why a site “protected” by a plugin still goes down under an aggressive scan: the refusal does happen, but it has already been paid for.

A plugin depends on the software it protects

A flaw in the CMS core, or in another plugin loaded earlier, is exploited before the security module gets control. Filtering and target share one process: whatever compromises one compromises the other.

A plugin only covers one technology

No single module covers a Laravel API, a PrestaShop store and a Next.js front end at once. A proxy, on the other hand, is indifferent to whatever runs behind it: it sees HTTP requests, and that is all it needs.

In exchange, a plugin sees what a proxy never will

A plugin reads your files, your users and your database. It spots a modified file, an admin account created overnight, a theme whose signature no longer matches. A proxy has access to none of that: it only sees traffic. These are two different controls, not two versions of one.

What each one covers

When Zyre is not the right choice

Four situations where an upstream firewall is not what you need. They are here because they are true, and because a comparison that never concludes against itself is worth nothing.

• You cannot change your DNS. The whole protection rests on one record pointing at us. Without access to the zone — or the agreement of whoever administers it — there is nothing to set up.
• Your problem is file integrity. If your question is “has someone modified a file on my server?”, you need a tool that reads the disk. We do not read it, and no setting will change that.
• Your site is not publicly exposed. A service reachable only from an internal network does not need a filter placed on the public internet.
• You are looking for volumetric DDoS protection. We filter at the application layer. If your network link is saturated, packets are lost at the carrier and no application filter runs at all — that is a different category of product, and we do not claim to replace it.

Should you keep both?

Yes — and this is not a sales answer: the two controls only partly overlap. The firewall absorbs hostile traffic before your server, the plugin watches what happens inside. What you should switch off after the cutover is the plugin’s firewall module: otherwise two rule engines inspect the same request, and a false positive becomes impossible to attribute.