Sécurité des applications web : les bonnes pratiques pour protéger votre application

Améliorer la sécurité d’une application web, c’est réduire les chances qu’un attaquant lise, modifie ou détruise des données qu’il ne devrait pas voir. En pratique, cela repose sur quelques habitudes : contrôler finement les droits d’accès, chiffrer les échanges, mettre à jour les dépendances, tester l’application comme le ferait un pirate et surveiller ce qui s’y passe. La référence commune pour prioriser ces chantiers est le Top 10 de l’OWASP, dont l’édition 2025 place le contrôle d’accès défaillant en tête.

Une application web est accessible à toute personne disposant d’une connexion internet : c’est sa force, et c’est aussi ce qui l’expose. Ce guide s’adresse aux dirigeants et chefs de projet qui font développer une application (espace client, outil métier, plateforme de réservation) et veulent savoir quoi exiger de leurs développeurs. On y reprend les risques les plus fréquents, les bonnes pratiques à appliquer tout au long du projet et les obligations légales à connaître.

• Qu’est-ce que la sécurité des applications web ?
• Quels sont les risques les plus courants ?
• Quelles bonnes pratiques appliquer ?
• Comment tester la sécurité de son application ?
• Quelles obligations légales en France ?
• Quelles erreurs éviter ?
• Questions fréquentes
• Sources

Qu’est-ce que la sécurité des applications web ?

La sécurité des applications web regroupe les mesures qui permettent à une application de continuer à fonctionner correctement, et de protéger les données qu’elle manipule, même lorsqu’elle est attaquée. Tout logiciel contient des défauts : l’objectif n’est pas d’atteindre une perfection impossible, mais de repérer les failles avant les attaquants et de limiter les dégâts si l’une d’elles est exploitée.

Elle ne se limite pas au code. Une application sûre dépend aussi de sa conception (qui a le droit de faire quoi), de son hébergement (serveur, base de données, sauvegardes), des bibliothèques tierces qu’elle embarque et des personnes qui l’administrent. C’est pourquoi les bonnes pratiques recommandent d’intégrer la sécurité à chaque étape du cycle de développement plutôt que de la vérifier à la fin. Cette approche porte un nom, le DevSecOps.

À distinguer de la sécurité d’un site vitrine : un site WordPress sans espace membre expose surtout son back-office et ses extensions. Pour ce cas, notre article sur comment sécuriser un site web est plus adapté. Ici, on parle d’applications qui gèrent des comptes utilisateurs, des données métier ou des paiements.

Quels sont les risques les plus courants ?

L’OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui publie le classement de référence des risques pour les applications web. L’édition 2025 du Top 10 retient les catégories suivantes :

Rang	Catégorie OWASP 2025	Exemple concret
A01	Contrôle d’accès défaillant	Un client modifie l’identifiant dans l’URL et voit la facture d’un autre client
A02	Mauvaise configuration de sécurité	Mode debug laissé actif en production, interface d’administration exposée
A03	Défaillances de la chaîne d’approvisionnement logicielle	Une bibliothèque tierce compromise ou non maintenue
A04	Défaillances cryptographiques	Mots de passe stockés en clair ou avec un algorithme obsolète
A05	Injection	Injection SQL via un champ de recherche, script injecté dans un commentaire (XSS)
A06	Conception non sécurisée	Un parcours de réinitialisation de mot de passe contournable par construction
A07	Défaillances d’authentification	Aucune limite au nombre d’essais de connexion
A08	Défaillances d’intégrité des logiciels ou des données	Mise à jour installée sans vérifier son origine
A09	Défaillances de journalisation et d’alerte	Une intrusion découverte des semaines plus tard faute de logs
A10	Mauvaise gestion des conditions exceptionnelles	Une erreur non prévue qui affiche des informations internes ou laisse l’accès ouvert

Ce tableau sert de grille de lecture : si votre prestataire ne sait pas vous dire comment chacune de ces catégories est traitée dans votre application, c’est un signal à prendre au sérieux.

Quelles bonnes pratiques appliquer ?

1. Cartographier les points sensibles dès la conception

Toutes les parties d’une application ne présentent pas le même niveau de risque. Avant d’écrire du code, regardez votre application du point de vue d’un attaquant et classez ses modules :

1. les fonctions exposées à internet qui manipulent des données clients (inscription, connexion, paiement, formulaires) ;
2. les modules qui contiennent des informations internes à l’entreprise (tarifs, marges, données RH) ;
3. les modules qui n’ont accès à aucune donnée sensible.

Cette cartographie permet de concentrer l’effort (tests, revues de code, surveillance) là où une faille coûterait le plus cher. Elle se fait idéalement au moment de la rédaction du cahier des charges.

2. Contrôler les droits d’accès côté serveur

C’est le premier risque du classement OWASP. Chaque requête doit vérifier, côté serveur, que l’utilisateur connecté a bien le droit d’accéder à la ressource demandée. Masquer un bouton dans l’interface ne suffit pas : un attaquant peut appeler directement l’adresse ou l’API. Appliquez le principe du moindre privilège : chaque compte, y compris ceux de vos salariés, n’a accès qu’à ce dont il a besoin. Si des identifiants sont volés, l’attaquant reste limité aux droits de ce compte.

3. Chiffrer les échanges et protéger les mots de passe

Tout le trafic doit passer en HTTPS (protocole TLS). L’en-tête HTTP Strict-Transport-Security (HSTS) indique en plus au navigateur de ne jamais revenir en HTTP sur votre domaine. Côté stockage, les mots de passe ne doivent jamais être conservés en clair ni simplement chiffrés : la CNIL recommande de les transformer avec une fonction de hachage lente et salée, et cite notamment scrypt et Argon2. Les données particulièrement sensibles (santé, pièces d’identité) méritent un chiffrement en base.

4. Renforcer l’authentification

La recommandation de la CNIL sur les mots de passe (octobre 2022) raisonne en entropie plutôt qu’en règles fixes. Un exemple qu’elle donne : au moins 12 caractères mêlant majuscules, minuscules, chiffres et caractères spéciaux lorsque le mot de passe est le seul moyen d’authentification. Si l’application limite les tentatives (blocage temporaire après plusieurs échecs, par exemple), l’exigence peut être abaissée. Pour les comptes administrateurs, activez une double authentification.

5. Valider toutes les entrées

Tout ce qui vient de l’utilisateur (formulaires, paramètres d’URL, fichiers envoyés, appels d’API) doit être considéré comme potentiellement malveillant. Utilisez des requêtes préparées pour la base de données, échappez les contenus affichés dans les pages et limitez le type et la taille des fichiers acceptés. Les frameworks récents (Django, Laravel, Symfony) intègrent ces protections : encore faut-il ne pas les contourner.

6. Sécuriser les cookies et les sessions

Les cookies de session sont la clé d’entrée de vos utilisateurs. Quelques règles simples :

• n’y stockez jamais d’informations sensibles (mot de passe, coordonnées bancaires) ;
• activez les attributs Secure (envoi en HTTPS uniquement), HttpOnly (inaccessible au JavaScript) et SameSite (limite l’envoi depuis d’autres sites) ;
• donnez-leur une durée de vie raisonnable et invalidez la session à la déconnexion.

Les cookies de mesure d’audience ou publicitaires relèvent, eux, du consentement de l’utilisateur, conformément aux règles de la CNIL.

7. Mettre à jour le code et les dépendances

Une application moderne embarque des dizaines de bibliothèques tierces. Les attaquants utilisent des outils qui repèrent automatiquement les versions vulnérables. Tenez un inventaire des dépendances, activez les alertes de sécurité de votre gestionnaire de paquets ou de votre dépôt de code, et planifiez les mises à jour du framework, du langage et du serveur. Une application livrée puis jamais maintenue devient vulnérable avec le temps, même si elle était saine le jour de la mise en ligne : c’est l’objet d’un contrat de maintenance et d’hébergement.

8. Documenter les changements

La gestion de projet est souvent la partie la plus fragile, surtout après la mise en ligne. Documentez l’architecture, les dépendances ajoutées et les choix de sécurité, et versionnez le code (Git) avec des revues avant chaque fusion. Une petite bibliothèque ajoutée sans trace par un développeur peut devenir la porte d’entrée d’un incident, et sans documentation personne ne saura qu’elle existe.

9. Journaliser et surveiller

Enregistrez les événements importants (connexions, échecs d’authentification, changements de droits, exports de données) et configurez des alertes sur les comportements anormaux. Sans journaux, une intrusion peut passer inaperçue pendant des semaines, et il devient impossible de savoir quelles données ont été touchées. Veillez à ce que les logs ne contiennent eux-mêmes ni mot de passe ni donnée bancaire.

10. Former les équipes et gérer les accès

Les personnes qui administrent l’application doivent connaître les risques de base (hameçonnage, partage de mots de passe) et disposer de comptes nominatifs. Supprimez les accès des personnes qui quittent l’entreprise ou le projet, y compris ceux des prestataires. Un gestionnaire de mots de passe d’équipe évite les identifiants partagés dans des e-mails ou des tableurs.

Comment tester la sécurité de son application ?

Essayer de pirater sa propre application reste le meilleur moyen de mesurer sa résistance. Plusieurs approches se complètent :

• L’analyse statique du code (SAST) : un outil lit le code source à la recherche de motifs dangereux, idéalement à chaque modification.
• L’analyse des dépendances (SCA) : elle signale les bibliothèques qui ont des vulnérabilités connues.
• Les tests dynamiques (DAST) : un scanner attaque l’application en fonctionnement, comme le ferait un robot malveillant.
• Le test d’intrusion : un spécialiste tente manuellement de compromettre l’application, en connaissant ou non son fonctionnement interne (voir la différence entre test boîte noire et boîte blanche).

Pour structurer ces tests, l’OWASP publie l’ASVS (Application Security Verification Standard), une liste d’exigences vérifiables dont la version 5.0 est sortie en mai 2025. Elle permet de fixer, dans un contrat ou un cahier des charges, le niveau de sécurité attendu. Pour un test d’intrusion, faites appel à une société spécialisée en cybersécurité, indépendante de l’équipe qui a développé l’application, et documentez chaque faille trouvée jusqu’à sa correction.

Quelles obligations légales en France ?

Dès que votre application traite des données personnelles, le RGPD s’applique. Son article 32 impose de mettre en œuvre des mesures techniques et organisationnelles adaptées au risque, comme la pseudonymisation, le chiffrement ou la capacité à rétablir l’accès aux données après un incident. Son article 33 impose de notifier à la CNIL une violation de données présentant un risque pour les personnes, si possible dans les 72 heures après en avoir pris connaissance.

Côté ressources, la CNIL publie un guide de la sécurité des données personnelles et un guide RGPD du développeur, et l’ANSSI propose des recommandations sur les mécanismes de sécurité côté navigateur (CSP, CORS, cookies). Pour une vue d’ensemble des obligations, lisez notre article sur le RGPD.

Quelles erreurs éviter ?

• Traiter la sécurité en fin de projet. Une faille de conception (A06 dans le classement OWASP) coûte bien plus cher à corriger après la mise en ligne.
• Se fier au HTTPS seul. Il protège les échanges, pas le serveur ni la logique de l’application.
• Vérifier les droits uniquement dans l’interface. Les contrôles doivent être faits côté serveur.
• Oublier la maintenance. Les dépendances vieillissent et de nouvelles failles sont publiées en permanence.
• Afficher les erreurs techniques aux visiteurs. Un message d’erreur détaillé renseigne l’attaquant sur votre pile technique.
• Partager des comptes administrateurs. Impossible alors de savoir qui a fait quoi, ni de couper un accès proprement.

Si vous lancez une application métier ou un espace client, on intègre ces points dès la conception dans nos applications web sur mesure. Pour en parler, écrivez-nous à contact@osmova.com ou via le formulaire de contact.

Questions fréquentes

Le HTTPS suffit-il à sécuriser une application web ?

Non. Le HTTPS chiffre les échanges entre le navigateur et le serveur, ce qui empêche l’interception. Il ne protège ni contre une injection SQL, ni contre un contrôle d’accès mal fait, ni contre une dépendance vulnérable.

Qu’est-ce que l’OWASP Top 10 ?

C’est le classement des dix catégories de risques les plus critiques pour les applications web, publié par la fondation OWASP. L’édition en vigueur est celle de 2025, avec le contrôle d’accès défaillant en première position.

À quelle fréquence faire un test d’intrusion ?

Il n’existe pas de règle légale unique. Une bonne pratique consiste à en réaliser un avant la mise en ligne, puis après chaque évolution importante (nouveau module de paiement, nouvelle API), en complément des analyses automatiques menées en continu.

Comment stocker les mots de passe des utilisateurs ?

Jamais en clair ni avec un simple chiffrement réversible. La CNIL recommande une fonction de hachage dédiée, salée, comme scrypt ou Argon2.

Que faire en cas de fuite de données ?

Contenir l’incident (couper l’accès, changer les secrets), conserver les journaux, évaluer les données touchées et notifier la CNIL si possible sous 72 heures lorsque la violation présente un risque pour les personnes. Si le risque est élevé, les personnes concernées doivent aussi être informées.

Sources

• OWASP Top 10:2025
• OWASP Application Security Verification Standard (ASVS 5.0)
• OWASP Cheat Sheet Series
• CNIL : recommandation sur les mots de passe (2022)
• CNIL : guide de la sécurité des données personnelles
• CNIL : guide RGPD du développeur
• RGPD, chapitre IV (articles 32 et 33)
• CNIL : notifier une violation de données personnelles
• ANSSI : recommandations pour sécuriser un site web
• MDN : en-tête Set-Cookie
• MDN : en-tête Strict-Transport-Security