Usage de cette checklist
Cette checklist est conçue pour les audits de sécurité de sites web de PME, les audits pré-lancement, et les révisions annuelles de posture de sécurité. Elle ne remplace pas un pentest professionnel pour les sites à fort enjeu.
Cette checklist est conçue pour les audits de sécurité de sites web de PME, les audits pré-lancement, et les révisions annuelles de posture de sécurité. Elle ne remplace pas un pentest professionnel pour les sites à fort enjeu.
1. SSL / TLS
- Certificat SSL valide et non expiré
- Expiration à plus de 30 jours (alerte si < 30j)
- TLS 1.2 minimum, TLS 1.3 supporté
- TLS 1.0 et 1.1 désactivés (protocoles obsolètes)
- Redirections HTTP → HTTPS opérationnelles sur tous les sous-domaines
- HSTS (Strict-Transport-Security) activé avec
max-age≥ 1 an - Chaîne de certification complète et correcte
- Pas de mixed content (ressources HTTP sur pages HTTPS)
# Tester la configuration TLS
openssl s_client -connect votredomaine.com:443 -tls1
# Vérifier la date d'expiration
echo | openssl s_client -connect votredomaine.com:443 2>/dev/null \
| openssl x509 -noout -dates
# Tester HSTS
curl -sI https://votredomaine.com | grep -i strict2. En-têtes HTTP de sécurité
Les en-têtes HTTP de sécurité protègent contre les attaques XSS, clickjacking, et injection de contenu. Vérifiez leur présence avec curl ou un outil dédié :
Strict-Transport-Security— force HTTPSContent-Security-Policy— contrôle les sources de contenu autoriséesX-Frame-Options: DENY— protège contre le clickjackingX-Content-Type-Options: nosniff— empêche le MIME sniffingReferrer-Policy— contrôle les informations de référentPermissions-Policy— restreint l'accès aux APIs navigateur (caméra, géoloc...)
# Vérifier tous les en-têtes de sécurité
curl -sI https://votredomaine.com | grep -iE "strict|content-security|x-frame|x-content|referrer|permissions"
CSP : à configurer avec précaution
Une Content-Security-Policy mal configurée peut bloquer des ressources légitimes et casser le site. Commencez en mode report-only (
Une Content-Security-Policy mal configurée peut bloquer des ressources légitimes et casser le site. Commencez en mode report-only (
Content-Security-Policy-Report-Only) pour identifier les violations avant d'appliquer la politique.
3. Authentification email
- Enregistrement SPF présent et syntaxiquement correct
- SPF couvre tous les serveurs d'envoi légitimes
- DKIM configuré pour le domaine principal et les sous-domaines d'envoi
- DMARC présent avec politique
p=quarantineoup=reject - Tag RUA configuré pour recevoir les rapports agrégés
- Absence d'enregistrement SPF avec
+all(autorise tout le monde) - Enregistrement MX valide et pointant vers les bons serveurs
4. Infrastructure DNS
- Au moins 2 serveurs DNS (redondance)
- DNSSEC activé pour les domaines critiques
- Aucun enregistrement CNAME pointant vers une ressource externe expirée (risk de subdomain takeover)
- Transfert de zone DNS désactivé pour les IP non autorisées
- Date d'expiration du domaine > 60 jours
- Renouvellement automatique activé chez le registrar
- 2FA activé sur le compte registrar
5. Ports exposés
Seuls les ports nécessaires au fonctionnement du service doivent être accessibles depuis Internet. Chaque port ouvert est une surface d'attaque potentielle.
- Port 22 (SSH) — restreindre par IP ou désactiver l'accès public si possible
- Ports 80/443 — standard, mais vérifier les versions de serveur (bannières)
- Ports de base de données (3306 MySQL, 5432 PostgreSQL, 27017 MongoDB) — jamais accessibles depuis Internet
- Port 3389 (RDP) — jamais exposé directement sur Internet
- Panneau d'administration (cPanel, Plesk, phpMyAdmin) — accès restreint par IP
# Scan de ports basique (légal uniquement sur vos propres serveurs)
nmap -sV -p 1-1000 votredomaine.com
# Via nmap avec détection de version
nmap -sV --version-intensity 5 votredomaine.com6. Vulnérabilités CVE connues
Les CVE (Common Vulnerabilities and Exposures) sont des vulnérabilités documentées dans les logiciels. Vérifier régulièrement si vos composants sont affectés est essentiel.
- Version du serveur web (nginx, Apache) — vérifier le changelog CVE
- Version PHP, Node.js, Python — à jour selon les branches supportées
- CMS et plugins (WordPress, Drupal...) — versions à jour
- Bibliothèques et dépendances — audit via
npm audit,pip-audit, Composer - Bannières serveur désactivées (ne pas exposer les versions)
7. Contrôle des accès
- Pages d'administration protégées par 2FA
- Pas d'identifiants par défaut (admin/admin, root/root...)
- Politique de mot de passe forte (minimum 12 caractères)
- Sessions avec expiration automatique
- Logs de connexion actifs et monitored
- Principe du moindre privilège respecté
- Comptes de test ou de développement supprimés en production
8. Monitoring et réponse aux incidents
- Monitoring de disponibilité (uptime) avec alertes
- Monitoring SSL — alerte avant expiration du certificat
- Monitoring DNS — alerte sur tout changement d'enregistrement
- Logs applicatifs et serveur centralisés
- Sauvegardes testées et stockées hors site
- Plan de réponse aux incidents documenté
- Contact sécurité défini (qui appeler en cas d'incident ?)
Automatiser le monitoring
Plutôt que de passer cette checklist manuellement chaque mois, un outil comme Wezea automatise les vérifications SSL, email (SPF/DKIM/DMARC), ports exposés, CVE et blacklists — et vous alerte dès qu'un problème est détecté.
Plutôt que de passer cette checklist manuellement chaque mois, un outil comme Wezea automatise les vérifications SSL, email (SPF/DKIM/DMARC), ports exposés, CVE et blacklists — et vous alerte dès qu'un problème est détecté.
Lancez un audit automatique de votre domaine maintenant :
→ Auditer mon site gratuitement