Un scan SSL et une vérification Google Safe Browsing ne couvrent qu’une fraction de la surface d’attaque réelle d’un site. Nous observons régulièrement des sites affichant un score A+ sur leurs en-têtes HTTP tout en déposant des traceurs avant consentement ou en exposant des comptes partagés sans traçabilité. Pour tester la sécurité d’un site internet de façon réellement utile, il faut dépasser le simple diagnostic technique et intégrer la conformité réglementaire, la gestion des cookies et les politiques d’authentification.
Conformité des cookies et traceurs : le test que les scanners ignorent
La majorité des outils gratuits d’analyse de sécurité se concentrent sur le certificat TLS, les en-têtes HTTP et la présence éventuelle du domaine sur une liste noire. Aucun d’entre eux ne vérifie le comportement réel du bandeau de consentement aux cookies.
C’est un angle mort coûteux. La CNIL a poursuivi en 2025 ses sanctions contre les sites qui déposent des traceurs avant le consentement, ne permettent pas un refus aussi simple que l’acceptation, ou continuent à lire des cookies après le retrait du consentement. Nous recommandons de procéder à un test en trois étapes distinctes après chaque mise en production :
- Charger la page en navigation privée et capturer les requêtes réseau avant toute interaction avec le bandeau. Tout cookie tiers déposé à ce stade constitue une non-conformité.
- Refuser les traceurs, poursuivre la navigation sur plusieurs pages, puis vérifier via les outils développeur que le refus est effectivement respecté sur l’ensemble du parcours.
- Accepter les cookies, retirer le consentement via le lien prévu, et contrôler que la lecture des traceurs cesse réellement. Un test limité à la page d’accueil ne suffit pas.
Ce protocole prend moins de dix minutes. Il couvre pourtant un périmètre que les scanners automatisés n’abordent pas, et qui représente la première source de sanctions CNIL sur les sites web français.
Avant de lancer un audit technique classique, il est pertinent de tester la sécurité d’un site internet en combinant analyse des vulnérabilités et vérification du comportement des traceurs.
Scan de vulnérabilités web : ce qu’un outil automatisé détecte vraiment
Un scanner de sécurité en ligne (type analyse des en-têtes HTTP, vérification SSL/TLS, détection de malwares via Google Safe Browsing) produit un diagnostic utile, mais partiel. Ces outils identifient les failles connues : absence de Content-Security-Policy, version TLS obsolète, domaine blacklisté.
Les failles logiques restent invisibles aux scanners automatisés. Une élévation de privilèges via un paramètre URL mal contrôlé, un formulaire de contact sans protection CSRF, ou une API exposant des données utilisateur sans authentification ne déclenchent aucune alerte dans un scan passif.
Pour un site e-commerce ou une application avec espace client, nous recommandons de compléter le scan automatisé par un test manuel ciblé sur trois points :
- Tenter d’accéder à des ressources protégées en manipulant les identifiants dans l’URL (IDOR). Si le serveur renvoie des données sans vérifier l’identité du demandeur, la faille est critique.
- Injecter des chaînes de test XSS dans tous les champs de saisie visibles. Un formulaire qui renvoie le contenu sans échappement HTML expose les visiteurs au vol de session.
- Vérifier les en-têtes de réponse sur chaque endpoint API, pas uniquement sur la page d’accueil. Les politiques de sécurité varient souvent d’une route à l’autre sur un même domaine.
Un rapport de scanner affichant un score élevé ne garantit rien si ces vérifications manuelles n’ont pas été menées.
Politique d’authentification et comptes partagés : une faiblesse sanctionnée
La CNIL a signalé dans son bilan 2025 que 14 organisations ont été sanctionnées pour sécurité insuffisante, notamment en raison de mots de passe trop faibles ou de comptes partagés entre plusieurs utilisateurs. Ce constat concerne autant les back-offices de sites web que les accès aux bases de données.
Tester la sécurité d’un site sans auditer la politique de mots de passe revient à vérifier la serrure en laissant la clé sous le paillasson. Nous observons encore des CMS dont le compte administrateur utilise un mot de passe par défaut, ou des équipes marketing qui partagent un identifiant unique pour accéder au tableau de bord analytique.
Chaque accès doit être individuel et traçable. Un audit sérieux vérifie que le site impose une longueur minimale de mot de passe, bloque les tentatives après un nombre défini d’échecs, et journalise les connexions avec horodatage et adresse IP. Sans ces contrôles, la détection d’une intrusion devient impossible après coup.
Murs de traceurs et dark patterns : un piège réglementaire récent
Les « cookie walls » (accès conditionné à l’acceptation des traceurs) constituent un sujet que les guides de sécurité généralistes n’abordent pas. La CNIL précise qu’un tel dispositif n’est pas automatiquement interdit, mais que le consentement doit rester libre, éclairé et présenté avec des choix équilibrés.
En pratique, un bouton « Accepter » en couleur vive et un lien « Refuser » en gris clair au bas de la page ne satisfont pas cette exigence. Un test de conformité doit évaluer le ratio visuel entre les options, la facilité de navigation vers le refus, et l’absence de conséquence punitive (redirection, contenu masqué) en cas de non-acceptation.
Ce contrôle dépasse le périmètre technique habituel, mais il relève directement de la protection des données en ligne. Un site techniquement sûr qui exerce une pression disproportionnée sur le consentement de ses visiteurs s’expose aux mêmes sanctions qu’un site mal sécurisé.
La sécurité d’un site web ne se résume pas à un score affiché par un scanner. Elle se mesure sur trois axes simultanés : la robustesse technique, la conformité du traitement des données personnelles et la rigueur des politiques d’accès internes. Négliger un seul de ces axes revient à laisser une porte ouverte, quel que soit le cadenas posé sur les deux autres.
