La checklist de sécurité que nous passons avant chaque mise en ligne

La plupart des sites ne sont pas compromis par des techniques inédites. Ils le sont par une dépendance obsolète, une interface d'administration laissée exposée, un envoi de fichiers qui n'a jamais validé ce qu'il recevait, ou des identifiants réutilisés ailleurs. Ce sont les vérifications peu spectaculaires qui interceptent la majorité des incidents réels, et c'est pourquoi nous les passons de la même façon à chaque fois.

Voici la checklist que nous déroulons avant qu'un site ne passe en production. Elle n'est pas exhaustive, et la réussir ne rend pas un site sûr : rien ne le fait. Elle ferme les portes que l'on trouve le plus souvent ouvertes.

Dépendances et chaîne d'approvisionnement

Chaque framework, extension et paquet est du code que vous n'avez pas écrit et qui s'exécute avec les privilèges de votre application. Les vulnérabilités connues dans des composants obsolètes figurent constamment parmi les causes les plus fréquentes de compromission, en grande partie parce que l'exploitation est automatisée : un scanner trouve la version, un script fait le reste.

• Auditez chaque dépendance au regard des avis de sécurité avant la mise en ligne, pas après
• Retirez les paquets qui ne servent plus : du code inutilisé reste une surface d'attaque
• Vérifiez que les extensions sont activement maintenues ; une extension abandonnée ne recevra pas de correctif
• Figez les versions pour qu'un déploiement ne tire pas silencieusement quelque chose de nouveau
• Mettez en place des alertes automatiques pour être informé sans vérification manuelle

Authentification et gestion des sessions

L'authentification est l'endroit où se logent les défaillances les plus coûteuses. Elle mérite d'être testée délibérément plutôt que présumée réglée par le framework.

• Appliquez une véritable politique de mots de passe et vérifiez les identifiants face aux listes de fuites connues
• Limitez le débit et bloquez après des échecs répétés
• Assurez-vous que les jetons de réinitialisation sont à usage unique, limités dans le temps et non devinables
• Régénérez l'identifiant de session à la connexion et lors d'un changement de privilège
• Positionnez Secure, HttpOnly et SameSite sur les cookies de session
• Proposez l'authentification multifacteur pour les comptes d'administration

Autorisation

L'authentification demande qui vous êtes. L'autorisation demande ce que vous avez le droit de toucher, et c'est la plus souvent défaillante des deux. Le contrôle d'accès défaillant occupe la première place du Top 10 de l'OWASP dans les révisions récentes, et il apparaît rarement en usage normal parce que les utilisateurs ordinaires n'essaient jamais.

• Vérifiez l'autorisation côté serveur pour chaque requête, pas seulement dans l'interface
• Vérifiez la propriété de l'objet, pas seulement que l'utilisateur est connecté
• Refusez par défaut et accordez explicitement
• Testez chaque rôle contre les points d'entrée destinés à d'autres rôles

Traitement des entrées et envoi de fichiers

Tout ce qu'un utilisateur envoie est non fiable, y compris les valeurs produites par votre propre interface. Les envois de fichiers méritent une attention particulière, car ils combinent contenu non fiable et système de fichiers.

• Validez côté serveur contre une liste d'autorisation ; la validation navigateur est un confort, pas un contrôle
• Utilisez partout des requêtes paramétrées : la concaténation de chaînes dans du SQL reste l'erreur classique
• Encodez la sortie selon le contexte où elle atterrit pour prévenir le cross-site scripting
• Vérifiez le type des fichiers envoyés par leur contenu plutôt que par leur extension
• Stockez les fichiers hors de la racine web, ou servez-les depuis un domaine qui ne peut exécuter de code
• Plafonnez la taille des fichiers et le débit d'envoi

Configuration et surfaces exposées

Une large part des constats d'une évaluation typique relève de la configuration plutôt que du code : des réglages acceptables en développement et jamais adaptés à la production.

• Désactivez les modes debug et les pages d'erreur détaillées en production
• Supprimez les comptes par défaut et le contenu d'exemple
• Assurez-vous que les répertoires .git, les sauvegardes, les fichiers d'environnement et les exports de base ne sont pas accessibles depuis le web
• Restreignez les interfaces d'administration par réseau ou par authentification supplémentaire quand c'est possible
• Positionnez les en-têtes de sécurité : Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy
• Vérifiez que TLS est correctement configuré et que HTTP redirige vers HTTPS

Journalisation, sauvegardes et reprise

Les questions qui suivent un incident sont toujours les mêmes : quand cela a-t-il commencé, jusqu'où sont-ils allés, et pouvons-nous revenir à un état sain connu ? Vous ne pouvez y répondre que si vous avez préparé en amont.

• Journalisez les événements d'authentification, les changements de privilèges et les actions d'administration
• Conservez les journaux là où un attaquant présent sur le serveur web ne peut pas simplement les supprimer
• Effectuez des sauvegardes planifiées et conservez au moins une copie hors site
• Réalisez réellement une restauration de test : une sauvegarde non testée est un espoir, pas un contrôle
• Notez qui contacter et quoi faire en premier, avant d'en avoir besoin

Ce que cette checklist ne fait pas

Elle ne couvre pas les failles de logique métier, propres à votre application et qui demandent généralement un humain pour être trouvées. Elle ne traite pas l'infrastructure au-delà de la configuration de base. Et c'est un exercice daté : un site conforme aujourd'hui dérivera à mesure que les dépendances vieillissent et que des fonctionnalités s'ajoutent.

Traitez-la comme le socle à valider avant la mise en ligne, puis continuez de le valider selon un calendrier. Si vous voulez un examen plus approfondi d'une application précise, c'est à cela que servent une évaluation de vulnérabilités ou un test d'intrusion.