Site signalé comme piraté par Google : le déroulé, et ce que le retour demande

Un site compromis ne perd pas son trafic le jour de l’intrusion. Il le perd le jour où un moteur de recherche s’en aperçoit, et il ne le récupère pas au moment où le problème est corrigé. Cet écart entre les trois dates est ce qui rend le sujet mal compris, et ce qui explique pourquoi la facture est toujours plus lourde que prévu.

Cet article décrit l’ordre réel des étapes, les mécanismes par lesquels la visibilité tombe, et ce que personne ne peut vous promettre sur le délai de retour.

L’ordre des étapes

Il est presque toujours le même, et aucune étape ne saute son tour.

1. Quelque chose devient lisible. Un fichier de configuration servi par erreur, un composant dont l’éditeur a arrêté le suivi, une interface d’administration accessible sans restriction. À ce stade, rien ne s’est produit : le défaut existe, il est public, et il attend.
2. Un robot le trouve. Personne ne vous a ciblé. Des programmes parcourent le Web en permanence en essayant les mêmes adresses, dans le même ordre, sur tous les domaines qu’ils rencontrent. C’est un balayage, pas une attaque.
3. Le site sert du contenu que son propriétaire n’a jamais écrit. Le cas courant n’est pas la page défigurée, qui se voit tout de suite : c’est l’injection discrète de pages ou de redirections destinées à d’autres moteurs de recherche que vous. Elles ne sont visibles ni sur votre page d’accueil, ni dans votre interface d’administration.
4. Le moteur détecte l’anomalie. En quelques jours dans les cas que nous observons. Le site est alors signalé dans les résultats, et parfois dans le navigateur des visiteurs.
5. La visibilité tombe. Pas d’un coup, et c’est ce qui trompe : la baisse ressemble d’abord à une saisonnalité.
6. Le nettoyage. Il faut retirer le contenu injecté, refermer la porte, et considérer comme compromis tous les secrets qui étaient lisibles.
7. La demande de réexamen, puis l’attente. Cette dernière étape n’est pas sous votre contrôle, et elle dure.

Entre l’étape 1 et l’étape 4, il existe une fenêtre pendant laquelle le défaut est déjà public et où rien n’est encore arrivé. C’est la seule sur laquelle un outil d’observation peut faire une différence.

Pourquoi les positions tombent

Trois mécanismes agissent en même temps, et on les confond souvent en un seul.

Le signalement. C’est le plus visible. Un résultat accompagné d’un avertissement perd une grande partie de ses clics, même quand il reste en place. Le classement n’a pas bougé ; le trafic, oui.

Le budget d’exploration détourné. Les pages injectées sont explorées comme les vôtres. Sur un site de quelques milliers d’URL, une injection massive occupe une part significative de ce que le moteur accepte de parcourir chez vous, et vos pages réelles sont revisitées moins souvent. Vos mises à jour légitimes cessent d’être prises en compte à la vitesse habituelle.

La perte de cohérence du site. Les pages injectées parlent d’un autre sujet, dans une autre langue, vers d’autres destinations. Elles diluent ce que votre site déclare être. Cet effet est le plus lent à apparaître, et le plus lent à se dissiper.

Le premier mécanisme se corrige par le nettoyage. Les deux autres se corrigent par l’exploration, donc par le temps.

Ce que Search Console vous montre, et ce qu’elle ne montre pas

Search Console signale les problèmes de sécurité détectés et permet de demander un réexamen. C’est l’outil de référence, et il faut le surveiller.

Deux limites méritent d’être connues. La première : c’est un outil de constat, pas de prévention. Il vous parle une fois que le moteur a détecté quelque chose, c’est-à-dire à l’étape 4 de la liste ci-dessus, quand le coût est déjà engagé. La seconde : il ne dit rien des signaux publiquement observables des étapes 1 à 3. Un fichier de configuration lisible n’est pas une anomalie de son point de vue, tant que personne ne s’en est servi.

Les signaux qui précèdent, et qui se relèvent de l’extérieur

Ils ont une propriété commune : ils sont visibles depuis Internet, avec les moyens d’un visiteur ordinaire, sans identifiants et sans rien modifier.

• Un fichier de configuration servi tel quel. C’est le cas le plus grave, parce qu’il livre directement des secrets utilisables : mot de passe de base de données, clés d’envoi d’e-mails, jetons d’API. Bloquer l’accès ne suffit pas ensuite : le fichier a pu être lu avant que vous ne le sachiez, et les secrets doivent être changés.
• Un composant dont l’éditeur a arrêté le suivi. Les défauts découverts après la fin du support restent ouverts indéfiniment, et ils sont documentés publiquement : ce sont les premiers essayés par les robots de balayage.
• Du code source exposé. Un répertoire de gestion de versions laissé dans la racine publique donne l’historique du projet, et parfois des identifiants qui y ont séjourné.
• Un certificat expiré ou mal chaîné. Le navigateur avertit avant même que la page ne s’affiche. L’effet sur la conversion est immédiat, et il n’attend aucun moteur.
• Des ressources non chiffrées appelées depuis une page sécurisée. Un script chargé sans chiffrement peut être remplacé en transit. Le navigateur bloque parfois silencieusement, et la page se dégrade sans erreur visible.
• Le statut de votre domaine chez Google Safe Browsing. C’est la même source que celle qui déclenche l’avertissement dans le navigateur des visiteurs, et elle est interrogeable directement.

Aucun de ces relevés ne demande d’accès à votre serveur. Ils constatent ce que votre site expose déjà, à qui le demande.

Ce que personne ne peut vous promettre

C’est la partie que les prestataires évitent, et il vaut mieux la lire avant de choisir.

Le délai de retour n’est pas mesurable à l’avance. Il dépend de la décision d’un tiers. Les ordres de grandeur que nous observons se comptent en semaines après la demande de réexamen, mais publier un nombre de jours serait une invention.

La disparition d’un constat ne prouve pas une correction. Un relevé qui ne trouve plus rien peut signifier que le défaut est corrigé, ou que le passage a échoué. Deux passages ne se comparent que si chacun sait dire qu’il est allé au bout, sans quoi « disparu » se lit « réglé ».

Un relevé extérieur ne voit pas ce qui n’est pas exposé. Ce qui exige un compte, un mot de passe ou un accès au serveur reste hors de portée, par construction. C’est la limite de tout constat fait de l’extérieur, et elle est structurelle : la lever demanderait des accès que personne ne devrait accorder pour une observation.

L’ordre des opérations, si c’est déjà arrivé

1. Refermez l’accès, sans attendre d’avoir compris toute l’histoire.
2. Changez tous les secrets qui étaient lisibles. Base de données, clés d’API, jetons d’envoi. Considérez-les comme connus.
3. Retirez le contenu injecté, en cherchant les pages que vous n’avez pas écrites plutôt que celles que vous connaissez.
4. Vérifiez l’adresse fautive après correction. Une réponse vide en 200 reste une réponse : le fichier est toujours servi.
5. Demandez le réexamen, une fois, avec le détail de ce qui a été fait.
6. Surveillez l’exploration, pas seulement le classement. Le retour des positions suit le retour des visites de robots, jamais l’inverse.

Ce qu’il faut retenir

La sanction est une sanction de visibilité, et elle arrive après coup. La seule marge de manœuvre se situe entre le moment où un défaut devient lisible et celui où un moteur le remarque, c’est-à-dire exactement là où un relevé extérieur régulier a une valeur. Après, il ne reste qu’à nettoyer et à attendre une décision qui ne vous appartient pas.