Checklist sécurité avant production : 25 points

Mettre un site ou une application en production sans vérification de sécurité, c'est ouvrir une boutique sans fermer la porte à clé. Cette checklist de 25 points couvre les 5 dimensions critiques à vérifier avant tout déploiement en production.

Chaque point est actionnable et vérifiable en quelques minutes. Pour un guide plus progressif, consultez d'abord notre article sécuriser son site en 10 étapes.

Infrastructure (5 points)

1. HTTPS forcé avec certificat valide

• [ ] Certificat SSL/TLS valide (non expiré, signé par une CA reconnue)
• [ ] Redirection automatique HTTP → HTTPS (code 301)
• [ ] HSTS activé : Strict-Transport-Security: max-age=31536000; includeSubDomains
• [ ] Pas de contenu mixte (ressources HTTP sur page HTTPS)

Vérification rapide : curl -I http://votredomaine.com doit retourner un 301 vers HTTPS.

2. Configuration TLS robuste

• [ ] TLS 1.2 minimum (TLS 1.3 recommandé)
• [ ] SSLv3 et TLS 1.0/1.1 désactivés
• [ ] Suites de chiffrement faibles désactivées (RC4, DES, 3DES)
• [ ] Certificate Transparency activé (pour les certificats OV/EV)

Outil : ssllabs.com/ssltest — visez un score A ou A+.

3. Headers de sécurité configurés

• [ ] X-Frame-Options: SAMEORIGIN (protection clickjacking)
• [ ] X-Content-Type-Options: nosniff (protection MIME sniffing)
• [ ] Content-Security-Policy définie et testée
• [ ] Referrer-Policy: strict-origin-when-cross-origin
• [ ] Permissions-Policy configurée (désactiver les APIs non utilisées)

Consultez notre guide complet : Headers HTTP de sécurité.

4. Ports et services exposés

• [ ] Seuls les ports nécessaires sont ouverts (80, 443 minimum)
• [ ] SSH non exposé sur le port 22 public (ou accès restreint par IP)
• [ ] Interfaces d'administration (phpMyAdmin, Adminer...) non accessibles publiquement
• [ ] Pas de service de debug exposé (Xdebug, Node inspector...)

Vérification : Lancez un scan de ports ou utilisez WarDek pour détecter les services exposés.

5. Pare-feu applicatif et protection DDoS

• [ ] Pare-feu applicatif (WAF) en place ou Cloudflare activé
• [ ] Rate limiting configuré sur les endpoints sensibles (login, API, formulaires)
• [ ] Protection DDoS basique activée (Cloudflare free plan suffit pour démarrer)
• [ ] IP de management restreintes si applicable

Application (5 points)

6. Gestion des erreurs sécurisée

• [ ] Pas de stack traces exposées en production (messages d'erreur génériques côté client)
• [ ] Pas de chemins absolus du serveur dans les messages d'erreur
• [ ] Erreurs loguées côté serveur avec contexte complet
• [ ] Mode debug désactivé en production (APP_ENV=production, DEBUG=false)

7. Validation des entrées utilisateur

• [ ] Toutes les entrées utilisateur sont validées côté serveur (pas seulement côté client)
• [ ] Validation du type, format, longueur et contenu de chaque champ
• [ ] Requêtes SQL préparées ou ORM utilisé (pas de concaténation de chaînes SQL)
• [ ] Sortie HTML échappée pour prévenir le XSS

Pour les attaques XSS en détail, consultez notre guide : Protection XSS.

8. Gestion des dépendances

• [ ] Toutes les dépendances sont à jour (npm audit, composer audit, pip-audit...)
• [ ] Aucune dépendance avec une CVE critique non corrigée
• [ ] Lock files commitées dans le dépôt (package-lock.json, composer.lock)
• [ ] Dépendances de développement absentes du build de production

9. Sécurité des fichiers et répertoires

• [ ] Directory listing désactivé
• [ ] Fichiers sensibles non accessibles (.env, .git, configuration, logs)
• [ ] Permissions fichiers correctes (pas de 777 sur les répertoires)
• [ ] Upload de fichiers restreint par type MIME et taille maximale

10. Variables d'environnement et secrets

• [ ] Aucun secret en dur dans le code (clés API, mots de passe, tokens)
• [ ] Fichier .env absent du dépôt git (présent dans .gitignore)
• [ ] Variables d'environnement configurées dans l'environnement d'exécution
• [ ] Rotation des secrets effectuée si le projet était dans un dépôt public

Authentification (5 points)

11. Politique de mots de passe

• [ ] Longueur minimale de 12 caractères (16 recommandé)
• [ ] Vérification contre les listes de mots de passe compromis (HIBP API)
• [ ] Pas de contraintes arbitraires (interdire les espaces, limiter les caractères spéciaux)
• [ ] Pas de rotation forcée périodique sans compromission (contre-productif selon NIST)

12. Authentification multi-facteurs

• [ ] MFA disponible pour les utilisateurs
• [ ] MFA obligatoire pour les comptes administrateurs
• [ ] Recovery codes sécurisés fournis lors de l'activation du MFA
• [ ] MFA résistant au phishing (clés de sécurité FIDO2 pour les accès critiques)

13. Gestion des sessions

• [ ] ID de session aléatoire et suffisamment long (128 bits minimum)
• [ ] Régénération de l'ID de session après login
• [ ] Expiration des sessions inactives configurée
• [ ] Déconnexion invalidant la session côté serveur (pas seulement suppression du cookie client)

14. Protection contre la force brute

• [ ] Limitation des tentatives de connexion (verrouillage temporaire ou CAPTCHA)
• [ ] Délai progressif après plusieurs échecs
• [ ] Alertes sur les tentatives de connexion suspectes (géolocalisation anormale, volume élevé)
• [ ] Tokens CSRF sur tous les formulaires de connexion et actions sensibles

15. Gestion des comptes

• [ ] Comptes de test ou de démonstration supprimés avant production
• [ ] Mots de passe par défaut changés (admin/admin, root/root...)
• [ ] Principe de moindre privilège appliqué (chaque compte a uniquement les permissions nécessaires)
• [ ] Procédure de désactivation rapide des comptes compromis documentée

Données (5 points)

16. Chiffrement des données sensibles

• [ ] Données sensibles chiffrées au repos (AES-256 minimum)
• [ ] Mots de passe hachés avec un algorithme adapté (bcrypt, Argon2, scrypt)
• [ ] Clés de chiffrement stockées séparément des données chiffrées
• [ ] Données de paiement : conformité PCI-DSS ou délégation totale à Stripe/Adyen

17. Minimisation et rétention des données

• [ ] Seules les données strictement nécessaires sont collectées
• [ ] Durées de conservation définies et automatiquement appliquées
• [ ] Procédure de suppression des comptes (et des données associées) documentée
• [ ] Données de test anonymisées ou fictives (jamais de données de production en dev)

18. Sauvegardes

• [ ] Sauvegardes automatiques configurées et testées
• [ ] Copies hors site (règle 3-2-1)
• [ ] Sauvegardes chiffrées si elles contiennent des données sensibles
• [ ] Procédure de restauration documentée et testée

19. Conformité RGPD (si données personnelles)

• [ ] Politique de confidentialité à jour et accessible
• [ ] Bannière de cookies conforme (si applicable)
• [ ] Registre des traitements mis à jour — voir notre guide
• [ ] Contrats de sous-traitance (DPA) signés avec tous les prestataires concernés

20. Transferts et intégrations tiers

• [ ] Liste complète des services tiers ayant accès aux données (analytiques, CRM, emailing...)
• [ ] Mécanismes de transfert hors UE documentés (DPF, CCT, décision d'adéquation)
• [ ] Webhooks et callbacks sécurisés (validation des signatures)
• [ ] APIs tierces accessibles uniquement avec des clés à droits limités

Monitoring (5 points)

21. Logs d'accès et d'erreurs

• [ ] Logs centralisés et conservés (minimum 90 jours recommandé)
• [ ] Logs incluant : timestamp, IP, user-agent, action, résultat
• [ ] Pas de données sensibles dans les logs (mots de passe, numéros de carte, tokens)
• [ ] Accès aux logs restreint aux équipes autorisées

22. Alertes de sécurité

• [ ] Alertes sur les tentatives de connexion suspectes (volume élevé, IPs blacklistées)
• [ ] Alertes sur les erreurs 4xx et 5xx anormales
• [ ] Alertes sur les modifications de fichiers critiques (si applicable)
• [ ] Notification immédiate en cas de violation de données (procédure documentée)

23. Monitoring de disponibilité

• [ ] Monitoring de disponibilité configuré (alerte si site inaccessible)
• [ ] Monitoring du certificat SSL (alerte avant expiration)
• [ ] Health check endpoint disponible (/api/health ou équivalent)
• [ ] Contacts d'astreinte définis pour les incidents critiques

24. Plan de réponse aux incidents

• [ ] Procédure documentée pour les incidents de sécurité
• [ ] Contacts des prestataires critiques à jour (hébergeur, registrar, CDN)
• [ ] Procédure de notification CNIL sous 72h en cas de violation de données personnelles
• [ ] Exercice de simulation d'incident réalisé (ou planifié)

25. Revue post-déploiement

• [ ] Scan de sécurité automatisé après chaque déploiement en production
• [ ] Test de régression des fonctionnalités de sécurité (authentification, accès aux données)
• [ ] Revue des nouvelles dépendances introduites
• [ ] Documentation des changements effectués et des risques acceptés

Utiliser WarDek pour automatiser cette checklist

Certains de ces 25 points peuvent être vérifiés manuellement en quelques minutes. D'autres nécessitent des outils spécialisés ou une expertise technique.

WarDek scanne automatiquement les catégories Infrastructure, Headers, TLS, Cookies, et Services tiers — soit environ 40% de cette checklist — en 2 minutes. Le rapport généré est directement utilisable comme documentation de conformité.

Lancez un scan WarDek gratuit avant votre prochain déploiement.

Pour aller plus loin

• Sécuriser son site en 10 étapes : guide pratique pour démarrer rapidement
• Headers HTTP de sécurité : guide complet pour configurer HSTS, CSP, et les autres headers
• Protection XSS : comprendre et prévenir les attaques par injection