Sécurité des applications web : le guide complet 2026
La sécurité des applications web regroupe les mesures qui empêchent un tiers de lire, de modifier ou de bloquer une application accessible par navigateur et ses données. Elle se décide au cadrage, s'appuie sur le Top 10 OWASP 2025 et sur l'ASVS, et engage l'entreprise comme son prestataire au titre du RGPD, qui impose de notifier une violation à la CNIL si possible sous 72 heures.
Votre application web est-elle vérifiable ?
Répondez à 4 questions rapides
En 2025, le piratage de compte est devenu la première menace des entreprises et associations aidées par Cybermalveillance.gouv.fr, avec 21 % de leurs parcours d'assistance. La même année, la CNIL a reçu 6 167 notifications de violations de données, dont la moitié causées par un piratage. Une application web concentre ce qui intéresse un attaquant : des comptes, des données et un accès depuis n'importe où.
Ce guide de la sécurité des applications web s’adresse à celui qui fait développer une application, pas à celui qui la code. Il donne les mesures attendues par l’OWASP, l’ANSSI et la CNIL, puis les obligations légales qui s’appliquent. À chaque étape, il dit ce qu’il faut exiger de votre prestataire et comment le vérifier.
🛡️ Qu’est-ce que la sécurité des applications web ?
Le périmètre couvre quatre choses : le code de l’application, sa configuration, les données qu’elle stocke et les échanges entre le navigateur et le serveur. Il ne couvre pas les ordinateurs de vos équipes, votre messagerie ni les services que vous utilisez à côté, qui se traitent séparément. L’ANSSI définit la sécurité des systèmes d’information par trois propriétés : la disponibilité, l’intégrité et la confidentialité. Pour une application web, elles deviennent des contrôles vérifiables : qui se connecte, qui voit quoi, ce qui est chiffré, ce qui est tracé.
Aucune définition officielle du terme ne fait autorité, ni au NIST ni à l’ANSSI. La référence commune est l’OWASP, dont les référentiels sont publics : la CNIL demande de protéger les sites web contre les risques de son Top 10.
Le Top 10 OWASP : les failles les plus fréquentes
Le classement en est à sa huitième édition. Celle de 2025 repose sur des données portant sur plus de 2,8 millions d’applications et sur une enquête auprès de la communauté. Ses dix entrées sont des catégories de risques, pas des failles précises. L’OWASP prévient : s’en servir comme cahier des charges de développement, c’est viser « le strict minimum ».
Les intitulés sont traduits de l’anglais. Par rapport à l’édition 2021, encore citée par la plupart des guides en ligne, la chaîne d’approvisionnement logicielle (A03) élargit l’ancienne catégorie des composants vulnérables. Les conditions exceptionnelles mal gérées (A10) font leur entrée.
Site vitrine, application web, logiciel métier : une exposition différente
Un site vitrine publie des pages que tout le monde peut lire. Une application web sur mesure ouvre des comptes, stocke des données et laisse des utilisateurs agir à distance. Un logiciel métier sur mesure y ajoute vos règles de calcul, vos validations et des connexions à d’autres outils. Chaque couche ajoute une surface à protéger : des identifiants, des droits, des échanges.
⚖️ Qui est concerné, et quelles obligations s’appliquent ?
Toute application web qui traite des données personnelles relève de l’obligation de sécurité du RGPD. La directive NIS2 vise certaines entreprises d’au moins taille moyenne, dans des secteurs listés. Le Cyber Resilience Act s’adresse aux fabricants de produits numériques. Les données de santé et de paiement ont, en plus, leurs propres référentiels.
Toute application qui traite des données personnelles : l’obligation de sécurité du RGPD
L’article 32 du RGPD s’impose à deux acteurs : le responsable du traitement, l’entreprise qui décide de l’application, et le sous-traitant qui traite les données pour son compte. Un prestataire qui héberge ou maintient l’application en est un exemple. Tous deux garantissent « un niveau de sécurité adapté au risque », tests réguliers de l’efficacité des mesures compris.
En cas de violation de données, l’article 33 du RGPD impose de notifier la CNIL « si possible, 72 heures au plus tard », sauf absence de risque. Toute violation se consigne dans un registre, même non notifiée. Si le risque est élevé, les personnes sont informées ; le chiffrement peut dispenser de cette information, jamais de la notification.
Un manquement à ces obligations expose à une amende plafonnée à 10 M€ ou à 2 % du chiffre d’affaires annuel mondial. Le montant le plus élevé est retenu, et il s’agit d’un plafond, pas d’un tarif.
L'article 28 du RGPD exige un prestataire présentant « des garanties suffisantes » et un contrat écrit. Ce contrat l'oblige à appliquer les mesures de sécurité, à vous assister en cas d'incident et à permettre « des audits, y compris des inspections ». La CNIL y ajoute la restitution puis la destruction des données en fin de contrat.
NIS2 et Cyber Resilience Act : quand votre entreprise ou votre prestataire est visé
La directive NIS2 vise, dans des secteurs listés, les entreprises d’au moins 50 personnes ou dont le chiffre d’affaires et le bilan dépassent 10 M€. Le mot « logiciel » n’y figure pas. En revanche, la « gestion des services TIC (interentreprises) » vise les prestataires qui installent, exploitent ou entretiennent des applications pour leurs clients.
En France, la loi de transposition n’est pas promulguée au 15 septembre 2026. Adoptée par le Sénat en mars 2025, elle attend toujours son examen en séance à l’Assemblée nationale. L’ANSSI diffuse depuis mars 2026 un référentiel de mesures, encore au stade de document de travail.
Le Cyber Resilience Act, règlement européen 2024/2847, s’adresse aux fabricants de produits numériques mis sur le marché. Son obligation de signaler les vulnérabilités activement exploitées s’applique depuis le 11 septembre 2026, le reste du règlement à partir du 11 décembre 2027. Le logiciel en tant que service conçu hors de la responsabilité d’un fabricant relève de NIS2. Le logiciel développé sur mesure, lui, n’est pas exclu du champ.
Pour une application web développée et exploitée pour une seule entreprise, aucun texte officiel ne tranche l'application du Cyber Resilience Act. La foire aux questions de la Commission européenne éclaire la notion de produit sur mesure, mais elle précise ne pas engager la Commission. Posez la question contrat en main, ne concluez pas seul.
Quand ce guide ne suffit pas
Deux familles de données sortent du cadre de ce guide. Les données de santé exigent un hébergeur titulaire d’un certificat de conformité HDS, selon un référentiel v2.0 en vigueur. Les paiements par carte relèvent de la norme PCI DSS, qui impose un test d’intrusion au moins tous les 12 mois. Dans ces deux cas, un spécialiste de la conformité intervient dès le cadrage.
🧰 Ce qu’il faut réunir avant de commencer
Sécuriser une application web commence avant la première ligne de code, avec quelques documents courts. L’entreprise sait quelles données seront traitées, qui accède à quoi et qui décide en cas d’incident. Le prestataire fournit un référentiel d’exigences, la liste des composants et un plan de sauvegarde. Sans ces documents, rien ne se vérifie à la livraison.
Ce que vous rassemblez en interne
Ces éléments trouvent leur place dans le cahier des charges du logiciel, au chapitre des exigences de sécurité.
Ce que le prestataire doit vous fournir
Pour choisir ce prestataire, le guide complet du développement logiciel sur mesure reprend le déroulé d’un projet de bout en bout.
🛠️ Sécuriser une application web étape par étape
Sécuriser une application web se fait en sept étapes réparties sur toute la vie du projet. Elles vont de la modélisation des menaces à la surveillance, en passant par les accès, les entrées, les données, la configuration et les tests. Aucune n’est une option de fin de projet, et chacune se vérifie sans être technicien.
Chronologie réaliste
Les étapes se rattachent aux phases du projet plutôt qu’à des semaines. Aucune source publique ne fixe leur durée, qui dépend surtout de la sensibilité des données traitées.
Étape 1 : modéliser les menaces au cadrage
Modéliser les menaces, c’est répondre avant de coder à quatre questions reprises par l’OWASP : sur quoi travaille-t-on, qu’est-ce qui peut mal tourner, que fait-on contre, a-t-on fait assez bien ? L’OWASP recommande de mener l’exercice dès la conception, puis à chaque évolution.
C’est la parade à la conception non sécurisée, qu’aucun outil ne détecte de façon exhaustive. L’ANSSI a publié en avril 2026 une étude de marché sur l’intégration de la sécurité au cycle de développement, le S-SDLC ou DevSecOps. Elle y voit « un enjeu majeur pour la période 2025-2027 ».
Ce que vous vérifiez : une page qui liste les données sensibles, les menaces retenues et leurs parades, et le niveau ASVS visé, écrit.
Étape 2 : authentifier, contrôler les accès et protéger les API
L’authentification multifacteur est, selon l’OWASP, « de loin la meilleure défense » contre la plupart des attaques sur les mots de passe. La CNIL la demande pour les données sensibles, l’administration et les connexions depuis l’extérieur ; l’ANSSI déconseille le SMS comme second facteur. Sans second facteur, la CNIL fixe un plancher de 12 caractères de quatre types, ou 14 caractères sans caractère spécial.
Le contrôle d’accès défaillant est la première catégorie du Top 10 2025. La règle : tout refuser par défaut, n’accorder que le nécessaire, et contrôler côté serveur, là où un attaquant ne peut pas modifier la vérification. Les API, qui relient l’application à d’autres logiciels, ont leur propre classement OWASP. Son édition 2023 place en tête l’accès à une donnée qui appartient à un autre utilisateur.
Ce que vous vérifiez :
- l’authentification multifacteur, au minimum sur les comptes d’administration
- un compte nominatif par personne, aucun compte partagé
- un test simple : avec un profil restreint, tenter d’ouvrir une fiche réservée à un autre profil
Étape 3 : traiter chaque entrée comme hostile
L’injection, cinquième catégorie du Top 10, survient quand une saisie est exécutée comme une commande par la base de données ou le navigateur. Contre l’injection SQL, l’OWASP recommande la requête paramétrée et déconseille fortement de se contenter d’échapper les caractères. Contre l’injection de script (XSS), il recommande les protections du framework et l’encodage des sorties ; la CSP n’est qu’une couche supplémentaire. Contre la falsification de requête (CSRF), il faut des jetons ou la protection du framework, l’attribut SameSite ne suffisant pas.
Ce que vous vérifiez : le framework et ses protections activées, nommés par le prestataire, et l’absence de requête SQL construite en collant des saisies.
Étape 4 : protéger les données et les secrets
Un mot de passe se hache, il ne se chiffre pas : le hachage est à sens unique, le chiffrement réversible. L’OWASP recommande Argon2id et réserve bcrypt aux systèmes existants. Les échanges passent en TLS, le protocole qui remplace SSL : l’ANSSI privilégie TLS 1.3, accepte TLS 1.2 sous conditions et proscrit les versions antérieures.
Les secrets, clés d’API et mots de passe techniques, restent hors du code source, et un secret exposé se révoque. Les tests se font sur des données fictives ou anonymisées, dans un environnement distinct de la production. Le guide de la recette d’un logiciel métier détaille la seule exception admise par la CNIL.
Ce que vous vérifiez :
- l’algorithme de hachage des mots de passe, nommé
- la version de TLS active en production
- l’emplacement des secrets, hors du dépôt de code
- la provenance des données de test
Étape 5 : supprimer ce qui ne sert pas, durcir la configuration, tenir les dépendances à jour
La mauvaise configuration est la deuxième catégorie du Top 10. La CNIL en donne les réflexes : ports inutiles fermés, base de données jamais accessible depuis Internet, aucun compte générique. L’en-tête HSTS impose le HTTPS, l’en-tête CSP limite les ressources qu’une page peut charger. Les messages d’erreur restent génériques et n’affichent aucun détail technique.
Les composants tiers forment la troisième catégorie. L’OWASP demande de suivre la version de chaque composant, dépendances indirectes comprises, et un plan de mise à jour pour toute la vie de l’application. Sur GitHub, les alertes Dependabot sont incluses dans tous les plans.
Ce que vous vérifiez :
- la liste des composants et la date de sa dernière revue
- les en-têtes HSTS et CSP en production
- une page d’erreur sans version de logiciel
Étape 6 : tester, par la relecture du code, l’analyse automatique et le test d’intrusion
L’analyse statique (SAST) examine le code sans l’exécuter ; l’OWASP prévient qu’elle ne détecte qu’une part relativement faible des failles. L’analyse dynamique (DAST) teste l’application en fonctionnement, depuis l’extérieur. Le test d’intrusion, ou pentest, mené par un spécialiste, cherche ce que les outils ne voient pas. La CNIL recommande de tester régulièrement et avant toute mise en production d’une nouvelle version.
En France, l’ANSSI qualifie des prestataires d’audit, les PASSI, notamment pour les tests d’intrusion et l’audit de code source. Leur liste officielle est publique et mise à jour chaque mois.
Ce que vous vérifiez : un rapport de test daté, avec les failles et leurs corrections, et pour un test d’intrusion le périmètre écrit et le contre-test.
Étape 7 : surveiller, sauvegarder et préparer l’incident
Sans journalisation, une attaque passe inaperçue. La CNIL recommande de tracer les créations, consultations, modifications et suppressions de données, avec leur auteur et leur horodatage, et de garder ces journaux six mois à un an. Elle demande une sauvegarde sur un site distinct, une hors ligne, et des tests réguliers de restauration. En cas de violation, le prestataire prévient son client dans les meilleurs délais, et l’entreprise notifie la CNIL si possible sous 72 heures.
Ce que vous vérifiez : la date du dernier test de restauration réussi, la personne qui reçoit les alertes, et la procédure écrite en cas de violation.
Mener ces étapes seul suppose un développeur formé à la sécurité et du temps de vérification à chaque livraison. Chez OTTOPILOTE, tout part d’un brief de deux ou trois phrases, avec un devis gratuit et une réponse humaine sous 24 h ouvrées. Après la livraison, 30 jours de corrections sont offerts, puis un suivi mensuel en option couvre les corrections, les évolutions et la sécurité.
💶 Combien coûte la sécurité d’une application web
La sécurité d’une application web n’a pas de prix unique : elle se décompose en postes, dont le premier fait partie du développement lui-même. Aucune source officielle ne publie de fourchette pour un test d’intrusion. Le poste durable est la maintenance, qui porte les correctifs de sécurité année après année.
Le coût par poste
Les montants des marchés publics ne font pas une grille tarifaire. Comutitres a payé 2 550 € HT pour tester une page de désabonnement, le CIG Grande Couronne 35 000 € HT pour deux applications web. France Télévisions a attribué 229 655 € HT pour la plateforme france.tv. Ni le périmètre ni le nombre de jours ne sont publiés, et certains montants sont des maxima. Mis à l’échelle, l’écart parle de lui-même : ce n’est pas la même prestation.
🧭 Ce qu’une application sécurisée garantit, et ce qu’elle ne garantit pas
Une application web sécurisée selon les référentiels réduit le risque, sans jamais l’annuler. L’OWASP le dit sans détour : aucun outil ne couvre de façon exhaustive son Top 10, et toute promesse de couverture complète est « tout simplement fausse ». Les mesures protègent l’application, pas les personnes qui s’en servent.
Garanties et limites
Des comptes plus difficiles à pirater, si l'authentification multifacteur est imposée aux comptes sensibles.
Des données inexploitables en cas de vol, si les mots de passe sont hachés et les données chiffrées.
Des attaques courantes bloquées, tant que les protections du framework restent actives et à jour.
Une attaque détectée et un retour possible, si les journaux sont surveillés et la restauration testée.
Le risque zéro. L'OWASP écarte toute idée de couverture complète.
L'hameçonnage de vos équipes. Les comptes fuités ou hameçonnés servent d'accès initial, relève Cybermalveillance.gouv.fr.
Les postes de travail et services tiers. Messagerie, ordinateurs, outils connectés se sécurisent à part.
La faille découverte demain. Un composant sûr aujourd'hui peut ne plus l'être : c'est le rôle de la maintenance.
⚠️ Les pièges les plus fréquents
Six pièges fragilisent régulièrement la sécurité d’une application web, du cadrage à l’exploitation. Chacun a une parade simple, à condition de l’écrire avant de signer.
Six pièges, et leur parade
Une protection ajoutée après coup ne corrige pas une conception défaillante. Les ratios « 30 fois plus cher » qui circulent n'ont aucune source primaire : le surcoût ne se chiffre pas honnêtement.
Parade Menaces et niveau ASVS écrits au cadrage.
Un identifiant commun rend chaque action impossible à attribuer et survit aux départs. La CNIL interdit les comptes partagés ; l'ANSSI demande un compte d'administration nominatif.
Parade Un compte par personne, droits revus chaque année.
Sans contrat de maintenance, personne n'applique les correctifs. L'OWASP demande un plan de mise à jour pour toute la durée de vie de l'application.
Parade Écrire qui met à jour, et à quel rythme.
Une copie de la base de production sur un poste de test expose des données réelles sans leurs protections. L'amende encourue pour un manquement à la sécurité peut atteindre 10 M€ ou 2 % du CA mondial.
Parade Des données fictives ou anonymisées.
Un WAF filtre des attaques connues sans corriger la faille. L'OWASP le juge peu fiable contre le XSS et fait de la correction du code la première stratégie.
Parade Le WAF en complément, le code corrigé.
Une sauvegarde jamais restaurée reste une hypothèse. La CNIL demande des tests réguliers ; l'ANSSI prévoit un exercice au moins annuel en version renforcée.
Parade Un test de restauration daté et consigné.
🎯 En résumé
Une seule décision vous appartient vraiment : le niveau d’exigence, et elle se prend avant de signer, pas après la première alerte. L’ordre qui tient est toujours le même : recenser ce que l’application traitera, fixer ce niveau par écrit, le faire figurer au devis, puis ne valider chaque livraison que sur une preuve datée. Ce qui n’a pas été écrit avant la signature se renégocie ensuite.
Une application sûre n’est pas celle qui promet le risque zéro : c’est celle dont chaque protection se prouve, du cadrage à l’exploitation.
📚 Sources
- OWASP Top 10:2025 : liste, données et usage recommandé du classement
- OWASP Cheat Sheet Series : mots de passe, injection, XSS, CSRF, authentification, secrets, en-têtes, journalisation
- OWASP Application Security Verification Standard 5.0 : niveaux de vérification
- CNIL, Guide de la sécurité des données personnelles, édition 2024 : authentification, habilitations, sites web, sauvegardes, violations
- CNIL, rapport annuel 2025 : violations de données notifiées
- Règlement général sur la protection des données (EUR-Lex) : articles 28, 32, 33, 34, 82 et 83
- ANSSI, directive NIS 2 : périmètre et état de la transposition
- Cyber Resilience Act, règlement (UE) 2024/2847 (EUR-Lex) : calendrier et champ d’application
- Cybermalveillance.gouv.fr, rapport d’activité 2025 : menaces des entreprises et associations
Questions fréquentes
Le Top 10 OWASP 2025 place en tête le contrôle d'accès défaillant, puis la mauvaise configuration de sécurité et la chaîne d'approvisionnement logicielle. Ce classement se lit comme un ordre de priorité, pas comme un diagnostic de votre application : il agrège des mesures faites ailleurs, sur d'autres logiciels. Demandez à votre prestataire lesquelles de ces dix catégories ont été testées chez vous, et sur quelle preuve.
Le Top 10 OWASP est la liste des dix risques jugés les plus critiques pour les applications web. L'édition 2025 est la huitième. L'OWASP la présente d'abord comme un document de sensibilisation : utilisée comme norme de développement ou de test, elle ne constitue que le strict minimum. Pour définir et vérifier des exigences, l'OWASP recommande son autre référentiel, l'ASVS, dont la version 5.0 date de mai 2025.
Une API se sécurise comme l'application qu'elle sert, avec une vigilance particulière sur l'autorisation. Le classement OWASP des risques des API, édition 2023, place en tête l'autorisation défaillante au niveau de l'objet, puis l'authentification défaillante. Chaque requête doit vérifier, côté serveur, que l'utilisateur a le droit d'accéder à la donnée demandée. La consommation de ressources doit être limitée, et l'inventaire des API tenu à jour.
Trois familles d'outils se complètent. SonarQube Community Build et Semgrep Community Edition analysent le code gratuitement, et ZAP, gratuit et open source, teste l'application en fonctionnement. Les alertes Dependabot, incluses dans tous les plans GitHub, surveillent les composants. Aucun outil ne remplace un test d'intrusion : l'OWASP rappelle que les outils ne couvrent pas l'intégralité de son Top 10.
Aucune source officielle ne publie de fourchette de prix pour un audit de sécurité d'application web. Les marchés publics attribués en France pour des audits ou tests d'intrusion d'applications web vont de 2 550 € HT à 229 655 € HT, sur des périmètres non publiés. Le Diag Cybersécurité de Bpifrance coûte 8 800 € HT, subventionné à 50 %, mais il évalue l'entreprise, pas votre application.
Aucune loi ne fixe de fréquence générale. Le RGPD impose de tester « régulièrement » l'efficacité des mesures de sécurité, et la CNIL recommande des tests réguliers et avant toute mise en production d'une nouvelle version. L'OWASP demande un plan de mise à jour continu. Seuls certains secteurs chiffrent : la norme PCI DSS exige un test d'intrusion au moins tous les 12 mois pour les données de carte.
L'entreprise et son prestataire sont tous deux responsables, à des titres différents. Le RGPD impose l'obligation de sécurité au responsable du traitement, l'entreprise, et au sous-traitant qui traite les données pour elle. L'entreprise répond du dommage causé par le traitement ; le prestataire, s'il manque à ses propres obligations ou sort des instructions reçues. Le contrat doit prévoir les mesures de sécurité, l'assistance en cas d'incident et le droit d'audit.
Non, un pare-feu applicatif ne suffit pas. Il filtre des attaques connues en amont de l'application, mais il ne corrige pas la faille. L'OWASP fait de la correction du code la première stratégie de remédiation et juge les WAF peu fiables contre le XSS. La norme PCI DSS impose en revanche une solution automatisée de ce type devant les applications web publiques qui traitent des données de carte.
Un projet en tête ? Parlons-en.
Un brief, une lecture honnête et un devis gratuit sous 24 h. On vous aide à choisir — ou à construire — le bon outil.
OTTOPILOTE