Pourquoi les sites légitimes redirigent-ils parfois vers des pages malveillantes sans que vous le sachiez ?

Qu'est-ce qu'une redirection malveillante via compromission ?

La déclaration vise les cas où un site légitime et propre devient vecteur d'attaque sans action volontaire du propriétaire. Le scénario classique : un script tiers hébergé sur votre site (publicité, analytics, widget) est modifié à la source par un attaquant qui contrôle le serveur d'origine.

Résultat : vos visiteurs sont redirigés vers des pages de phishing, des arnaques ou des sites distribués de malwares. Vous ne voyez rien dans votre propre code source, parce que la compromission se situe ailleurs, dans une ressource externe que vous incluez aveuglément.

Comment Google détecte-t-il ces redirections cachées ?

Le crawler de Google exécute du JavaScript et suit les redirections en temps réel. Si votre page charge un script qui, une fois évalué, envoie le visiteur vers un domaine suspect, Google enregistre ce comportement et le lie à votre URL.

Le problème, c'est que la redirection peut être conditionnelle : elle ne se déclenche que pour certains user-agents, certaines géolocalisations ou certaines plages horaires. Le Googlebot peut passer à travers sans rien voir, puis toucher un échantillon d'utilisateurs réels qui, eux, se font piéger.

Pourquoi Google mentionne-t-il spécifiquement les « ressources » ?

Parce que la majorité des compromissions ne touche pas directement le code HTML du site victime. Les attaquants ciblent les dépendances externes : bibliothèques JS obsolètes, CDN compromis, plugins WordPress non maintenus, serveurs publicitaires tiers.

Vous incluez un fichier depuis un domaine externe qui semblait safe, et trois mois plus tard ce domaine change de main ou se fait hacker. Votre site devient instantanément complice sans que vous ayez modifié une ligne de code.

• Les redirections malveillantes passent souvent par des ressources tierces compromises, pas par votre propre serveur.
• Google suit les redirections JS et peut vous pénaliser même si vous êtes victime involontaire.
• La détection côté Google n'est pas toujours immédiate : un site peut infecter des visiteurs pendant des jours avant d'être blacklisté.
• Les attaques conditionnelles (par IP, par user-agent) échappent souvent au crawl initial.
• Un site propre qui charge des ressources sales est traité comme un site sale par Google.

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, totalement. J'ai vu des dizaines de cas où un site propre se retrouve dans Search Console avec un avertissement « Site compromis » alors que le propriétaire n'a jamais touché au code. L'audit révèle systématiquement un script tiers injecté ou un CDN détourné.

Ce qui est moins clair, c'est le seuil de tolérance de Google. Combien de visiteurs doivent être redirigés avant que le site soit blacklisté ? Google ne le dit pas. [A vérifier] : aucune donnée publique sur le délai entre détection et pénalité.

Quelles nuances faut-il apporter à cette affirmation ?

La notion de « site légitime » est floue. Google ne distingue pas toujours la victime du complice. Si votre site charge un script malveillant pendant une semaine, vous serez traité comme responsable, même si vous étiez de bonne foi.

Autre point : Google parle de « contenu modifié par des sites malveillants », mais ne précise pas si cela inclut les redirections client-side via JS uniquement, ou aussi les redirections serveur (301/302) injectées via .htaccess compromis. Mon observation : les deux sont sanctionnés, mais les redirections JS conditionnelles sont plus difficiles à détecter.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si la redirection est légitime et déclarée (ex : un site qui redirige volontairement vers un partenaire commercial), Google ne considère pas cela comme une compromission. Le problème surgit quand la redirection est non intentionnelle et non documentée.

Autre cas limite : les redirections géolocalisées pour raisons légales (RGPD, blocage de certains pays). Google tolère si c'est transparent et documenté dans robots.txt ou via des balises canoniques. Mais si tu rediriges l'Inde vers un site tiers sans justification, tu vas morfler.

Que faut-il faire concrètement pour protéger son site ?

Première étape : auditer toutes les ressources externes chargées par ton site. Ça veut dire lister chaque <script src=>, chaque CDN, chaque pixel de tracking, chaque widget social. Si tu ne contrôles pas le domaine source, tu prends un risque.

Ensuite, active une Content Security Policy (CSP) stricte. Ça ne bloquera pas toutes les attaques, mais ça limite drastiquement les vecteurs d'injection. Configure un CSP qui autorise uniquement les domaines que tu connais et surveille les violations via les rapports CSP.

Quelles erreurs éviter absolument ?

Ne jamais inclure un script tiers sans vérifier sa Subresource Integrity (SRI). Si le fichier distant change, le navigateur refusera de l'exécuter. Ça casse l'attaque à la racine.

Autre erreur classique : installer des plugins WordPress ou des thèmes nulled récupérés sur des forums douteux. Ces fichiers sont souvent déjà compromis à l'installation, avec des backdoors pré-intégrées.

Comment vérifier que mon site est propre et conforme ?

Utilise Google Search Console pour surveiller les alertes de sécurité. Mets en place un monitoring continu avec des outils comme Sucuri, Wordfence (pour WordPress) ou des solutions agnostiques comme VirusTotal pour scanner tes pages publiques.

Teste ton site avec des user-agents variés et depuis différentes géolocalisations. Les redirections malveillantes sont souvent conditionnelles, elles ne se déclenchent que pour certains profils de visiteurs.

• Inventorier toutes les ressources externes (scripts, CDN, iframes) et documenter leur provenance.
• Implémenter une Content Security Policy (CSP) stricte et surveiller les rapports de violation.
• Activer la Subresource Integrity (SRI) sur tous les scripts tiers critiques.
• Scanner régulièrement le site avec des outils de détection de malwares (Sucuri, Wordfence, VirusTotal).
• Vérifier Search Console quotidiennement pour détecter les alertes de compromission.
• Tester le site avec plusieurs user-agents et géolocalisations pour détecter les redirections conditionnelles.