📌 Ce qu’il faut retenir

1. Un mauvais score n’indique pas un piratage. Il signale surtout des protections techniques absentes, incomplètes ou à revoir. Un scanner externe ne peut pas confirmer l’intégrité de WordPress, des comptes ou de la base de données.
2. Les en-têtes HTTP sont un bon premier contrôle. CSP, HSTS, X-Content-Type-Options ou les règles d’intégration dans une iframe réduisent certaines surfaces d’attaque lorsqu’ils sont correctement adaptés au site.
3. Le scan ne doit pas rester ponctuel. Une mise à jour du CMS, du serveur, du CDN ou d’une extension peut modifier les réponses HTTP. Refaire le contrôle après un changement important permet de repérer une régression.
4. La première action est de corriger ce qui est compris. Ajouter une politique CSP trop stricte sans test peut casser des scripts légitimes. La configuration doit être testée sur le site avant généralisation.

Résumé généré par IA

Scanner son site web gratuitement : ce que mesure le test

Cet article complète notre guide comment tester la sécurité de votre site web publié la veille, qui détaille l’ensemble des outils gratuits disponibles et leurs limites. Ici, on se concentre sur un cas concret.

Pour un premier contrôle externe, deux services suffisent à faire ressortir des signaux utiles : MDN HTTP Observatory et SecurityHeaders.com. Ils interrogent l’adresse publique du site puis analysent notamment les en-têtes renvoyés par le serveur. Aucun accès WordPress, FTP ou hébergeur n’est nécessaire pour ce type de test.

Ce contrôle est donc intéressant avant un audit plus large. Il répond à une question simple : quelles protections un navigateur reçoit-il lorsqu’il charge le site ? Il ne répond pas à toutes les autres. Un bon score ne garantit ni l’absence d’extension vulnérable, ni la solidité des mots de passe, ni l’absence d’injection SQL ou de compromission passée.

L’objectif de cette page est différent : comprendre ce que les premiers signaux signifient et dans quel ordre agir.

Quel outil pour scanner son site sans fausse conclusion ?

Un scanner gratuit doit être utilisé comme un révélateur de configuration, pas comme un certificat de sécurité. Nous cherchons d’abord les écarts qui sont visibles depuis l’extérieur et qui peuvent être vérifiés sans perturber le site.

Cette distinction évite une erreur fréquente : corriger un score au lieu de corriger un risque. Chaque en-tête doit avoir un objectif. Le projet OWASP Secure Headers documente les protections utiles et leurs cas d’emploi. Il rappelle aussi qu’une configuration dépend du contexte technique.

Les 3 erreurs de sécurité web qui reviennent souvent

1. Des en-têtes de sécurité HTTP absents ou incomplets

Le premier signal est souvent une réponse HTTP trop permissive. HSTS indique au navigateur qu’il doit utiliser HTTPS pour les connexions futures. CSP permet de contrôler plus finement les ressources qu’une page peut charger. X-Content-Type-Options évite certains comportements de détection de type non souhaités.

Pour l’intégration dans des cadres, X-Frame-Options reste utile en compatibilité, mais la directive CSP frame-ancestors offre un contrôle plus moderne et plus souple. Il ne faut donc pas juger la sécurité d’un site sur la seule présence d’un nom d’en-tête.

Si ces notions sont nouvelles, commencez par notre guide pour corriger vos en-têtes de sécurité. Il est préférable de comprendre la fonction d’un réglage avant de le copier dans Apache, Nginx, un CDN ou une extension WordPress. Notre guide sécuriser un site web de PME replace ce réglage dans une stratégie de protection plus complète.

2. HTTPS est actif, mais sa protection n’est pas forcément complète

Voir un cadenas dans le navigateur ne suffit pas à conclure que toute la configuration HTTPS est optimale. Un scanner d’en-têtes peut notamment constater la présence ou l’absence de HSTS. En revanche, l’analyse détaillée des versions TLS, des suites cryptographiques et de la chaîne de certificats demande un outil spécialisé.

Cette nuance est importante. Mélanger « HTTPS actif », « HSTS présent » et « TLS correctement configuré » conduit à des diagnostics trop rapides. Le premier décrit le canal utilisé, le second une politique imposée au navigateur, le troisième exige une analyse plus large de la couche de transport.

3. Le scan est fait une fois puis oublié

Un résultat correct aujourd’hui peut évoluer après une migration, une modification du CDN, un changement de serveur ou l’installation d’une extension. La sécurité ne gagne donc rien à rester un contrôle unique réalisé lors de la mise en ligne.

Le réflexe utile est simple : conserver une référence, puis relancer les mêmes contrôles après une modification importante. Si un score baisse, cherchez d’abord la différence de configuration. Cela transforme le scanner en outil de détection de régression, plutôt qu’en simple générateur de note.

En-têtes de sécurité HTTP : quoi corriger en premier ?

La priorité n’est pas d’ajouter tous les en-têtes disponibles. Elle consiste à identifier les protections pertinentes, vérifier leur compatibilité avec le site et les déployer progressivement. Une CSP mal préparée peut bloquer des scripts, des polices, des formulaires ou des services tiers indispensables.

Commencez par inventorier les en-têtes déjà renvoyés. Vérifiez ensuite HTTPS et HSTS, puis les politiques liées au chargement des ressources, au cadrage et aux types de contenu. Pour CSP, un mode de rapport peut aider à observer les violations avant de rendre la politique bloquante.

• faire un scan externe de référence ;
• identifier les avertissements réellement applicables au site ;
• corriger un réglage à la fois ;
• tester les pages, formulaires et services tiers ;
• relancer le scan et documenter le résultat.

Cette méthode est moins spectaculaire qu’un empilement d’extensions, mais elle facilite le diagnostic. Elle permet aussi de savoir quel changement a amélioré ou dégradé le résultat.

Diagnostic sécurité site web : quand passer au-delà du scan gratuit ?

Le scan gratuit atteint vite sa limite dès qu’il faut vérifier l’intérieur du site. Si vous devez contrôler les comptes, les mises à jour, les extensions, les sauvegardes, les journaux, les permissions, le serveur ou des signes de compromission, il faut élargir le diagnostic.

C’est également le cas lorsque le site collecte des données personnelles, réalise des transactions, donne accès à un espace client ou joue un rôle important dans l’activité. Le niveau de contrôle doit être proportionné aux risques et aux conséquences d’une interruption.

Vous pouvez utiliser le scan comme point de départ, puis demander un diagnostic de votre site web si les alertes sont difficiles à interpréter ou si vous voulez vérifier les couches que ces outils publics ne voient pas. Pour une vue d’ensemble de la démarche, notre article comment tester la sécurité de votre site web explique aussi ce qu’un scan gratuit ne peut jamais détecter.

Ce que ce test gratuit apporte vraiment

Scanner son site web gratuitement est utile pour obtenir un premier état visible de sa configuration et repérer des protections manquantes. C’est rapide, reproductible et accessible sans accès technique au site. Sa vraie valeur vient toutefois de l’interprétation : un score n’est ni une preuve de piratage, ni une garantie de sécurité.

Le bon enchaînement est donc de tester, comprendre, corriger puis vérifier à nouveau. Si les anomalies dépassent les en-têtes HTTP ou si le site porte un enjeu métier important, le scan devient l’entrée d’un diagnostic plus complet, pas sa conclusion.