Sécurité web avec nginx : fermer les fuites d'informations

Abidjan, jeudi soir. Akwaba Market, la boutique en ligne de pagnes wax et d'artisanat de Madame Koné, à Treichville, ouvre samedi. Hier soir, un client développeur a prévenu en privé : une adresse de produit cassée affiche une page pleine de code avec le mot de passe de la base de données, un dossier de sauvegardes ouvert à tous livre les noms et les téléphones des clients, et le site annonce son logiciel et sa version à qui veut l'entendre. Vous regardez d'abord la boutique comme un inconnu la voit, avec curl et les outils de développement du navigateur, et vous notez ce qu'elle laisse échapper. Puis vous fermez les fuites une à une, par la configuration : nginx cesse d'annoncer sa version et retire l'en-tête de l'application ; le mode DEBUG passe à false, et la trace des erreurs part au journal, retrouvable par une référence ; le mot de passe divulgué est changé dans la base et dans l'application, dans le bon ordre, et le fichier qui le garde n'est plus lisible par tous ; les sauvegardes des clients quittent la racine du site, et nginx refuse désormais tout fichier caché, dépôt git compris. Vous vérifiez chaque correction comme un visiteur, vous lisez dans le journal les robots qui ont déjà frappé à la porte, et vous rédigez l'état de la surface d'attaque, avant et après. Premier atelier de la série sécurité web, sur la catégorie A02:2025 du Top 10 de l'OWASP : la mauvaise configuration. Tout se passe sur votre propre sandbox, une boutique fictive qui vous appartient le temps du lab.