Sécurité d’une application web : la checklist minimale (OWASP)

Une application web n’a pas besoin d’une attaque sophistiquée pour être compromise. Un contrôle d’accès oublié sur une page, une clé d’API publiée par erreur, une dépendance jamais mise à jour ou une sauvegarde jamais restaurée suffisent. Ces failles sont connues, documentées, et se préviennent avec une liste de contrôles courte.

Ce guide part de la liste de référence, l’OWASP Top 10 dans son édition 2025, puis la traduit en une checklist minimale à vérifier avant chaque mise en ligne, complétée par les recommandations de l’ANSSI et de la CNIL. Ce sont les réflexes acquis pendant mon cursus cybersécurité chez Guardia, que j’entretiens sur TryHackMe (sécurité web OWASP, réseaux, cryptographie) et que j’applique sur ce site comme sur Docalio.

L’OWASP Top 10 2025 : les 10 risques à connaître

L’OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui travaille à améliorer la sécurité des logiciels. Son Top 10 est un document de sensibilisation qui classe les risques les plus critiques des applications web. L’édition en vigueur, l’OWASP Top 10:2025, a été présentée en novembre 2025 et remplace celle de 2021.

Ce qui change par rapport à 2021, d’après l’introduction de l’édition 2025 : le contrôle d’accès reste premier, la mauvaise configuration passe de la 5e à la 2e place, deux catégories apparaissent (A03 et A10), et l’authentification comme la journalisation changent de nom.

Contrôle d’accès : le premier chantier, et le plus sous-estimé

Le principe posé par l’OWASP tient en une phrase : « sauf pour les ressources publiques, refuser par défaut ». Trois règles en découlent.

• Vérifier côté serveur, à chaque requête. Masquer un bouton dans l’interface ne protège rien : la requête peut être envoyée directement.
• Vérifier la propriété de chaque enregistrement. Exemple type : la facture /factures/1042 s’affiche, l’utilisateur essaie /factures/1043. Si l’application ne vérifie pas que cette facture lui appartient, il lit celle d’un autre client.
• Donner le moindre privilège. La CNIL recommande de définir des profils d’habilitation, de retirer les droits dès qu’ils ne sont plus justifiés et de les revoir chaque année.

Sur Docalio, un portail client B2B, elles se traduisent par des données isolées par organisation, un stockage privé des documents et des liens d’accès temporaires.

Côté technique, une base PostgreSQL permet d’écrire l’isolement dans la base elle-même. Supabase, par exemple, documente la sécurité au niveau des lignes (RLS) : une fois activée sur une table, une requête envoyée avec la clé publique n’accède qu’aux lignes autorisées par des règles explicites.

Authentification : ce que recommandent la CNIL, l’ANSSI et l’OWASP

• Ne stocker que l’empreinte des mots de passe, calculée avec une fonction conçue pour cet usage et un sel, jamais avec MD5 ou SHA-1 (CNIL, fiche authentification).
• Exiger des mots de passe robustes. La CNIL retient par défaut une entropie de 80 bits, par exemple 12 caractères mêlant majuscules, minuscules, chiffres et caractères spéciaux. L’OWASP conseille aussi de refuser les mots de passe présents dans les listes de fuites connues.
• Limiter les tentatives de connexion, en bloquant le compte temporairement ou en ralentissant les essais.
• Proposer l’authentification multifacteur, au moins pour les administrateurs et les accès depuis l’extérieur. L’ANSSI y consacre ses recommandations relatives à l’authentification multifacteur et aux mots de passe.
• Gérer les sessions côté serveur : nouvel identifiant après la connexion, jamais dans l’adresse, invalidé à la déconnexion et après inactivité (OWASP A07).
• Ne pas révéler si un compte existe lors de l’inscription ou de la réinitialisation du mot de passe, comme le demande la CNIL dans sa fiche sur la sécurité des sites web.

Dans une première version, mieux vaut s’appuyer sur un service d’authentification éprouvé que tout réécrire soi-même, puis vérifier ces points un à un dans sa configuration.

Injection et XSS : ne jamais mélanger données et commandes

L’OWASP résume la prévention en une règle : garder les données séparées des commandes et des requêtes. En pratique :

• utiliser des requêtes paramétrées, jamais de texte saisi collé dans une requête SQL ;
• valider les entrées côté serveur, en listant ce qui est autorisé plutôt que ce qui est interdit ;
• échapper les caractères spéciaux selon l’endroit où la donnée est réutilisée ;
• ajouter une politique de sécurité du contenu (CSP), seconde barrière contre le XSS.

Le XSS fait partie de la catégorie Injection : un script injecté dans une page s’exécute chez vos utilisateurs, avec leurs droits. La conception compte autant que le code (OWASP A06) : pour chaque parcours sensible, écrivez à côté des cas d’usage les « cas d’abus », ce qu’un utilisateur malveillant essaierait de faire.

En-têtes de sécurité : ce que j’applique sur ce site

Un serveur peut demander au navigateur d’activer des protections par de simples en-têtes HTTP. L’ANSSI y consacre un guide, « Maîtriser les standards de sécurité côté navigateur », et l’OWASP range leur absence dans la mauvaise configuration (A02). Voici les principaux en-têtes que renvoie ce site, statique et sans dépendance :

Une précision honnête : les styles en ligne restent autorisés (style-src 'self' 'unsafe-inline'). C’est un compromis assumé, car le risque principal, l’exécution de scripts injectés, est fermé. Le guide CSP de MDN rappelle que la CSP sert d’abord de défense contre le XSS et contre le détournement de clic ; la page Strict-Transport-Security détaille HSTS.

Pour vérifier votre propre site, la commande curl -sI https://votre-site.fr affiche les en-têtes renvoyés, et l’HTTP Observatory de Mozilla les analyse et propose des corrections. Côté cookies, la CNIL demande d’activer les options HttpOnly et Secure sur tous les cookies.

Secrets et dépendances : surveiller le code que vous n’avez pas écrit

Chaque dépendance ajoutée est du code que vous n’avez pas écrit, mais dont vous répondez. La nouvelle catégorie A03 de l’OWASP recommande de tenir l’inventaire des dépendances, de supprimer celles qui ne servent plus, de ne les obtenir que depuis des sources officielles et de surveiller les vulnérabilités publiées (CVE). La CNIL le dit plus simplement dans sa fiche sur les sites web : limiter le nombre de composants, en assurer la veille et les mettre à jour. Ce site pousse la logique au bout : il ne repose sur aucune dépendance npm, donc sur aucune bibliothèque tierce à surveiller.

Pour les secrets (clés d’API, accès à la base de données, secrets de webhooks) :

• jamais dans le code source ni dans le dépôt, mais dans des variables d’environnement ;
• jamais dans le code envoyé au navigateur : chez Supabase, par exemple, la clé secrète contourne toutes les règles d’accès ;
• un renouvellement en cas de doute : Stripe recommande de changer les secrets de webhook régulièrement, ou dès qu’une fuite est suspectée.

Sauvegardes, journaux et incidents : prévoir le jour où ça casse

Une sauvegarde jamais restaurée n’est qu’une hypothèse. Dans ses fondamentaux de la sauvegarde, l’ANSSI recommande la règle « 3-2-1 » : trois copies des données (la production et deux sauvegardes) sur deux supports différents, dont une hors ligne. Elle demande aussi de tester régulièrement les sauvegardes et d’écrire une procédure de restauration. La CNIL va dans le même sens.

Les journaux permettent de comprendre ce qui s’est passé. Pour les traces applicatives, la CNIL recommande d’enregistrer les créations, consultations, partages, modifications et suppressions, avec l’auteur et la date, et de conserver ces événements sur une période glissante de six mois à un an. L’OWASP y ajoute l’alerte (A09) : un journal que personne ne lit ne détecte rien.

Prévoyez enfin l’échec (A10). Quand une opération échoue en cours de route, l’application doit tout annuler et revenir à un état sûr, ce que l’OWASP appelle « échouer de façon fermée », sans afficher de détail technique à l’utilisateur. Et si une violation de données personnelles présente un risque pour les personnes, le RGPD impose de la notifier à la CNIL dans les meilleurs délais, si possible sous 72 heures ; toute violation doit en outre être documentée en interne.

La checklist minimale avant la mise en ligne

Pour une application qui traite des données personnelles, l’article 32 du RGPD impose une sécurité adaptée au risque, et le guide de la sécurité des données personnelles de la CNIL (édition 2024, 25 fiches) en détaille les mesures. Voici le minimum que je vérifie avant une mise en ligne.

Accès et comptes

• Chaque page et chaque API vérifie les droits côté serveur
• Chaque enregistrement a un propriétaire, vérifié à chaque lecture
• Comptes par défaut et comptes de test supprimés
• Interfaces d’administration réservées aux personnes habilitées

Authentification

• Mots de passe stockés sous forme d’empreinte salée, avec une fonction dédiée
• Tentatives de connexion limitées
• Authentification multifacteur pour les administrateurs
• Messages neutres à l’inscription et à la réinitialisation

Code et données

• Requêtes paramétrées partout
• Aucun secret dans le dépôt ni dans le navigateur
• Dépendances inventoriées, à jour, sans composant inutile
• Aucune donnée personnelle dans les adresses (URL)

Serveur et navigateur

• HTTPS partout, HSTS activé
• CSP sans script en ligne, frame-ancestors défini
• Cookies en HttpOnly et Secure
• Messages d’erreur sans détail technique

Exploitation

• Sauvegardes automatiques, dont une hors ligne, et restauration testée
• Journaux des opérations sensibles, conservés et relus
• Procédure écrite en cas d’incident, notification à la CNIL comprise

En résumé : la sécurité se décide à la conception

La sécurité d’une application web ne s’ajoute pas à la fin, pendant la recette : elle se décide quand on dessine les rôles, les données et les parcours. Commencez par le contrôle d’accès, appuyez-vous sur des briques éprouvées pour l’authentification et le paiement, verrouillez le navigateur avec quelques en-têtes, puis faites des sauvegardes et des journaux une routine. Et relisez cette liste à chaque nouvelle fonctionnalité, pas seulement au lancement.

Vous lancez un SaaS ou un espace client et voulez un socle de sécurité solide dès la première version ? C’est le principe de mon accompagnement en création de SaaS et d’application web. Pour la méthode produit, voir aussi créer un SaaS, de l’idée au MVP.