Table des matières de l'article :
Au cours des douze derniers mois, en tant que société d'hébergement Linux et d'ingénierie de systèmes spécialisée dans les performances web des principaux CMS, nous avons constaté un phénomène de plus en plus évident : le trafic automatisé vers les sites web a augmenté de manière significative, souvent soudainement, et dans certains cas avec des impacts très graves sur les infrastructures des clients.
Ce ne sont plus seulement les robots classiques des moteurs de recherche, les robots d'exploration SEO ou les scanners automatisés qui parcourent Internet à la recherche de vulnérabilités connues depuis des années. Aujourd'hui, le paysage est bien plus complexe. Aux techniques d'exploration traditionnelles s'est ajoutée une nouvelle vague de robots et d'extracteurs de données à l'échelle mondiale, motivée principalement par la collecte massive de données nécessaires à l'entraînement, à la mise à jour ou à l'enrichissement de nouveaux modèles de langage à grande échelle.
L'essor de l'intelligence artificielle générative a fait du contenu web public une ressource inestimable. Blogs, forums, documentation technique, sites de commerce électronique, descriptions de produits, fiches d'information, bases de connaissances, avis, portails éditoriaux et sites web d'entreprises sont devenus des cibles privilégiées pour quiconque souhaite collecter d'importantes quantités de texte, de données structurées ou d'informations sectorielles.
Dans certains cas, cette exploration est effectuée de manière transparente. Des opérateurs reconnus, tels qu'OpenAI ou Anthropic, utilisent des agents utilisateurs déclarés et documentés. Un robot d'exploration peut se présenter, par exemple, avec un agent utilisateur tel que : GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot ou similaire, permettant au gestionnaire du site de le reconnaître et d'appliquer des règles via robots.txt.
Voici la bonne approche : le bot s’annonce, déclare son identité et permet au webmaster de décider d’autoriser ou de refuser l’accès à certaines sections du site. Les directives Allow, Disallow ou toute indication de limitation de débit, lorsqu'elle est prise en charge ou respectée, permet au moins d'établir une relation claire entre ceux qui publient du contenu et ceux qui l'acquièrent.
Malheureusement, tout le monde ne se comporte pas ainsi.
On observe de plus en plus de robots d'exploration qui ne révèlent même pas leur nature automatisée. Au lieu de cela, ils se font passer pour de véritables utilisateurs en utilisant des agents utilisateurs apparemment légitimes, copiés des navigateurs les plus courants : Chrome, Safari, Firefox, Microsoft Edge, Opera, DuckDuckGo Browser, navigateurs mobiles, WebView Android, WebView iOS, etc.
Dans de nombreux cas, ces bots proviennent d'infrastructures cloud, de fournisseurs étrangers, de réseaux proxy, d'adresses IP résidentielles ou de types de réseaux difficiles à attribuer avec précision. Le trafic peut provenir de pays asiatiques, de centres de données européens ou américains, ou encore de réseaux apparemment locaux. L'objectif reste le même : se fondre dans le trafic légitime et rendre son blocage difficile à l'aide de règles simples.
Le problème fondamental est que l'agent utilisateur, en soi, n'a plus aucune valeur fiable. Il s'agit d'une chaîne de caractères librement paramétrable par le client. Un bot écrit en Python, Go, Rust, Node.js ou tout autre langage peut facilement se faire passer pour un navigateur Chrome sous Windows ou Safari sous macOS. Mais cela ne signifie pas que derrière cette requête se cache réellement un utilisateur assis devant un écran, avec un véritable navigateur, une véritable carte graphique, une véritable fenêtre d'affichage, un véritable environnement graphique et un comportement humain réel.
Lorsque l'exploration devient un problème de performance
Sur un site bien configuré, comme un blog doté d'une mise en cache efficace des pages, même un crawl massif peut avoir un impact relativement nul sur la charge. Si les requêtes sont traitées par Varnish, Nginx FastCGI Cache, un cache d'application ou un CDN, l'impact sur PHP, le processeur, la RAM et les bases de données peut être minime.
Un bot qui télécharge des pages déjà en cache génère du trafic, consomme de la bande passante, sature les journaux et peut fausser les statistiques et les indicateurs, mais il provoque rarement un plantage du serveur de l'application. Dans ces cas-là, le problème existe, mais il est souvent gérable, voire totalement négligeable, car il n'entraîne aucun dysfonctionnement.
La situation change radicalement lorsque le site n'est pas correctement mis en cache ou lorsqu'il s'agit d'un site e-commerce complexe. WooCommerce, Magento, PrestaShop et les plateformes similaires sont bien plus sensibles qu'un blog statique ou semi-statique. Un catalogue de produits peut générer des milliers, des dizaines de milliers, voire des millions d'URL différentes, surtout avec une navigation à facettes.
La navigation à facettes permet aux utilisateurs de filtrer les produits par couleur, taille, prix, marque, disponibilité, matière, catégorie, attribut, tri, pagination et autres critères. Du point de vue de l'expérience utilisateur, il s'agit souvent d'une fonctionnalité essentielle. Cependant, du point de vue de la sécurité et des performances, elle peut constituer une faille de sécurité importante.
Un robot d'exploration non autorisé peut exploiter une infinité de combinaisons de filtres et de paramètres. Il peut interroger des URL en constante évolution, souvent non mises en cache, forçant ainsi le serveur à générer dynamiquement chaque page. Le résultat est prévisible : PHP-FPM sature, MySQL ou MariaDB reçoivent des requêtes de plus en plus lourdes, la charge du processeur augmente, la RAM est consommée, la charge moyenne s'accroît et le temps de réponse du site se dégrade considérablement.
Dans ces scénarios, le passage d'un bot ne se limite plus à une simple exploration ; il sature l'application. Il ne s'agit pas toujours d'une attaque DDoS volumétrique au sens strict, mais le résultat est très similaire : le site ralentit, le processus de paiement devient instable, les utilisateurs légitimes ne peuvent plus naviguer, les conversions s'effondrent et les clients ont l'impression que le service est indisponible.
Le paradoxe est que le trafic malveillant ou indésirable ne se manifeste souvent pas immédiatement comme tel. Dans les journaux, il peut ressembler à du trafic de navigateur : l’agent utilisateur indique Chrome, l’adresse IP n’est pas nécessairement blacklistée, les requêtes sont formellement valides (requêtes HTTP), aucun code malveillant n’est détecté, aucune faille de sécurité n’est identifiable. Il s’agit simplement d’un nombre anormal de requêtes, réparties sur de nombreuses URL et susceptibles de générer une charge système réelle.
L'approche traditionnelle : plus de matériel, plus d'optimisation, plus de blocs
Lorsqu'un site commence à souffrir de ces problèmes, la première réaction consiste souvent à augmenter ses ressources matérielles. Cela implique de passer à davantage de processeurs, de mémoire vive, de disques plus rapides, d'une base de données distincte, d'un serveur plus puissant, d'instances cloud plus onéreuses ou d'architectures plus complexes.
Dans certains cas, cela s'avère nécessaire. Si un site a connu une croissance réelle, si le trafic légitime a augmenté, si le volume des ventes justifie une infrastructure plus robuste, la mise à l'échelle est la solution appropriée. Cependant, lorsque la charge est principalement due à du trafic automatisé indésirable, l'augmentation des ressources risque de ne faire qu'aggraver le problème, et ce, à grands frais.
Après les mises à niveau matérielles, vient généralement la phase d'optimisation. Nous analysons les requêtes lentes, améliorons les index de la base de données, réduisons les appels inutiles et corrigeons les plugins complexes, les modules inefficaces, les modèles lents, les configurations incorrectes et les caches manquants ou mal implémentés. Cela fait partie intégrante de notre travail quotidien.
Optimiser une application pour mieux servir les utilisateurs réels est une chose. L'optimiser pour gérer des centaines de requêtes par seconde générées par des bots indésirables en est une autre. Dans ce dernier cas, le problème ne se limite pas aux performances, mais concerne également le contrôle du trafic.
À ce stade, on a souvent recours au pare-feu, au blocage d'adresses IP, à la limitation du débit et au géoblocage. Des classes de réseaux entières, des ASN suspects, des pays d'où les clients ne devraient pas provenir, ou des zones géographiques jugées non pertinentes pour l'activité sont bloqués. Cette approche peut s'avérer efficace lorsque le site ne vend que sur certains marchés et que le trafic malveillant provient clairement de pays non desservis.
Mais ce n'est pas toujours comme ça.
Si un site de commerce électronique vend en Italie et que le trafic malveillant provient de l'étranger, le géoblocage peut constituer une solution acceptable. Cependant, si le trafic légitime et le trafic malveillant proviennent du même pays, bloquer l'ensemble du territoire national devient impossible . Si les bots utilisent des adresses IP résidentielles, des proxys distribués ou une infrastructure située sur les mêmes marchés que les clients légitimes, le géoblocage s'avère un outil trop rudimentaire.
Dans ces cas-là, un filtrage plus précis s'impose. Il ne suffit pas de se demander d'où vient la requête. Il faut commencer par s'interroger sur le client qui la génère réellement.
Bots d'IA et scanners de pirates informatiques : des objectifs différents, des méthodes similaires
Le même problème, sous diverses formes, existe depuis des années dans le domaine de la sécurité des applications. Dès qu'une vulnérabilité critique est découverte dans un plugin WordPress, un module WooCommerce, une extension PrestaShop, un composant Magento ou un CMS populaire, des analyses automatisées à grande échelle sont déclenchées.
Les attaquants savent que de nombreux sites ne sont pas mis à jour rapidement. Ils savent qu'un certain délai peut s'écouler entre la publication d'une faille et l'application d'un correctif. Ils savent qu'il existe des milliers d'installations vulnérables, souvent mal gérées, avec des plugins abandonnés, des thèmes obsolètes ou des modules non maintenus. C'est pourquoi ils développent des scanners automatiques capables de rechercher les versions vulnérables et, si possible, d'exploiter immédiatement la faille.
L'objectif de ces scanners est manifestement différent de celui des robots d'exploration basés sur l'IA. Les premiers consistent en la collecte, l'extraction ou l'acquisition massive de contenu. Les seconds impliquent la compromission, l'exploitation de failles de sécurité, le chargement de webshells, le vol de données, le spam, le défaçage de sites web ou l'accès non autorisé. La gravité des infractions est variable.
Mais d'un point de vue technique, il existe un élément commun fondamental : dans la plupart des cas, ces systèmes n'utilisent pas de véritables navigateurs.
Ils utilisent des clients HTTP automatisés. Il peut s'agir de scripts basés sur curl, des modules Python comme requests o aiohttpCe sont des agents écrits en Go, Rust, Node.js ou Java. Ils peuvent renommer l'agent utilisateur, falsifier les en-têtes, simuler les cookies, suivre les redirections et même gérer certaines réponses rudimentaires. Mais dans la plupart des cas, ce ne sont pas de véritables navigateurs.
Ils ne disposent pas d'un moteur graphique complet. Ils n'ont pas de véritable GPU. Ils n'ont pas de plugins. Ils n'ont pas d'historique. Aucun utilisateur ne déplace la souris, ne clique, ne fait défiler, ne change d'onglet, n'interagit avec la page. Souvent, ils n'ont même pas d'interpréteur JavaScript. Ils se contentent d'envoyer des requêtes GET et POST de manière rythmée, systématique et massive.
Même avec des solutions plus avancées basées sur des navigateurs sans interface graphique comme Chromium, pilotés par Puppeteer, Playwright ou Selenium, une différence significative persiste par rapport à un navigateur traditionnel utilisé par un humain. Un navigateur sans interface graphique peut exécuter du JavaScript, mais présente souvent des caractéristiques distinctives : propriétés anormales, empreintes numériques uniformes, fenêtres d’affichage artificielles, GPU logiciels, absence de plugins, comportement prévisible, ou encore incohérences entre l’environnement déclaré et l’environnement réel.
Et c'est là qu'intervient l'empreinte numérique du navigateur.
Qu'est-ce que l'empreinte numérique du navigateur ?
L'empreinte numérique du navigateur est un ensemble de techniques qui collectent des signaux provenant du navigateur et de son environnement d'exécution afin d'établir un profil technique du client. Ce profil peut servir à de nombreuses fins : analyse des fraudes, sécurité, détection des bots, prévention du web scraping, protection contre les abus, identification des anomalies ou vérification de la cohérence entre les informations déclarées par le client et son état réel.
Dans le cadre de la protection anti-bots, l'empreinte numérique ne sert pas nécessairement à identifier une personne. Elle permet plutôt de déterminer si le client effectuant la requête ressemble à un navigateur réel ou à un environnement automatisé.
La question n'est pas : « Qui est cet utilisateur ? »
La question pertinente est : « Ce client se comporte-t-il et se présente-t-il comme un véritable navigateur ou comme un processus automatisé prétendant en être un ? »
Cette distinction est cruciale. Un système de protection moderne n'a pas nécessairement à bloquer tout ce qu'il ne reconnaît pas. Il doit attribuer un niveau de risque, observer les signaux, les combiner et décider d'accepter, de bloquer, de limiter, de contester ou de surveiller plus attentivement la requête.
Un test isolé peut donner des faux positifs. En revanche, une série de tests correctement pondérés peut fournir une indication beaucoup plus fiable.
Les techniques les plus utiles pour distinguer les vrais navigateurs des robots
Un pare-feu applicatif web (WAF) moderne, notamment celui conçu pour distinguer les utilisateurs réels des robots automatisés, peut exploiter de nombreux signaux côté client. Certains sont simples, d'autres plus sophistiqués. Aucune technique n'est parfaite, mais la combinaison de plusieurs techniques permet d'obtenir un profil très efficace.
L'une des commandes les plus connues est celle sur navigator.webdriverCette propriété est souvent activée lorsqu'un navigateur est contrôlé par des outils d'automatisation tels que Selenium, Puppeteer ou Playwright. Si cet indicateur est activé, cela constitue un signal d'automatisation très fort.
Un autre contrôle concerne les langues du navigateur, disponible via navigator.languagesDans les navigateurs classiques, on trouve généralement un tableau correspondant aux paramètres de l'utilisateur, comme « italien », « italien-Italie », « anglais » ou d'autres combinaisons. Dans les navigateurs sans interface graphique ou les environnements artificiels, cette valeur peut être absente, vide ou réduite à une seule valeur générique.
Le nombre de plugins installés est également lisible via navigator.plugins.lengthCela peut fournir des informations intéressantes. Les navigateurs modernes proposent souvent des plugins ou des composants intégrés, contrairement à de nombreux environnements sans interface graphique. Bien que ce ne soit pas un indicateur définitif, car l'évolution des navigateurs a considérablement réduit le rôle des plugins traditionnels, cette corrélation reste utile.
La profondeur de couleur, obtenue à partir de screen.colorDepthCes paramètres peuvent révéler des anomalies. Des valeurs trop faibles, nulles ou incohérentes indiquent souvent des environnements de rendu irréalistes ou mal configurés. De même, la résolution d'écran, le rapport entre la fenêtre d'affichage et l'écran, le rapport de pixels du périphérique et d'autres paramètres graphiques permettent de distinguer un périphérique réel d'un environnement simulé.
Le fuseau horaire, qui peut être obtenu via Intl.DateTimeFormat().resolvedOptions().timeZoneVoici une autre donnée précieuse. Si une adresse IP semble être géolocalisée en Italie, mais que le navigateur affiche un fuseau horaire incompatible, cela ne signifie pas automatiquement qu'il s'agit d'un robot, mais c'est certainement un indice à prendre en compte. Les VPN, les voyages et les configurations inhabituelles existent, mais avec un grand nombre de cas, ces incohérences deviennent statistiquement significatives.
Aussi navigator.maxTouchPoints Cela peut s'avérer utile. Un véritable appareil mobile possède souvent plusieurs points de contact, tandis qu'un environnement émulé peut déclarer des valeurs absentes ou incohérentes avec l'agent utilisateur. Si un client se présente comme un iPhone mais n'expose pas de fonctionnalités compatibles avec un appareil tactile, il y a un problème.
navigator.hardwareConcurrencyLe nombre de cœurs logiques disponibles, indiqué par le numéro du processeur, peut révéler des valeurs suspectes. Une valeur nulle, absente ou excessivement élevée peut indiquer un environnement artificiel. Il en va de même pour le numéro du processeur. navigator.deviceMemory, lorsqu'elle est disponible, cette fonction fournit une estimation de la mémoire de l'appareil. De nombreux navigateurs sans interface graphique ou environnements automatisés signalent des valeurs manquantes, génériques ou incohérentes.
Parmi les techniques les plus connues figure l'empreinte digitale du canevas. Une image est générée sur un élément de canevas 2D en dessinant du texte, des formes, des couleurs et des transformations. Le résultat est ensuite converti en une représentation mesurable. Chaque combinaison de système d'exploitation, de moteur graphique, de polices, de GPU et de pilotes peut engendrer de légères différences. Les navigateurs sans interface graphique, surtout s'ils sont standardisés et largement déployés, tendent à générer un rendu plus uniforme et prévisible.
Un raisonnement similaire s'applique à WebGL. En interrogeant certaines propriétés du moteur de rendu, lorsqu'elles sont disponibles, vous pouvez obtenir des informations sur le GPU ou le moteur de rendu logiciel utilisé. Les navigateurs sans interface graphique ou les environnements virtualisés peuvent exposer des moteurs de rendu tels que SwiftShader, Mesa ou d'autres backends logiciels, plutôt qu'un GPU matériel correspondant au périphérique déclaré.
Il existe ensuite des contrôles spécifiques pour les anciens frameworks d'automatisation. PhantomJS, par exemple, peut laisser les objets globaux comme window.callPhantom o window._phantomNightmare.js peut exposer window.__nightmareLes anciennes versions de Selenium peuvent laisser des traces telles que document.__selenium_unwrapped, window.__selenium_evaluate o document.__webdriver_evaluate.
Un autre ensemble de vérifications concerne la présence d'environnements Node.js ou JSDOM. Dans un navigateur réel, les objets globaux comme process o BufferCes éléments sont typiques des environnements côté serveur ou simulés. S'ils sont présents dans le contexte de la page, il s'agit probablement d'un environnement autre qu'un navigateur.
D'autres signaux peuvent provenir de l'API Permissions, de l'état des notifications, de la présence de window.chrome, comportement de l'API audio, gestion des polices, prise en charge de WebRTC, codecs multimédias, capteurs disponibles, cohérence entre l'agent utilisateur et les indications client, gestion des cookies, temps d'exécution JavaScript et comportement du client après la première visite.
La valeur ne réside pas dans le test individuel, mais dans le score global.
L'important est de ne pas utiliser ces tests aveuglément. Bloquer un utilisateur sur la seule base d'un paramètre anormal peut générer de faux positifs. Cela concerne notamment les navigateurs spécifiques, les extensions de confidentialité, les configurations d'entreprise, les appareils embarqués, WebView, les navigateurs intégrés aux applications, les modes restrictifs, les systèmes anti-pistage et les utilisateurs réels disposant d'environnements non standard.
C’est pourquoi l’approche la plus efficace est celle du système de notation.
Chaque test contribue à un score de risque. Certains signes sont très graves, d'autres seulement légèrement suspects. Par exemple, navigator.webdriver Un serveur actif peut être très significatif. Un fuseau horaire incohérent l'est moins. L'absence de plugins peut être un signe d'alerte mineur. Un moteur de rendu WebGL logiciel peut être plus significatif lorsqu'il est combiné à d'autres éléments. La présence d'objets PhantomJS ou Selenium obsolètes peut être considérée comme très grave.
À ce stade, le WAF peut prendre des décisions progressives.
Un client ayant un score très bas, par exemple inférieur à 20, peut être considéré comme légitime. Dans ce cas, sa demande peut être automatiquement acceptée et, le cas échéant, un cookie signé peut lui être attribué, permettant ainsi de le reconnaître lors des requêtes ultérieures sans avoir à se réauthentifier systématiquement.
Un client avec un score très élevé, proche de 100 par exemple, peut être bloqué immédiatement. S'il échoue à la quasi-totalité des tests et présente des signes évidents d'automatisation, il est inutile de gaspiller les ressources du serveur.
Les cas intermédiaires sont les plus intéressants. Un score de 50 ou 60 peut indiquer un client douteux : son comportement n’est pas suffisamment sûr pour être accepté automatiquement, mais pas assez grave pour être bloqué sans appel. Dans ces cas-là, un contrôle plus approfondi peut être appliqué : un script JavaScript intermédiaire, une vérification comportementale, une demande d’interaction, une case à cocher manuelle, ou une méthode similaire à celles popularisées par les systèmes de détection d’attaques.
Ce modèle progressif est bien plus efficace que le modèle binaire. Il ne divise pas le monde en « bon » et « mauvais » sur la base d'un simple en-tête, mais établit une évaluation dynamique et adaptative.
Pourquoi bloquer avant la mise en cache et avant le backend ?
Un aspect souvent négligé est le point de l'infrastructure où le filtrage est effectué. Si le bot est bloqué après avoir atteint PHP ou la base de données, le mal est déjà en partie fait. Même une réponse 403 générée par l'application consomme des ressources. Un plugin de sécurité WordPress, s'il est exécuté dans WordPress, nécessite l'initialisation du CMS, le chargement de PHP, des requêtes à la base de données et de la mémoire.
C’est pourquoi les protections les plus efficaces doivent agir le plus en amont possible.
Idéalement, le filtre devrait intervenir au niveau du proxy inverse, du WAF, de Nginx, d'OpenResty, de Varnish, ou en tout cas avant que la requête n'atteigne le serveur de l'application. Bloquer une requête indésirable en moins d'une milliseconde, sans faire intervenir PHP-FPM ni interroger MySQL, est bien plus efficace que de laisser le CMS décider.
Ce principe est particulièrement important sur les sites de commerce électronique. Si un robot d'indexation génère des milliers de requêtes vers des pages produits non mises en cache, chaque requête interceptée avant d'atteindre le serveur représente un gain de temps pour le processeur, des requêtes évitées et un temps de réponse préservé pour les utilisateurs.
Un pare-feu applicatif web (WAF) antibot bien conçu ne doit pas devenir un goulot d'étranglement. Il doit être rapide, léger, déterministe pour les opérations les plus fréquentes et capable de prendre des décisions basées sur des cookies signés, des listes noires, des listes blanches, des scores et des règles de comportement.
Notre expérience avec WAF 4 NGINX
Forts de notre expérience récente, nous avons développé en interne un système WAF, AntiBot et AntiCrawler propriétaire appelé WAF 4 NGINX , à ne pas confondre avec l'application commerciale du même nom historiquement associée à F5 Networks et aujourd'hui connue sous un autre nom commercial : « App Protect ».
L'objectif était clair : disposer d'une solution propriétaire, sur site et contrôlable, intégrable à notre infrastructure et conceptuellement similaire à certaines des fonctionnalités popularisées par Cloudflare, mais sans obliger le client à changer de serveurs de noms, à déléguer le trafic à des tiers ou à adopter un service externe qui n'était pas toujours compatible avec les contraintes organisationnelles, bureaucratiques ou liées au RGPD.
De nombreux clients utilisent Cloudflare sans problème. D'autres, en raison de politiques internes, d'exigences contractuelles, de la sensibilité des données, de contraintes de conformité ou de choix d'infrastructure, préfèrent ou doivent conserver un contrôle total sur le chemin des requêtes. Dans ces cas, la protection locale, intégrée directement au proxy inverse Nginx, représente un avantage considérable.
WAF 4 NGINX est conçu avec plusieurs modes de fonctionnement. Il inclut des systèmes de listes blanches et noires, des interdictions temporaires, des règles de filtrage personnalisées, des contrôles du comportement des requêtes, des défis JavaScript, des modes transparents, des interstitiels et une vérification plus intrusive telle que la case à cocher humaine.
Le mode transparent est particulièrement intéressant car il permet d'effectuer la vérification sans afficher de bannières, de logos, de pages intermédiaires ni de messages visibles pour l'utilisateur. Le visiteur continue de naviguer normalement tandis que le système collecte les signaux, évalue l'empreinte numérique, attribue un score et décide d'émettre ou non un cookie HMAC signé certifiant la réussite de la vérification.
Le mode interstitiel, quant à lui, s'avère utile dans les cas les plus critiques, lorsque le site est attaqué, fait l'objet d'un crawl intensif ou lorsque du trafic anormal commence déjà à impacter les performances du serveur. Dans ce scénario, une barrière explicite est mise en place avant l'accès effectif au site : le visiteur est temporairement bloqué sur une page intermédiaire pendant que le système effectue des vérifications côté client, contrôle la capacité d'exécuter du JavaScript, évalue l'empreinte numérique du navigateur et décide d'autoriser ou non la poursuite de la navigation.
Ce mode est plus visible que le contrôle transparent, mais il a l'avantage de réduire immédiatement la charge sur l'infrastructure, en empêchant les clients suspects d'accéder directement aux pages dynamiques, aux catalogues, aux filtres, aux points de terminaison de recherche ou aux zones particulièrement gourmandes en ressources de calcul. Il est particulièrement utile lors de pics soudains de trafic, de campagnes massives de web scraping, d'analyses automatisées à grande échelle ou de tentatives de saturation d'applications.
La vérification manuelle (case à cocher) représente le niveau de contrôle le plus intrusif, mais aussi l'un des plus efficaces pour distinguer clairement le trafic humain du trafic automatisé . Exigeant une interaction explicite, elle permet de bloquer de nombreux bots qui, bien que capables d'exécuter du JavaScript ou de simuler partiellement un navigateur, ne sont pas conçus pour passer une vérification manuelle. Du fait de son caractère plus intrusif, elle doit être utilisée avec discernement, de préférence dans les cas à haut risque ou en dernier recours pour les clients présentant un niveau de suspicion intermédiaire ou élevé.
Résultats obtenus en production
Les résultats obtenus en production ont été très significatifs. En cas de problèmes liés à un crawling intensif, un scraping agressif ou des attaques DDoS de couche 7, l'introduction du WAF nous a permis de réduire drastiquement la charge sur le serveur et, systématiquement, d'éliminer les interventions manuelles d'urgence auparavant nécessaires pour gérer les saturations soudaines.
Plus précisément, nous avons observé une réduction de 50 à 70 % de la charge du serveur sur les sites très fréquentés, notamment lorsque le plantage survenait avant le cache Varnish et le serveur de l'application. Cela se traduit par une diminution des requêtes PHP et des requêtes de base de données, une moindre saturation du processeur et une stabilité perçue accrue pour les utilisateurs.
Le temps de réponse du WAF est resté constamment inférieur à 1 milliseconde (pendant le développement, nous avons même envisagé des optimisations à la nanoseconde) par requête dans 99,9 % des cas mesurés en production. ngx.now() sur des charges réelles. C'est crucial : la protection anti-bot doit protéger, et non alourdir. Si le système de défense introduit une latence importante à chaque requête, il risque de devenir une partie du problème.
Un autre résultat important a été l'élimination des faux positifs détectés chez les utilisateurs réels en mode transparent, grâce à la combinaison de l'authentification par défi, de l'empreinte digitale et des cookies HMAC signés. Une fois le client vérifié, le système peut le reconnaître efficacement sans avoir à répéter constamment des contrôles coûteux ou intrusifs.
La compatibilité a été vérifiée avec les principaux navigateurs modernes, y compris WebView mobile et les navigateurs intégrés à des applications comme Facebook, Instagram, DuckDuckGo et autres environnements embarqués. Ceci est essentiel car de nombreux utilisateurs ne naviguent plus exclusivement depuis Chrome sur ordinateur ou Safari classique. Ils utilisent des applications, des navigateurs intégrés, des appareils mobiles, des environnements axés sur la confidentialité et des configurations avec des politiques de sécurité du contenu restrictives.
Un système anti-bot moderne doit tenir compte de cette diversité. Il doit être efficace contre les systèmes automatisés, mais il ne doit pas pénaliser les utilisateurs réels simplement parce qu'ils naviguent dans un contexte moins traditionnel.
Pourquoi une solution sur site peut être préférable
Cloudflare a eu le mérite de rendre accessibles à un très large public des outils avancés de protection, de mise en cache, d'atténuation des attaques DDoS, d'optimisation du trafic et de lutte contre les bots. L'entreprise a également contribué à ouvrir la voie, sur le plan technique et conceptuel, à l'émergence de solutions propriétaires rares comme la nôtre.
Il serait hypocrite de prétendre qu'une solution comme WAF 4 NGINX aurait pu être créée de la même manière sans l'existence de plateformes telles que Cloudflare. Cloudflare a popularisé une approche moderne de la protection des applications : le filtrage du trafic avant qu'il n'atteigne le serveur, l'évaluation du comportement du client, l'application de défis progressifs, la distinction entre les utilisateurs légitimes et les attaques automatisées, et la protection du site non seulement contre les attaques volumétriques, mais aussi contre les abus au niveau applicatif.
Pour de nombreux sites, des services comme celui-ci offrent une solution efficace, pratique et rapide à mettre en œuvre. En quelques étapes seulement, vous pouvez activer une protection performante, bénéficier d'un réseau mondial distribué, réduire la charge sur le serveur d'origine, atténuer les attaques DDoS, optimiser la gestion du cache et intégrer des mécanismes anti-bots sans avoir à développer de composants complexes en interne. Ce modèle est parfaitement adapté aux blogs, aux sites d'entreprise, aux portails éditoriaux et à de nombreux sites e-commerce.
Cependant, ce n'est pas toujours la solution idéale.
Déléguer la gestion du trafic HTTP et HTTPS à un tiers implique de faire transiter les requêtes, les en-têtes, les cookies, les adresses IP, les URL visitées et, dans certains cas, même des données sensibles par une infrastructure externe . Pour de nombreuses organisations, cela ne pose pas de problème, surtout lorsque les avantages opérationnels surpassent largement les implications architecturales. Pour d'autres entreprises, en revanche, ce choix exige une réflexion beaucoup plus approfondie.
Certaines organisations, pour des raisons de politique interne, refusent que le trafic web transite par un intermédiaire externe. D'autres ne peuvent pas modifier leurs serveurs de noms car le DNS est géré par différents services, des fournisseurs tiers, des politiques d'entreprise ou des procédures bureaucratiques très strictes. Dans d'autres cas encore, le domaine fait partie d'une infrastructure plus vaste, avec des enregistrements, des délégations, des configurations de messagerie, des services existants et des contraintes opérationnelles qui rendent toute modification de la gestion DNS complexe, voire risquée.
Il existe également des contextes où les contraintes légales, contractuelles ou de conformité sont cruciales. Les entreprises qui traitent des données sensibles, les administrations publiques, les portails de santé, les plateformes B2B, les sites de commerce électronique soumis à des obligations spécifiques en matière de traitement des données, ou les entités soumises à des politiques RGPD très restrictives peuvent préférer conserver le contrôle de l'intégralité du cycle de gestion des demandes au sein de leur propre infrastructure.
Une solution sur site vous permet de contrôler précisément le traitement des requêtes, la collecte des données, leur durée de conservation, la signature des cookies, la rédaction des journaux et l'application des règles. Ce niveau de contrôle est essentiel pour les entreprises manipulant des données sensibles, les sites e-commerce à fort trafic, les portails B2B, les infrastructures publiques ou les clients soumis à des exigences de conformité strictes. La solution WAF 4 NGINX que nous avons développée et implémentée répond parfaitement à ces exigences de gouvernance et de confidentialité, en s'exécutant directement sur le serveur du client.
De plus, une solution locale peut être adaptée précisément à chaque infrastructure. Un site WordPress avec WooCommerce n'a pas les mêmes besoins qu'un site Magento. Une boutique PrestaShop avec navigation à facettes ne se comporte pas comme un blog éditorial. Un portail headless n'a pas les mêmes caractéristiques qu'un site web traditionnel. Un pare-feu applicatif web (WAF) intégré au proxy inverse peut être personnalisé pour chaque cas spécifique, au lieu d'appliquer des règles génériques.
L'empreinte digitale ne signifie pas bloquer les utilisateurs soucieux de leur vie privée
Une objection légitime concerne le respect de la vie privée. Le fingerprinting du navigateur est souvent associé au suivi publicitaire et au profilage intrusif. Il est donc important de clarifier la différence entre le fingerprinting utilisé à des fins publicitaires et celui utilisé à des fins de sécurité.
Dans le premier cas, l'objectif est d'identifier ou de suivre un utilisateur sur différents sites, souvent sans son consentement explicite, à des fins commerciales ou publicitaires. Dans le second cas, l'objectif est de déterminer si un client est réel ou automatisé, de protéger l'infrastructure, de prévenir les abus et le web scraping, et d'atténuer les attaques applicatives.
Un système bien conçu n'a pas besoin de créer de profils persistants intrusifs. Il peut simplement calculer un score technique, signer un cookie de validation, appliquer une date d'expiration raisonnable et ne conserver que les informations nécessaires à la sécurité. Le principe doit être la minimisation : collecter juste assez d'informations pour distinguer un robot d'un navigateur légitime, et non pas assez pour profiler l'utilisateur.
Il est également important d'éviter toute approche punitive envers les utilisateurs soucieux de leur vie privée. Les navigateurs dotés de protections anti-pistage, d'extensions de confidentialité, de configurations restrictives ou d'empreintes digitales partiellement masquées ne devraient pas être automatiquement considérés comme malveillants. Ils devraient simplement recevoir un score cohérent et, si nécessaire, faire l'objet d'une vérification non intrusive.
L’identification anti-bot doit être un outil de sécurité, et non un outil de surveillance.
L'avenir du filtrage sera de plus en plus comportemental.
Le simple blocage d'adresses IP est voué à devenir de moins en moins efficace. Les bots modernes peuvent changer d'adresse IP, utiliser des proxys résidentiels, répartir les requêtes, modifier leur agent utilisateur, simuler des en-têtes réalistes et imiter certaines fonctionnalités des navigateurs.
C’est pourquoi l’avenir de la protection reposera de plus en plus sur une combinaison de signaux. L’empreinte numérique, l’analyse comportementale, la réputation IP, la cohérence géographique, la fréquence des requêtes, les habitudes de navigation, la validation JavaScript, les cookies signés, les défis progressifs et l’observation du trafic devront tous fonctionner de concert.
Un utilisateur réel ne navigue pas comme un robot d'extraction de données. Il n'ouvre pas systématiquement des milliers de combinaisons de filtres. Il n'interroge pas des centaines d'URL par minute à intervalles parfaitement réguliers. Il ne néglige pas complètement les ressources, les images, les CSS et les JavaScript. Il ne passe pas d'une catégorie à l'autre en suivant un ordre alphabétique ou paramétrique. Il n'attaque pas séquentiellement des points d'accès vulnérables connus sur des dizaines de sites différents.
Le comportement est révélateur. Les empreintes digitales le sont tout autant. La cohérence entre les données déclarées et les données réelles l'est tout autant. La force d'un WAF moderne réside dans la combinaison de ces éléments.
conclusion
La gestion automatisée du trafic est devenue un défi opérationnel majeur pour les propriétaires de sites web modernes. L'essor des robots d'exploration basés sur l'IA, combiné à la persistance des scanners malveillants à la recherche de vulnérabilités dans les systèmes de gestion de contenu, a mis en évidence un point essentiel : nous ne pouvons plus nous fier aux agents utilisateurs, aux adresses IP ni à des règles statiques trop simplistes.
Lorsque du trafic indésirable atteint des sites mal conçus pour la mise en cache, des sites de commerce électronique complexes ou des plateformes à navigation à facettes, les conséquences peuvent être désastreuses : une utilisation du processeur en flèche, des bases de données surchargées, des processus de paiement lents, des utilisateurs légitimes pénalisés et une augmentation inutile des coûts d’infrastructure.
L'ajout de matériel peut être utile, mais ne résout pas le problème de fond. L'optimisation de la base de données est essentielle, mais insuffisante si la charge est générée par des bots. Bloquer des pays entiers peut fonctionner dans certains cas, mais devient impraticable lorsque le trafic légitime et malveillant provient des mêmes zones géographiques.
Une approche plus intelligente, chirurgicale et adaptative est nécessaire.
L'empreinte numérique du navigateur, utilisée correctement et dans le respect de la vie privée, permet de distinguer plus précisément un navigateur légitime d'un client automatisé. Associée aux défis JavaScript, aux cookies signés, au système de notation progressive, aux blocages temporaires, aux listes blanches, aux listes noires et au filtrage par proxy inverse, elle devient un outil extrêmement efficace pour protéger les sites web et l'infrastructure applicative.
Notre expérience avec WAF 4 NGINX montre qu'il est possible d'atteindre un niveau de protection comparable, voire supérieur dans certains cas, à celui de solutions externes comme Cloudflare, tout en conservant un contrôle total sur votre infrastructure, la confidentialité de vos données et la conformité réglementaire.
Le but n'est pas de tout bloquer, mais de faire la distinction.
Distinguer le vrai client du robot.
Distinguez le robot d'exploration déclaré du robot de raclage masqué.
Distinguer le véritable navigateur du client HTTP qui se fait passer pour lui.
Distinguer le trafic utile du trafic qui consomme des ressources, réduit les performances et met en péril la disponibilité du service.
Dans un web de plus en plus peuplé d'agents automatisés, cette capacité de distinction n'est plus un luxe technique, mais une nécessité opérationnelle.
Si votre site subit des surcharges injustifiées et que vous n'arrivez pas à contenir efficacement les robots et les crawlers, contactez-nous ! Nous avons les compétences et la solution qu'il vous faut !
