Bonnes pratiques et sécurité avancée

Vous avez maintenant une application où les identités sont vérifiées, les mots de passe correctement hachés et les accès contrôlés. C'est le nécessaire, et ce n'est pas le suffisant. Les incidents dont on lit le récit ne commencent presque jamais par « l'attaquant a cassé l'authentification ». Ils commencent par un point Actuator laissé ouvert, une clé d'API dans un dépôt public, une bibliothèque vieille de trois ans, ou une trace d'exception affichée en production qui indiquait le chemin complet du serveur.

Ces défauts ont un point commun : aucun n'est un défaut de code applicatif. Ce sont des défauts de configuration, d'exploitation, d'hygiène de dépendances. L'OWASP les classe d'ailleurs séparément — « mauvaise configuration de sécurité » et « composants vulnérables ou obsolètes » sont deux catégories distinctes de son classement des dix principaux risques.

Cette dernière leçon rassemble donc les éléments qui n'appartiennent à aucune des précédentes mais qui décident de la solidité réelle du système : les en-têtes que le navigateur doit recevoir, la façon d'imposer HTTPS sans provoquer de boucle de redirection, la limitation du débit, la journalisation utile — et celle qui crée elle-même la fuite —, la gestion des secrets et la surveillance des dépendances.