Comment auditer la sécurité de son site web soi-même

La majorité des propriétaires de sites web pensent que la sécurité est l'affaire des experts. C'est une erreur. Si vous savez utiliser un navigateur et suivre une checklist, vous pouvez réaliser un premier audit sérieux de votre site en moins d'une heure — et identifier des failles que même des développeurs expérimentés laissent passer.

Voici la méthode, étape par étape.

Étape 1 : Vérifier votre certificat SSL/TLS

Le cadenas dans la barre d'adresse ne suffit pas. Beaucoup de sites ont un certificat SSL valide mais utilisent des protocoles obsolètes (TLS 1.0 ou 1.1) qui sont vulnérables à des attaques comme BEAST ou POODLE.

Outil à utiliser : SSL Labs (ssllabs.com/ssltest)

Entrez votre domaine et attendez le rapport. Vous devez obtenir au minimum une note A. Voici ce que vous cherchez :

• Le protocole minimum doit être TLS 1.2, idéalement TLS 1.3
• Les suites cryptographiques faibles (RC4, DES, 3DES) doivent être désactivées
• Le certificat ne doit pas expirer dans moins de 30 jours
• La chaîne de certificats doit être complète (certificat intermédiaire inclus)

Une note B ou C signifie que vos visiteurs et leurs données sont exposés à des risques réels, même si le site "fonctionne normalement".

Étape 2 : Analyser vos headers HTTP de sécurité

Les headers HTTP sont des instructions envoyées par votre serveur aux navigateurs. Quand ils sont absents ou mal configurés, vous laissez la porte ouverte à des attaques XSS, au clickjacking, et à l'injection de contenu malveillant.

Outil à utiliser : SecurityHeaders.io

Les headers critiques à vérifier :

• Content-Security-Policy (CSP) : définit quelles sources de contenu (scripts, images, styles) sont autorisées. Sans CSP, un attaquant peut injecter des scripts arbitraires dans vos pages.
• Strict-Transport-Security (HSTS) : force le navigateur à toujours utiliser HTTPS. Sans lui, une attaque de type SSL stripping peut rediriger vos utilisateurs vers une version HTTP non chiffrée de votre site.
• X-Frame-Options : empêche votre site d'être intégré dans une iframe sur un autre domaine. Protège contre le clickjacking.
• X-Content-Type-Options : valeur nosniff obligatoire. Empêche le navigateur d'interpréter un fichier autrement que ce que votre serveur déclare.
• Referrer-Policy : contrôle les informations transmises lors de la navigation entre pages.
• Permissions-Policy : limite l'accès aux APIs sensibles du navigateur (caméra, micro, géolocalisation).

SecurityHeaders.io vous donne une note de F à A+. Visez A minimum. Chaque header manquant est listé avec une explication.

Étape 3 : Auditer vos enregistrements DNS

Votre DNS, c'est l'annuaire de votre domaine. Un DNS mal configuré peut permettre à des attaquants d'envoyer des emails en votre nom, de détourner vos sous-domaines, ou d'intercepter votre trafic.

Outil à utiliser : MXToolbox (mxtoolbox.com)

Les enregistrements à vérifier :

• SPF (Sender Policy Framework) : liste les serveurs autorisés à envoyer des emails depuis votre domaine. Sans SPF, n'importe qui peut usurper votre adresse email.
• DKIM (DomainKeys Identified Mail) : signature cryptographique ajoutée à vos emails. Permet au destinataire de vérifier qu'un email vient bien de vous.
• DMARC : politique qui dit aux serveurs de messagerie quoi faire quand un email échoue les vérifications SPF ou DKIM. Sans DMARC avec p=reject, vos emails frauduleux passent.

Dans MXToolbox, lancez le "Email Health" check sur votre domaine. Chaque alerte rouge est un problème à corriger.

Étape 4 : Scanner les ports ouverts

Chaque port ouvert sur votre serveur est une surface d'attaque potentielle. Si votre base de données MySQL écoute sur le port 3306 et est accessible depuis internet — c'est un problème grave.

Outil à utiliser : Shodan (shodan.io)

Cherchez votre adresse IP dans Shodan. Le service indexe automatiquement les serveurs exposés sur internet. Vous verrez :

• Quels ports sont ouverts et quels services tournent dessus
• Les versions des logiciels exposés (et si des CVE connues existent)
• Des informations de géolocalisation et d'infrastructure

Les ports qui ne devraient jamais être exposés publiquement : 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB), 22 (SSH, sauf usage intentionnel avec clés SSH uniquement).

Pour un scan plus détaillé, nmap en ligne de commande reste la référence — mais nécessite un accès à un terminal.

Étape 5 : Vérifier les vulnérabilités connues de votre stack

Si vous utilisez WordPress, Drupal, Joomla, ou n'importe quel CMS avec des plugins tiers, vous devez vérifier que tout est à jour et qu'aucune version installée n'a de CVE (Common Vulnerabilities and Exposures) connue.

Outils à utiliser :

• WPScan (pour WordPress) : scan automatique des plugins, thèmes et configurations vulnérables
• CVE Details (cvedetails.com) : base de données des vulnérabilités par logiciel et version
• Snyk : analyse vos dépendances open source

Pour WordPress spécifiquement, vérifiez dans votre tableau de bord admin que :

• Le core WordPress est à jour
• Tous les plugins actifs sont à jour
• Les plugins inactifs sont supprimés (pas juste désactivés)
• L'URL d'administration n'est pas /wp-admin (trop prévisible)
• xmlrpc.php est désactivé si vous n'en avez pas besoin

Étape 6 : Tester les fuites d'informations

Votre site révèle peut-être plus d'informations qu'il ne devrait sur votre infrastructure.

Vérifiez manuellement :

• Le header Server dans les réponses HTTP — il ne devrait pas exposer la version exacte d'Apache ou Nginx
• Le header X-Powered-By — ne devrait pas afficher PHP/8.1.2 ou similaire
• Les pages d'erreur — une erreur 500 ne devrait pas afficher une stack trace complète
• Le fichier robots.txt — ne doit pas lister des chemins sensibles comme /admin, /backup, /config
• Les fichiers .git exposés — testez votresite.com/.git/config. Si vous obtenez une réponse 200, votre code source est accessible publiquement.

Pour inspecter les headers HTTP, utilisez les outils de développement de votre navigateur (onglet Network > cliquez sur une requête > Headers) ou l'outil curl -I votresite.com en ligne de commande.

Étape 7 : Vérifier la réputation de votre domaine

Un site compromis finit souvent en liste noire chez Google, les antivirus, ou les filtres email. Vérifiez régulièrement :

• Google Safe Browsing : transparencyreport.google.com/safe-browsing/search
• VirusTotal : analysez votre URL, gratuit jusqu'à 4 requêtes par minute
• MXToolbox Blacklist Check : pour vérifier si votre IP est blacklistée par des filtres anti-spam

Récapitulatif de la checklist

Voici les 7 points à auditer dans l'ordre :

• SSL/TLS : note A sur SSL Labs, TLS 1.2 minimum
• Headers HTTP : CSP, HSTS, X-Frame-Options, X-Content-Type-Options configurés
• DNS email : SPF, DKIM, DMARC en place avec politique stricte
• Ports ouverts : bases de données non exposées, SSH sécurisé
• Mises à jour : CMS, plugins, dépendances tous à jour
• Fuites d'info : headers serveur masqués, pas de .git exposé
• Réputation : domaine non blacklisté sur Google et antivirus

Un audit complet de ce type prend environ 45 à 60 minutes la première fois. Ensuite, une vérification mensuelle de 15 minutes suffit pour maintenir un niveau de sécurité correct.

La sécurité n'est pas un état — c'est une pratique. Et cette pratique commence par savoir où regarder.