WAF ou plugin de sécurité : ce qui les sépare vraiment

La question revient à chaque installation : « j'ai déjà un module de sécurité sur mon site, est-ce que j'ai besoin d'autre chose ? » La réponse ne tient pas à une liste de fonctionnalités, mais à l'endroit où le filtrage s'exécute.

La différence en une phrase

Tout le reste en découle. Pour qu'un plugin inspecte une requête, il faut que votre serveur l'accepte, ouvre une connexion, démarre l'interpréteur, charge le cœur du CMS, puis charge le plugin. Le filtrage arrive au bout de cette chaîne. Un pare-feu placé en amont refuse la requête avant le premier de ces gestes.

Quatre conséquences concrètes

Un plugin ne protège pas de la charge

Dix mille requêtes hostiles par minute coûtent dix mille démarrages d'interpréteur à votre hébergement, que le plugin les bloque ou non. C'est la raison pour laquelle un site « protégé » par un plugin tombe quand même sous un scan agressif : le refus a bien lieu, mais il a déjà été payé.

Un plugin dépend du logiciel qu’il protège

Une faille dans le cœur du CMS, ou dans un autre plugin chargé plus tôt, s'exploite avant que le module de sécurité n'ait la main. Le filtrage et la cible partagent le même processus : ce qui compromet l'un compromet l'autre.

Un plugin ne couvre qu’une technologie

Il n'existe aucun module unique couvrant à la fois une API Laravel, une boutique PrestaShop et un front Next.js. Un proxy, lui, est indifférent au logiciel qui tourne derrière : il voit des requêtes HTTP, et c'est tout ce dont il a besoin.

En échange, un plugin voit ce qu’un proxy ne verra jamais

Un plugin lit vos fichiers, vos utilisateurs et votre base de données. Il repère un fichier modifié, un compte administrateur créé pendant la nuit, un thème dont la signature ne correspond plus. Un proxy n'a accès à rien de tout cela : il ne voit que du trafic. Ce sont deux mesures différentes, pas deux versions de la même.

Ce que chacun couvre

Quand Zyre n’est pas le bon choix

Quatre situations où un pare-feu en amont n'est pas ce dont vous avez besoin. Elles sont ici parce qu'elles sont vraies, et parce qu'une comparaison qui ne conclut jamais contre soi-même ne vaut rien.

• Vous ne pouvez pas modifier votre DNS. Toute la protection repose sur un enregistrement qui pointe vers nous. Sans accès à la zone — ou sans l'accord de celui qui l'administre — il n'y a rien à mettre en place.
• Votre problème est l'intégrité des fichiers. Si votre question est « quelqu'un a-t-il modifié un fichier de mon serveur ? », il vous faut un outil qui lise le disque. Nous ne le lisons pas, et aucun réglage ne changera cela.
• Votre site n'est pas exposé publiquement. Un service joignable uniquement depuis un réseau interne n'a pas besoin d'un filtre placé sur l'internet public.
• Vous cherchez une protection DDoS volumétrique. Nous filtrons au niveau applicatif. Si votre lien réseau est saturé, les paquets sont perdus chez l'opérateur et aucun filtre applicatif ne s'exécute — c'est une autre catégorie de produit, et nous ne prétendons pas la remplacer.

Faut-il garder les deux ?

Oui, et ce n'est pas une réponse de commercial : les deux mesures ne se recouvrent qu'en partie. Le pare-feu absorbe le trafic hostile avant votre serveur, le plugin surveille ce qui se passe à l'intérieur. Ce qu'il faut désactiver après la bascule, en revanche, c'est le module de pare-feu du plugin : sinon deux moteurs de règles inspectent la même requête, et un faux positif devient impossible à attribuer.