3 scanners de sécurité gratuits donnent 3 résultats différents — à qui faire confiance ?

L'alerte JavaScript détectée par le deuxième outil est très probablement un mécanisme de redirection conditionnelle. Les codes malveillants ne s'affichent pas pour les administrateurs connectés, ils ne se déclenchent que pour les visiteurs dont le referer est Google. Récupérez le code de la page depuis le terminal avec curl en utilisant différents User-Agent et Referer. Cherchez dans le fichier des fonctions suspectes comme eval, base64_decode ou document.write.

Avant de paniquer, vérifiez deux choses : d'abord connectez-vous à la Search Console de Google pour votre site et allez dans l'onglet Problèmes de sécurité ; si Google a repéré un danger il y sera clairement indiqué. Ensuite, déterminez la date de la dernière sauvegarde saine de votre site. Si le problème a commencé il y a quelques jours, comparer avec la sauvegarde reste la méthode la plus rapide.

L'année dernière, on a ignoré une alerte similaire parce que deux scanners disaient que tout était propre. 48 heures plus tard, le moteur de recherche bloquait notre site avec un écran rouge. Les pubs ont été coupées et on a perdu environ 4.200 dollars de chiffre d'affaires cette semaine-là. Le rapport « clean » des scanners externes donne un faux sentiment de sécurité, donnez toujours la priorité au rapport qui signale une infection.

Que le troisième scanner classe le site en risque élevé juste pour des en-têtes HTTP, c'est une technique marketing classique. Beaucoup d'outils gratuits exagèrent l'absence d'en-têtes de sécurité comme si le serveur était infecté par un virus tout ça pour vous vendre leur plugin payant. Ne confondez pas un défaut de configuration et une infection par un malware actif.

edit : j'ai corrigé quelques fautes de frappe.

je vous conseille vraiment de pas négliger l'alerte sur le script externe. en général c'est des vieux compteurs oubliés sur le site ou des pixels de chat tiers qui se font pirater pour injecter des redirections. jetez un œil entre les balises head dans le code source, si ya un domaine inconnu ça saute direct aux yeux.

Votre site tourne sous WordPress ou c'est un développement sur mesure ? Et ce fichier JavaScript suspect il est hébergé sur votre propre serveur ou chargé depuis un serveur externe ? Si vous pouvez préciser ces deux points ce sera plus facile de vous guider.

Pour y voir plus clair parmi ces rapports contradictoires, procédez dans cet ordre : 1) Notez l'URL exacte du script jugé suspect par le deuxième scanner. 2) Ouvrez le code source du fichier sur le serveur et cherchez des codes de redirection anormaux. 3) Vérifiez la date de dernière modification via FTP ou le panneau d'hébergement. 4) Laissez de côté pour l'instant les alertes de certificats et d'en-têtes du troisième outil.

Ne vous découragez pas, ce genre de faux positif ou de petite fuite de script arrive souvent sur les sites e-commerce actifs. Si vous hésitez à toucher au code, ouvrez un ticket auprès du support de votre hébergeur en leur transmettant les logs du deuxième scanner, ils feront un scan antivirus côté serveur gratuitement.

J'ai vécu exactement la même chose il y a deux ans. Commencez par un petit test ne vous engagez pas sur tout d'un coup.

Je suis aussi curieux de savoir si d'autres font autrement.

je trouve difficile d'être aussi catégorique côté scanner de sécurité de site web gratuit. les gens défendent l'habitude pas le processus... du coup la résistance vient de là.

Pensez-vous que cela fonctionne à toutes les échelles ? Le temps que vous mettez à détecter un problème détermine directement son coût.

Bon courage.

Nous avons aussi bloqué au même endroit à une époque. Quand on essaie de tout changer en même temps, rien ne prend.

Commencez par un petit test, ne vous engagez pas sur tout d'un coup. C'est mon avis, je ne l'écris pas comme une vérité absolue.

trois avis différennts sont sortis, ils se complètent tous puis si l'autorisation et le périmètre ne sont pas écrits ne lancez pas ce test.

à votre placce j'irais par cette voie.

Exact. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

Je suis aussi curieux de savoir si d'autres font autrement.

Je suis entièrement d'accord. Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.

Je suis aussi curieux de savoir si d'autres font autrement.

Je suis d'accord j'aimerais même souligner ce point. Les gens défendent l'habitude pas le processus. La résistance vient de là.

C'est confirmé par l'expérience.

Ma question va paraître un peu novice, désolé d'avance. Le temps que vous mettez à détecter un problème détermine directement son coût.

Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur. Je le note au cas où.

J'écris cela pour éviter que vous ne fassiez la même erreur. N'hésitez pas à demander, celui qui ne demande pas paie toujours plus cher.

Voilà, désolé si je me suis étendu.