Trafic parasite : pourquoi votre plugin de sécurité aggrave le problème

Un site devient lent. Les journaux montrent des milliers de requêtes automatisées par heure. Le réflexe habituel : installer une extension de sécurité qui promet de bloquer les robots et de limiter le débit.

Résultat fréquent : le site ralentit davantage. Ce n’est pas un défaut de l’extension. C’est une conséquence directe de l’endroit où elle intervient.

Où se paie le coût d’une requête

Une requête vers un site dynamique traverse plusieurs étages. Elle arrive sur le serveur web, qui la transmet à l’interpréteur applicatif. Celui-ci démarre un processus, charge le socle logiciel, initialise les extensions, ouvre une connexion à la base, puis exécute le code demandé.

L’essentiel du coût — mémoire, processeur, connexion base — est consommé avant que la moindre ligne de logique métier ne s’exécute.

Une extension de sécurité est, par construction, une extension. Elle s’exécute donc pendant cette phase d’initialisation, ou juste après. Quand elle décide de bloquer une requête, le socle est déjà chargé, le processus déjà démarré, la connexion à la base déjà ouverte.

Le blocage est effectif. Le coût, lui, a déjà été payé.

Pourquoi ça empire au lieu de s’améliorer

Un serveur applicatif dispose d’un nombre limité de processus simultanés. Chaque requête en occupe un jusqu’à sa fin. Quand tous sont pris, les requêtes suivantes attendent — y compris celles de vos visiteurs légitimes.

Face à un trafic automatisé soutenu, l’extension de sécurité ne réduit pas ce nombre de processus mobilisés. Elle en ajoute même un peu : sa propre logique de détection consomme du temps de calcul, et souvent des écritures en base pour tenir ses journaux et ses compteurs.

Le site se protège correctement, mais sature exactement de la même manière. Parfois un peu plus vite.

Le blocage doit intervenir avant

La solution est architecturale, pas fonctionnelle : filtrer le trafic avant qu’il n’atteigne votre serveur.

Un pare-feu applicatif positionné en amont, au niveau du réseau de diffusion, examine la requête à son arrivée sur le point de présence — donc avant tout contact avec votre hébergement. S’il décide de la rejeter, votre serveur ne la voit jamais. Aucun processus mobilisé, aucune connexion base ouverte, aucune ressource consommée.

La différence n’est pas marginale. Elle est de nature : d’un côté une requête qui coûte le prix d’un chargement applicatif complet, de l’autre une requête qui coûte le prix d’une décision réseau.

Ce que ça donne en pratique

Sur un site que je reprenais, soumis à un balayage intensif, la charge processeur restait à saturation malgré une extension de sécurité active et correctement configurée. Le déplacement du filtrage en amont — quelques règles bien ciblées sur les motifs d’accès observés dans les journaux — a ramené la charge à un niveau normal en quelques minutes.

L’extension avait été retirée dans la foulée. Elle ne bloquait plus rien d’utile, et libérait au passage les ressources que consommait sa propre logique.

Ce qui reste utile côté applicatif

Il ne s’agit pas de tout retirer. Certaines protections n’ont de sens qu’à l’intérieur de l’application, parce qu’elles dépendent d’un contexte que le réseau ne connaît pas.

Le contrôle des droits d’accès, la validation des données soumises par les formulaires, le durcissement des permissions de fichiers, la journalisation des connexions administrateur : tout cela relève de l’applicatif et doit y rester.

La règle de partage est simple. Ce qui se décide sur la seule base de la requête se filtre en amont. Origine, fréquence, motif d’accès, signature du client. Ce qui exige de connaître l’utilisateur ou l’état de l’application se traite dans l’application.

Confondre les deux revient à faire porter à l’applicatif un travail que le réseau fait mieux, plus tôt et pour beaucoup moins cher.

Par où commencer

Regardez vos journaux d’accès avant d’installer quoi que ce soit. Identifiez les motifs : quelles adresses, quelles URL ciblées, quelle fréquence, quelle signature client. La plupart des balayages automatisés suivent des schémas très reconnaissables.

Ces motifs se traduisent en quelques règles de filtrage en amont — souvent moins de dix. C’est plus rapide à mettre en place qu’une extension, et ça agit là où le coût se paie réellement.