Analyse sécurité site web : notre enquête sur un trafic suspect venu de Hong Kong

Cette question, beaucoup de dirigeants se la posent un jour. Pour y répondre sérieusement, il ne suffit pas de lancer un scanner en ligne : il faut une véritable analyse sécurité site web, qui croise les statistiques de visite, les journaux du serveur, l’intégrité des fichiers, les comptes utilisateurs et la configuration du pare-feu.

Ce dossier raconte, étape par étape et de façon anonymisée, l’enquête que nous avons menée pour ce client : un site WordPress avec une boutique WooCommerce. Vous y verrez ce que cachait ce trafic suspect, pourquoi Google Analytics ne filtre pas ce type de trafic de robots, comment nous avons découvert une tentative de fraude à la carte bancaire que personne n’avait remarquée, et surtout la méthode pour faire le même contrôle sur votre propre site.

Qu’est-ce qu’une analyse sécurité site web ?

Une analyse sécurité site web est un examen méthodique d’un site pour répondre à trois questions : le site est-il compromis, est-il en train d’être attaqué, et quelles faiblesses pourraient être exploitées demain ? Elle s’appuie sur des preuves (journaux, empreintes de fichiers, historique des connexions) et se termine par une liste de corrections classées par priorité.

On la confond souvent avec d’autres prestations. Elles sont complémentaires, mais ne répondent pas au même besoin.

Dans notre cas, la demande relevait clairement de l’analyse : un signal inhabituel, et le besoin de savoir vite s’il fallait s’inquiéter. Pour une revue de fond de votre protection, notre article sur l’audit de sécurité avant incident détaille la démarche.

Le point de départ : un trafic suspect dans Google Analytics

Le client avait repéré le phénomène dans le rapport des pays de Google Analytics 4 : un flux régulier de visites attribuées à Hong Kong, jour après jour. En regardant de plus près, ces sessions avaient plusieurs points communs typiques d’un trafic automatisé :

• une source de trafic « Direct » ou « (not set) », sans moteur de recherche ni site référent ;
• un temps d’engagement proche de zéro seconde ;
• une seule page vue par session, toujours les mêmes pages : accueil, création de site, panier, contact ;
• des visites étalées sur toute la journée et la nuit, à intervalles réguliers ;
• aucune conversion, aucun utilisateur qui revient.

Pris isolément, aucun de ces signaux ne prouve une attaque. Ensemble, ils indiquent presque toujours des robots. Reste à savoir lesquels, et ce qu’ils cherchent. Un robot qui indexe des pages pour une intelligence artificielle n’a pas la même gravité qu’un robot qui teste des mots de passe ou des numéros de carte.

Pourquoi Google Analytics ne filtre pas ce trafic de robots

Beaucoup de propriétaires de site pensent que Google Analytics élimine automatiquement les robots. C’est vrai, mais seulement en partie. Selon l’aide officielle de Google, GA4 exclut d’office le trafic des robots et des araignées connus, identifiés grâce aux recherches de Google et à la liste internationale des robots tenue par l’IAB. Ce filtre ne peut pas être désactivé, et il est impossible de savoir combien de visites il a retirées.

Le problème, c’est le mot « connus ». Ce filtre repose surtout sur la signature que le robot annonce (son « user-agent »). Un robot honnête se présente comme tel ; un robot malveillant se présente comme un Chrome ordinaire. Pire, les robots modernes utilisent des navigateurs sans interface (« headless ») qui exécutent le JavaScript de la page, y compris la balise Google Analytics. Pour GA4, ils ressemblent à de vrais visiteurs.

L’enjeu n’est pas marginal. D’après le rapport annuel Bad Bot Report d’Imperva (groupe Thales), les robots ont produit 51 % du trafic web mondial en 2024, dont 37 % de robots malveillants ; l’édition 2026 fait état de 53 % de trafic automatisé en 2025, dont environ 40 % de robots malveillants. Le commerce en ligne fait partie des secteurs les plus visés.

Conclusion pratique : Google Analytics est un excellent outil marketing, mais un mauvais outil de sécurité. Pour savoir ce qui se passe vraiment, il faut descendre d’un étage, côté serveur. Notre guide complet de Google Analytics 4 explique par ailleurs comment lire correctement ses rapports.

Notre méthode d’analyse sécurité en 6 étapes

Nous suivons toujours la même démarche, du plus rapide au plus profond. L’objectif est de répondre vite à la question « suis-je piraté ? » sans rien modifier sur le site avant d’avoir compris.

Un point technique mérite d’être signalé dès l’étape 2 : lorsque le site passe par un CDN ou un pare-feu en ligne (Cloudflare, Sucuri, etc.), les journaux du serveur n’enregistrent souvent que les adresses de ce service, pas celles des visiteurs. Il faut alors raisonner sur les signatures et les comportements, puis confirmer l’origine réelle dans le tableau de bord du CDN. C’est exactement ce qui s’est produit ici. Nous expliquons plus largement l’intérêt de ces fichiers dans notre article sur l’analyse des logs serveur.

Ce que les journaux du serveur ont révélé

Sur les trois jours de journaux disponibles, le site avait reçu environ 124 000 requêtes. Une fois écartés les robots de moteurs de recherche, les outils de surveillance et les robots d’intelligence artificielle qui s’annoncent clairement, une signature ressortait nettement : un navigateur « Chrome sur Android » à l’origine d’environ 13 000 requêtes en trois jours, soit plus de 10 % du trafic total à lui seul.

Son comportement n’avait rien d’humain. Environ toutes les heures, il chargeait les mêmes pages en exécutant leur JavaScript (d’où les visites dans Google Analytics), puis enchaînait une série d’adresses qui n’existent pas sur un site WordPress :

• des points d’accès d’API : /graphql, /api/graphql, /swagger, /api-docs ;
• des pages de réglages de développeur : /settings/api-keys, /settings/developer, /webhooks, /internal, /debug ;
• des fichiers .js.map, les « cartes de code source » qui accompagnent parfois les scripts et peuvent révéler du code ou des secrets oubliés.

Ce robot ne cherchait donc pas à pirater WordPress. Il cherchait des clés d’API et des secrets exposés par erreur, une mine d’or pour les attaquants : une clé de paiement, d’envoi d’e-mails ou d’intelligence artificielle permet d’utiliser un service aux frais de sa victime. Toutes ses requêtes ont reçu une erreur 404 : rien de tel n’était exposé. Nous détaillons les bonnes pratiques dans notre article sur la protection des clés d’API et des secrets dans le code.

Et Hong Kong ? Les statistiques du pare-feu ont permis de tordre le cou à l’intuition de départ. Ce robot passait par des adresses du monde entier (Canada, États-Unis, Allemagne, Singapour, Pays-Bas, Belgique…), probablement via des proxys résidentiels qui empruntent les connexions de particuliers. Le trafic réellement venu de Hong Kong ne représentait qu’environ 300 requêtes par jour, dont plus de la moitié étaient déjà interceptées par les règles automatiques du pare-feu. Une partie de ce reliquat cherchait des portes dérobées classiques (fichiers PHP aux noms suspects), sans succès. Bloquer un pays n’aurait donc rien réglé.

Un trafic inexpliqué apparaît dans vos statistiques ? Demandez une analyse de votre site par nos experts

Le site était-il piraté ? Les contrôles d’intégrité

Un robot insistant ne prouve pas un piratage. Pour répondre à la question du client, nous avons vérifié tout ce qu’un attaquant modifie habituellement après une intrusion réussie.

Les journaux montraient aussi de nombreuses attaques… toutes échouées : tentatives sur xmlrpc.php bloquées, page de connexion standard introuvable car déplacée, appels non autorisés à l’API d’installation d’extensions refusés. C’est la preuve que des protections simples, mises en place plus tôt, faisaient leur travail en silence.

Le site n’était donc pas piraté. En revanche, la dernière ligne du tableau a changé le cours de l’enquête.

La vraie découverte : des tests de cartes bancaires volées

En consultant le journal d’activité de WordPress, nous avons trouvé onze comptes clients créés sur deux périodes de quelques jours, avec des noms générés au hasard et des adresses e-mail factices. Chacun suivait exactement le même scénario, en moins de deux minutes :

1. création d’un compte depuis la page « Mon compte » de la boutique ;
2. connexion immédiate, depuis une adresse différente à chaque fois (Brésil, Mexique, Allemagne…) ;
3. visite des pages « Moyens de paiement » puis « Ajouter un moyen de paiement » ;
4. abandon, puis nouveau compte une heure plus tard.

Ce schéma porte un nom : le card testing, ou test de cartes. Des fraudeurs qui ont acheté des listes de numéros de cartes volées vérifient lesquelles fonctionnent encore. Plutôt que de passer de vraies commandes, ils utilisent une fonction plus discrète : l’enregistrement d’une carte dans l’espace client, qui déclenche une vérification auprès de la banque. Les cartes validées sont ensuite revendues plus cher ou utilisées ailleurs.

Pour le commerçant, les conséquences peuvent être lourdes, même s’il ne perd aucune marchandise :

• frais de transaction facturés sur chaque tentative par certains prestataires de paiement ;
• rétrofacturations si des paiements frauduleux aboutissent ;
• suspension du compte marchand : les prestataires de paiement surveillent ce type d’activité et peuvent geler les encaissements d’une boutique qui sert de terrain de test ;
• pollution de la base clients et des statistiques de la boutique.

Stripe, l’un des principaux prestataires de paiement, rappelle d’ailleurs que la lutte contre le test de cartes est une responsabilité partagée entre le commerçant, les réseaux de cartes et le prestataire, et qu’elle passe souvent par des réglages côté site. WooCommerce publie lui aussi une documentation dédiée à ces attaques. Dans notre cas, les tentatives avaient échoué, mais rien n’empêchait qu’elles recommencent.

Les mesures prises, couche par couche

Une fois le diagnostic posé, nous avons appliqué des corrections ciblées, sans gêner les vrais clients, et en notant chaque réglage d’origine pour pouvoir revenir en arrière.

1. Fermer les portes inutiles de la boutique

La boutique proposait la création libre d’un compte sur la page « Mon compte » et l’enregistrement d’une carte en dehors de toute commande. Aucune de ces deux fonctions n’était utile aux clients réels. Nous les avons désactivées : un client peut toujours commander sans compte, ou créer son compte au moment du paiement. Les pages qui servaient aux fraudeurs renvoient désormais une erreur 404.

2. Ajouter une vérification anti-robot au pare-feu

Le site était déjà protégé par un CDN avec pare-feu applicatif. Nous y avons ajouté une règle qui impose une vérification anti-robot (« Managed Challenge ») sur l’espace client et sur les adresses sondées par le robot. Un humain passe cette vérification en une seconde, souvent sans rien voir ; un script automatisé est bloqué. Les robots vérifiés des moteurs de recherche sont exclus de la règle : aucun impact sur le référencement.

3. Nettoyer ce qui ne sert plus

Une ancienne extension de suivi, désactivée depuis longtemps, était restée installée. Une extension inutilisée ne s’exécute pas, mais elle reste un code de plus à surveiller. Nous l’avons archivée puis supprimée.

4. Planifier un contrôle de suivi

Une attaque qui échoue revient souvent sous une autre forme : la surveillance du site web doit donc se poursuivre après les corrections. Un nouveau contrôle est programmé une semaine plus tard pour mesurer l’effet des règles, vérifier l’absence de faux positifs et décider des étapes suivantes.

Ce que nous avons volontairement évité

Deux réflexes courants auraient été contre-productifs. Bloquer Hong Kong n’aurait servi à rien, puisque le robot principal passait par des dizaines de pays. Quant aux listes blanches par pays (« autoriser tout le trafic de France ou du Canada »), elles sont fréquentes pour éviter de gêner ses propres clients, mais elles ont un effet pervers : sur la plupart des pare-feu, une règle « Autoriser » désactive toutes les autres protections pour ce trafic. Un robot qui emprunte une connexion française passe alors sans contrôle. C’est un point que nous avons signalé au client pour décision.

Vous voulez un pare-feu et des règles adaptés à votre site ? Découvrez notre offre de protection de site web

Les signaux d’alerte à surveiller sur votre site

Voici les signaux qui doivent déclencher une analyse, classés par gravité. La plupart se repèrent sans compétence technique.

Si l’un des signaux « Urgent » apparaît, ne perdez pas de temps : suivez notre guide d’urgence en cas de site piraté, puis notre article site piraté : quoi faire étape par étape.

Faire sa propre analyse sécurité site web : la check-list

Vous n’avez pas forcément besoin d’un prestataire pour un premier contrôle. Voici la liste que nous utilisons, du plus simple au plus technique. Les premiers points sont accessibles à tout gestionnaire de site.

1. Google Search Console : rubrique « Problèmes de sécurité » et « Actions manuelles ». Une alerte ici est prioritaire sur tout le reste.
2. Google Analytics : comparez les pays, les sources et le temps d’engagement des quatre dernières semaines avec la même période de l’année précédente.
3. Liste des utilisateurs : supprimez les comptes inutiles, vérifiez chaque administrateur et activez la double authentification.
4. Mises à jour : cœur du CMS, thème et extensions à jour ; supprimez ce qui est désactivé.
5. Sauvegardes : vérifiez qu’une sauvegarde récente existe hors du serveur et qu’elle peut être restaurée.
6. Journal d’activité : installez-en un si ce n’est pas fait ; sans lui, impossible de savoir qui a fait quoi.
7. Intégrité des fichiers : comparez le cœur et les extensions aux versions officielles (les extensions de sécurité et l’outil en ligne de commande WP-CLI le font).
8. Journaux du serveur : adresses et signatures les plus actives, pages en erreur 404 répétées, requêtes vers des fichiers sensibles.
9. Boutique : inscriptions, tentatives de paiement refusées, fonctions d’espace client réellement utiles.
10. Pare-feu ou CDN : règles actives, listes blanches trop larges, statistiques par pays et par type de robot.

Pour les sites WordPress, notre page dédiée à la sécurité WordPress décrit les protections que nous mettons en place, et notre article sur la sécurité web expliquée sans jargon reprend les bases.

Filtrer le trafic de robots dans Google Analytics

Une fois la menace écartée, reste la question des statistiques faussées par les bots dans Google Analytics. GA4 offre peu de leviers pour exclure ce trafic après coup : ses filtres de données ne concernent que le trafic interne et le trafic de développement. Plusieurs solutions existent toutefois :

• Bloquer à la source : la meilleure option. Un robot arrêté par le pare-feu ne charge jamais la balise Google Analytics, et vos chiffres redeviennent fiables pour l’avenir.
• Comparer avec un segment : dans les explorations, créez une comparaison qui exclut les sessions sans engagement venant des pays où vous n’avez pas de clients.
• Exclure les référents indésirables : dans les paramètres du flux de données, la liste des référents indésirables évite qu’un domaine parasite apparaisse comme source.
• Annoter : notez la date de l’incident et des corrections pour que les rapports futurs restent interprétables.

Ne cherchez pas à « nettoyer » le passé à tout prix : l’important est de savoir quelle part de vos chiffres est réelle au moment de prendre des décisions marketing.

Protéger sa boutique contre les tests de cartes

Le test de cartes vise toutes les plateformes. Les leviers sont les mêmes partout, seuls les réglages changent.

Sur PrestaShop, le problème des inscriptions frauduleuses est fréquent : notre article sur les faux comptes clients sur PrestaShop détaille les solutions. Et si vous gérez une boutique WooCommerce, notre agence WooCommerce peut auditer vos réglages de paiement.

Et si des données personnelles ont fuité ?

Dans notre cas, aucune donnée n’a été exposée. Mais si une analyse révèle une intrusion avec accès à des données de clients, des obligations légales s’appliquent, avec des délais courts. Elles varient selon le pays.

Dans tous les cas, documentez chaque constat et chaque action dès le début de l’analyse : ce journal servira autant pour la notification que pour l’assurance éventuelle.

Les idées reçues sur la sécurité des petits sites

• « Mon site est trop petit pour intéresser les pirates. » Les robots ne choisissent pas leurs cibles : ils balaient tout le web. Une petite boutique est même une cible idéale pour le test de cartes, car elle est souvent moins surveillée.
• « Google Analytics filtre les robots. » Seulement ceux qui s’annoncent. Les robots qui imitent un navigateur passent à travers.
• « Bloquer la Chine ou Hong Kong suffit. » Les attaquants utilisent des proxys dans tous les pays, y compris le vôtre.
• « Pas piraté, donc pas de risque. » Notre cas le montre : le site était sain, mais sa boutique servait à valider des cartes volées.
• « Une extension de sécurité suffit. » Elle est utile, mais elle ne voit qu’une couche. La protection efficace combine réglages, pare-feu, mises à jour et surveillance.

Conclusion : une analyse sécurité vaut mieux qu’une inquiétude

Un trafic suspect dans Google Analytics n’est pas toujours le signe d’un piratage, mais ce n’est jamais un détail à ignorer. Dans le cas de notre client, quelques heures d’analyse sécurité site web ont suffi pour écarter l’hypothèse du piratage, identifier un robot à la recherche de clés d’API et découvrir une tentative de fraude à la carte passée inaperçue.

La leçon dépasse ce cas précis : la sécurité d’un site se joue dans les détails (une fonction de boutique inutile, une liste blanche trop large, une extension oubliée), et seule une vérification méthodique permet de les repérer. Si vous avez un doute sur votre site, mieux vaut le lever maintenant que le découvrir dans le tableau de bord de votre banque.

Questions fréquentes sur l’analyse sécurité d’un site web

Comment savoir si mon site web a été piraté ?

Pour savoir si un site web a été piraté, il faut vérifier plusieurs indices : un administrateur inconnu, des redirections vers d’autres sites, des pages en langue étrangère dans les résultats de Google ou une alerte dans la rubrique « Problèmes de sécurité » de Google Search Console. Il faut ensuite comparer les fichiers du site aux versions officielles du CMS et des extensions, et examiner les connexions récentes dans le journal d’activité. En cas de doute, une analyse sécurité permet de trancher en quelques heures.

Pourquoi ai-je du trafic de Hong Kong ou de Chine dans Google Analytics ?

Le trafic inexpliqué de Hong Kong ou de Chine dans Google Analytics provient le plus souvent de robots hébergés sur des serveurs cloud asiatiques ou passant par des proxys. Ces robots exécutent le JavaScript des pages et sont donc comptés comme des visiteurs, avec un temps d’engagement proche de zéro et une seule page vue. Ce trafic fausse les statistiques mais n’indique pas à lui seul un piratage. Seuls les journaux du serveur ou du pare-feu permettent de savoir ce que ces robots cherchent.

Comment exclure le trafic des robots dans GA4 ?

GA4 exclut automatiquement les robots connus, mais ses filtres de données ne permettent pas d’exclure les autres robots après coup. La solution la plus efficace consiste à bloquer ces robots en amont avec un pare-feu applicatif ou un CDN, afin qu’ils ne chargent plus la balise. Pour l’historique, on peut créer des comparaisons ou des segments qui excluent les sessions sans engagement des pays non ciblés. La liste des référents indésirables traite, elle, les sources parasites.

Qu’est-ce que le card testing sur une boutique en ligne ?

Le card testing, ou test de cartes, est une fraude qui consiste à utiliser une boutique en ligne pour vérifier si des numéros de cartes bancaires volées sont encore valides. Les fraudeurs passent par de petites commandes ou par l’ajout d’une carte dans l’espace client, souvent de façon automatisée. Le commerçant subit des frais, des rétrofacturations et risque la suspension de son compte marchand. Désactiver les fonctions inutiles et ajouter une vérification anti-robot réduit fortement ce risque.

Combien de temps prend une analyse sécurité de site web ?

Une analyse sécurité de site web prend généralement de quelques heures à deux jours pour un site vitrine ou une boutique de taille moyenne. La durée dépend de l’accès aux journaux du serveur, de la présence d’un journal d’activité et de la complexité du site. Le diagnostic initial (piraté ou non) est souvent posé dans la journée, puis les corrections sont appliquées par ordre de priorité. Un contrôle de suivi quelques jours plus tard vérifie l’efficacité des mesures.

À quelle fréquence faut-il analyser la sécurité de son site ?

Il est recommandé d’analyser la sécurité de son site au moins une fois par an, et après chaque événement inhabituel : pic de trafic inexpliqué, alerte de Google, inscriptions suspectes ou paiements refusés en série. Les sites e-commerce et ceux qui traitent des données sensibles gagnent à être contrôlés tous les trimestres. Entre deux analyses, des mises à jour régulières, des sauvegardes testées et une surveillance automatique couvrent l’essentiel des risques.

Nos sources

• Aide Google Analytics, exclusion du trafic des robots connus
• Imperva (Thales), Bad Bot Report
• ITPro, AI is helping bad bots take over the internet (Bad Bot Report 2025)
• Stripe, documentation sur le test de cartes
• WooCommerce, prévenir et répondre aux attaques par test de cartes
• Cloudflare, documentation sur les vérifications anti-robot (challenges)