Comment vérifier la sécurité de votre site web : ce qu'un contrôle passif peut vous dire, et ce qu'il ne peut pas

« Mon site est-il sécurisé ? » n'appelle pas de réponse par oui ou par non, mais la question a un premier pas utile : vérifier les éléments de votre sécurité que n'importe qui sur Internet peut déjà voir. Chaque navigateur qui visite votre site reçoit votre configuration HTTPS, votre certificat, vos en-têtes de réponse et vos cookies. S'ils sont mal configurés, vous facilitez les attaques sans aucune raison, et y remédier relève généralement d'un changement de réglages plutôt que d'une réécriture.

Ce guide passe en revue ce qu'il faut vérifier, comment le vérifier et, tout aussi important, ce qu'un contrôle de ce type ne peut pas vous dire.

Contrôles passifs et tests de sécurité

Un contrôle passif émet le même type de requêtes qu'un navigateur et lit les réponses. Il n'envoie jamais de charge d'attaque, ne soumet jamais de formulaire et n'essaie jamais de se connecter. On peut donc le lancer sans risque et à tout moment sur un site en production, et il repère efficacement les erreurs de configuration.

Un test d'intrusion, c'est autre chose : une personne qualifiée, avec votre autorisation, tente activement de s'introduire dans le site, en éprouvant les connexions, le traitement des saisies, le contrôle d'accès et la logique métier. Il révèle les vulnérabilités qu'un contrôle passif ne peut pas voir, et ne s'improvise pas sur un site en production.

Commencez par la couche passive. C'est rapide, et un site qui néglige les bases visibles a généralement d'autres problèmes.

Quoi vérifier, et à quoi ressemble une bonne configuration

1. Du HTTPS partout, avec une redirection permanente

Chaque page doit se charger en https://, et la saisie de l'adresse en http:// doit aboutir à une redirection 301 ou 308 vers la version HTTPS. Une redirection 302 fonctionne, mais elle n'est pas mémorisée, et un site qui sert encore des pages en HTTP simple permet à quiconque se trouve sur le même réseau de les lire ou de les modifier. Faites le test avec curl -I http://yourdomain.com/, puis examinez la ligne de statut et l'en-tête Location.

2. Un certificat valide qui se renouvelle tout seul

Le certificat doit être reconnu comme fiable, correspondre à votre domaine et ne pas être proche de son expiration. Un certificat expiré est presque toujours dû à une tâche de renouvellement qui s'est arrêtée sans bruit après un changement de serveur ou de DNS. Cliquez sur le cadenas dans votre navigateur pour voir l'émetteur et la date d'expiration, et assurez-vous que le renouvellement est automatisé.

3. Des en-têtes de sécurité aux valeurs sensées

Des en-têtes comme Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options et Referrer-Policy activent des protections intégrées aux navigateurs. Leurs valeurs comptent autant que leur présence : un max-age HSTS de 300 secondes hérité d'une phase de test ne protège presque rien, et une CSP contenant 'unsafe-inline' ou * dans script-src ne fait pas grand-chose contre les scripts injectés. Nos guides sur les en-têtes de sécurité et sur la Content-Security-Policy expliquent quelles valeurs sont sûres.

4. Les attributs des cookies

Les cookies de session et de connexion doivent être Secure (HTTPS uniquement), HttpOnly (invisibles pour JavaScript) et porter une valeur SameSite explicite. Dans le navigateur, ouvrez les outils de développement et regardez sous Application (Chrome, Edge) ou Stockage (Firefox) → Cookies. Le guide pour vérifier la sécurité des cookies détaille chaque attribut.

5. Une configuration CORS qui ne fait pas confiance à tout le monde

Les en-têtes Cross-Origin Resource Sharing indiquent aux navigateurs quels autres sites peuvent lire vos réponses. La configuration à risque est celle d'un serveur qui recopie n'importe quel Origin reçu dans Access-Control-Allow-Origin et envoie Access-Control-Allow-Credentials: true. N'importe quel site web peut alors lire des réponses obtenues avec les cookies de vos visiteurs. Autorisez plutôt des origines précises.

6. Aucun contenu mixte

Une page HTTPS qui charge des scripts, des feuilles de style ou des cadres en http:// comporte du contenu mixte actif, que les navigateurs modernes bloquent, ce qui casse souvent la page. Les images et les médias en HTTP simple constituent du contenu mixte passif : c'est moins dangereux, mais cela affaiblit tout de même le cadenas. Recherchez dans vos gabarits et votre base de données les URL http:// écrites en dur.

7. Ce que vous révélez aux attaquants

Des en-têtes comme Server: Apache/2.4.41 ou X-Powered-By: PHP/7.4 annoncent des versions exactes. Des source maps JavaScript publiques peuvent exposer votre code front-end d'origine. Ni l'un ni l'autre ne constitue une vulnérabilité en soi, mais tous deux font gagner du temps à un attaquant. Pensez aussi à publier un fichier /.well-known/security.txt comportant un champ Contact et une date Expires, afin que les personnes qui découvrent un problème sachent comment vous joindre.

Comment procède l'outil de vérification de la sécurité de Rudra

L'outil gratuit de vérification de la sécurité automatise la liste ci-dessus. Il envoie une requête normale à votre page et lit les en-têtes, les cookies qu'elle dépose (noms et attributs uniquement, jamais les valeurs) et le HTML. Il effectue ensuite un petit nombre fixe de requêtes supplémentaires en lecture seule : une connexion TLS pour le certificat, une requête vers http://yourdomain/ pour voir comment elle est redirigée, une requête portant une origine de test fictive (https://rudra-audit.invalid) pour observer la réaction de vos en-têtes CORS, et une courte liste blanche de fichiers bien connus tels que security.txt et robots.txt.

Chaque constat indique la valeur observée, ce à quoi ressemble une valeur acceptable et le degré de confiance du contrôle. Certains schémas, comme les gestionnaires onclick en ligne ou les scripts tiers sans Subresource Integrity, peuvent être anodins ou risqués selon le contexte : ils sont donc signalés avec un faible degré de confiance, pour que vous les examiniez, plutôt que présentés comme des problèmes avérés. Le rapport dresse aussi la liste des technologies et de la surface publique qu'il a pu observer, comme les formulaires de connexion et les URL d'API mentionnées dans la page, afin que vous sachiez ce qui est visible de l'extérieur.

Ce qu'un contrôle passif ne peut pas vous dire

C'est ici que l'on prête trop de sens à un bon score. Un contrôle passif, le nôtre compris, ne permet pas de :

• trouver les vulnérabilités de votre code, comme les injections SQL, le cross-site scripting ou un contrôle d'accès défaillant ;
• rechercher des versions connues pour être vulnérables dans votre CMS, vos extensions, vos bibliothèques ou votre serveur (sauf si un en-tête révèle par hasard une version) ;
• tester ce qui se trouve derrière une connexion, notamment les interfaces d'administration et les pages de compte ;
• tester le comportement des formulaires à l'envoi, notamment la protection CSRF et la limitation du nombre de requêtes ;
• détecter un logiciel malveillant, une défiguration du site ou un compte compromis ;
• examiner votre hébergement, vos sauvegardes, vos contrôles d'accès ni la liste des personnes qui détiennent les mots de passe administrateur.

Un résultat sans anomalie signifie que la configuration visible est en bon état. Cela ne veut pas dire que le site est sécurisé à tous égards, et aucune analyse automatisée ne peut le promettre.

Que faire au-delà de l'analyse

1. Maintenez vos logiciels à jour. Appliquez sans tarder les mises à jour du CMS, des extensions, des thèmes et des frameworks, et supprimez les extensions que vous n'utilisez pas.
2. Protégez les comptes administrateur. Utilisez des mots de passe uniques et l'authentification à deux facteurs pour chaque compte capable de modifier le site.
3. Conservez des sauvegardes testées. Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas un plan.
4. Surveillez les changements. Relancez le contrôle passif après chaque déploiement et chaque fois que vous ajoutez un script tiers.
5. Faites réaliser un test professionnel lorsque les enjeux le justifient. Si vous gérez des paiements, des données de santé ou des comptes, commandez un test d'intrusion à un testeur qualifié, avec un périmètre défini par écrit.

Pour le reste de la santé de votre site (vitesse, SEO, accessibilité et liens cassés), lancez un audit de site web complet sur la même page.