November 9, 2026
November 9, 2026
Votre application web est ouverte au monde entier, jour et nuit. Il peut s'agir d'un portail client, d'un système de réservation, d'une boutique en ligne ou d'un outil interne que vos équipes utilisent depuis chez elles. Dans tous les cas, chaque formulaire de connexion, chaque champ de recherche et chaque envoi de fichier est une porte que quelqu'un peut essayer d'ouvrir. La plupart des attaques visant ces portes n'ont rien de sophistiqué. Elles réussissent parce qu'un point élémentaire a été oublié. Ce guide présente les menaces les plus courantes en termes simples et explique comment les prévenir.
Les menaces les plus courantes en un coup d'œil
La sécurité des applications web consiste à protéger les sites, portails et services en ligne contre les attaques qui visent l'application elle-même : son code, sa logique, ses données et la façon dont les utilisateurs se connectent. Elle couvre tout, de la conception et de l'écriture du logiciel à sa configuration, son hébergement, ses tests et sa surveillance après le lancement.
Elle se distingue de la sécurité réseau, qui protège l'infrastructure autour de l'application, comme les pare-feu et les serveurs. Un pare-feu peut bloquer beaucoup de trafic indésirable, mais il ne peut pas arrêter quelqu'un qui se connecte avec un mot de passe volé puis consulte les commandes d'autres clients parce que l'application n'a jamais vérifié s'il en avait le droit. Ce type de faille se trouve dans l'application, c'est donc là qu'il faut la corriger.
La responsabilité est généralement partagée. Votre équipe ou votre partenaire de développement répond d'un code et d'une configuration sûrs. Votre hébergeur ou fournisseur cloud s'occupe de l'infrastructure sous-jacente. Et votre entreprise décide qui obtient des accès, quelles données sont collectées et à quelle vitesse les mises à jour de sécurité sont validées. Les failles apparaissent souvent là où ces responsabilités se rejoignent.
Les applications web sont exposées sur internet, elles contiennent souvent des données personnelles ou de paiement, et elles reposent sur de nombreux éléments : votre propre code, des bibliothèques open source, des extensions, des API et des services cloud. Chacun de ces éléments peut introduire une faiblesse.
Les attaquants n'ont d'ailleurs pas besoin de vous choisir. Des outils automatisés parcourent chaque jour de larges portions d'internet à la recherche de vulnérabilités connues dans des logiciels courants. Si votre application utilise une extension obsolète dont la faille a été publiée, elle peut être repérée et attaquée en quelques jours, quelle que soit la taille de votre entreprise.
La violation subie en 2017 par l'agence de crédit américaine Equifax en est l'exemple type. Les attaquants ont exploité une vulnérabilité connue d'Apache Struts, un framework web open source très répandu, pour laquelle un correctif avait déjà été publié. Les données personnelles d'environ 147 millions de personnes ont été exposées. La leçon pour toute entreprise est simple : beaucoup d'incidents graves ne reposent pas sur des techniques nouvelles ou astucieuses, mais sur un problème connu qui n'a pas été corrigé à temps.
L'OWASP Top 10, publié par l'Open Worldwide Application Security Project, est la référence la plus utilisée sur les risques des applications web. Sa dernière édition, l'OWASP Top 10:2025, place en tête le contrôle d'accès défaillant, la mauvaise configuration de sécurité et les défaillances de la chaîne d'approvisionnement logicielle. Les menaces ci-dessous reprennent les mêmes idées, expliquées pour des dirigeants et des responsables plutôt que pour des spécialistes de la sécurité.
C'est la faille grave la plus courante dans les applications web, et elle est facile à comprendre. Le contrôle d'accès détermine qui peut voir et faire quoi. Quand il est défaillant, des utilisateurs accèdent à des données ou à des fonctions qui ne leur sont pas destinées.
Un exemple classique : un client consulte sa facture à une adresse qui se termine par /invoice/10452. Il remplace le numéro par 10453 et voit la facture d'un autre client. L'application a vérifié qu'il était connecté, mais jamais que cette facture lui appartenait. D'autres variantes du même problème : des utilisateurs ordinaires qui ouvrent des pages d'administration en devinant leur adresse, ou qui modifient un champ caché pour s'accorder une remise ou un rôle plus élevé.
La prévention tient en une règle : vérifier les droits côté serveur à chaque requête, à chaque fois, et refuser l'accès par défaut. Masquer un bouton dans l'interface ne protège rien, car la requête peut toujours être envoyée directement.
Beaucoup de violations commencent par des paramètres plutôt que par du code. Exemples fréquents : des mots de passe administrateur par défaut jamais changés, des pages de test restées en ligne après le lancement, des espaces de stockage cloud rendus publics et des messages d'erreur qui affichent des détails techniques comme des noms de bases de données ou des chemins de fichiers.
La solution relève surtout de la rigueur. Utilisez une configuration standard et durcie pour chaque environnement, supprimez tout ce qui n'est pas nécessaire et revoyez les paramètres à chaque mise en production. Les contrôles de configuration automatisés aident, surtout quand votre application tourne dans le cloud. Notre article sur les solutions de sécurité cloud approfondit cet aspect.
Les applications web modernes s'appuient fortement sur des bibliothèques, frameworks et extensions open source. C'est normal et cela fait gagner beaucoup de temps, mais une faille dans le code de quelqu'un d'autre peut devenir une faille dans le vôtre. Le cas Equifax en est un exemple. Tous les systèmes de gestion de contenu et toutes les plateformes e-commerce populaires ont connu des problèmes similaires avec des extensions non mises à jour.
La liste 2025 de l'OWASP élargit ce point aux « défaillances de la chaîne d'approvisionnement logicielle », qui couvrent aussi les paquets compromis, les outils de build et les canaux de mise à jour. En pratique, la protection passe par :
La maintenance et les mises à jour des systèmes sont la partie la moins spectaculaire de la sécurité, et souvent la plus importante.
L'injection se produit quand une application prend ce qu'un utilisateur a saisi et le traite comme une commande. Avec l'injection SQL, un attaquant tape des commandes de base de données dans un champ de formulaire ou une URL, et l'application les exécute, ce qui peut exposer ou effacer des données. En 2023, une faille d'injection SQL dans le logiciel de transfert de fichiers MOVEit Transfer a été exploitée par un groupe de rançongiciel pour voler des données à un grand nombre d'organisations dans le monde.
Le cross-site scripting, ou XSS, est un problème voisin. Un attaquant parvient à insérer son propre script dans une page, par exemple via un commentaire ou un avis produit, et ce script s'exécute ensuite dans le navigateur des autres utilisateurs. Il peut voler des informations de session ou rediriger vers de fausses pages de connexion.
La bonne nouvelle, c'est que l'injection est bien connue et évitable. Les développeurs doivent utiliser des requêtes paramétrées au lieu de construire des commandes à partir des saisies des utilisateurs, valider les entrées côté serveur, encoder les sorties avant de les afficher et s'appuyer sur des frameworks modernes qui gèrent une grande partie de ces protections automatiquement.
Les pages de connexion sont attaquées en permanence. L'une des méthodes les plus courantes est le credential stuffing : les attaquants récupèrent des identifiants et mots de passe ayant fuité d'autres sites et les essaient sur le vôtre, sachant que beaucoup de gens réutilisent leurs mots de passe. D'autres problèmes fréquents : des règles de mot de passe trop faibles, aucune limite au nombre de tentatives de connexion et des jetons de session valables trop longtemps.
Une authentification solide comprend généralement :
Les informations personnelles, de paiement, de santé et les données de l'entreprise exigent une attention particulière. Les problèmes surviennent quand les données circulent sans chiffrement, sont stockées en clair, conservées plus longtemps que nécessaire ou visibles dans des journaux et des sauvegardes mal protégés.
Utilisez HTTPS partout, chiffrez les données sensibles stockées et évitez de collecter des données dont vous n'avez pas réellement besoin. Moins de données, c'est moins de choses à protéger. Au-delà du risque technique, il y a un risque juridique : à Singapour comme en Malaisie, les lois sur la protection des données imposent aux organisations de prendre des mesures de sécurité raisonnables pour les données personnelles qu'elles détiennent.
Certaines attaques durent des semaines parce que personne ne les remarque. Si votre application n'enregistre pas les événements importants, comme les connexions échouées, les erreurs de droits et les modifications des paramètres d'administration, ou si ces enregistrements ne sont jamais consultés, vous perdez la possibilité d'arrêter une attaque à temps.
Journalisez les événements liés à la sécurité, conservez les journaux là où un attaquant ne peut pas facilement les modifier et mettez en place des alertes qui parviennent à une personne qui agira. Le monitoring et le support proactif sont souvent le moyen le plus pratique pour les petites entreprises d'obtenir cette couverture sans équipe de sécurité complète.
La sécurité fonctionne mieux quand elle fait partie de chaque étape d'un projet plutôt que d'un contrôle final. Voici ce que cela donne en pratique.
Pendant la conception et le développement
Pensez à la sécurité dès les premières exigences. Décidez qui peut accéder à quoi, quelles données sont sensibles et ce qui pourrait mal tourner si quelqu'un détournait une fonctionnalité. Pendant le développement, suivez les bonnes pratiques de codage sécurisé, utilisez des frameworks bien maintenus, relisez le code sous l'angle de la sécurité et gardez les secrets comme les mots de passe et les clés d'API hors du code source.
Avant le lancement
Testez l'application pour ses vulnérabilités, pas seulement pour ses fonctionnalités. Lancez des analyses de sécurité automatisées, corrigez ce qu'elles révèlent et, pour les applications qui traitent des données sensibles ou des paiements, faites réaliser un test d'intrusion par un spécialiste qualifié. Supprimez les comptes de test, les données d'exemple et les paramètres de débogage avant la mise en ligne. Notre guide pour construire une stratégie efficace d'assurance qualité et de test explique où s'insèrent les tests de sécurité.
Après le lancement
C'est là que beaucoup d'entreprises relâchent trop tôt leur vigilance. Appliquez les correctifs aux composants et aux serveurs, surveillez les journaux et les alertes, sauvegardez les données et testez les restaurations, et revoyez les droits d'accès à chaque arrivée ou départ. Un pare-feu applicatif web (WAF) peut bloquer beaucoup d'attaques courantes avant qu'elles n'atteignent votre application, mais c'est une couche supplémentaire, pas un substitut à un code sûr. Une bonne configuration cloud et hébergement propose généralement un WAF et une protection contre les attaques DDoS en option.
Pour les PME de Singapour, le label Cyber Essentials de la Cyber Security Agency constitue un bon point de départ pour les contrôles de sécurité de base dans toute l'entreprise, y compris les systèmes dont dépend votre application web.
Le terme « tests de sécurité » recouvre plusieurs activités assez différentes. Connaître la différence aide à demander ce qu'il faut et à comparer correctement les devis.
Les outils automatisés sont rapides et peu coûteux à lancer souvent, mais ils manquent les problèmes de logique comme l'exemple de la facture ci-dessus. Les testeurs d'intrusion les trouvent, mais coûtent plus cher et ne donnent qu'une photographie à un instant donné. La plupart des entreprises ont intérêt à combiner les deux : des contrôles automatisés en permanence et des tests manuels aux moments clés.
Si une équipe externe construit ou maintient votre application web, la sécurité est un sujet légitime à aborder tôt. Quelques questions en disent long sur le sérieux avec lequel elle la traite.
Demandez comment elle gère le contrôle d'accès et l'authentification dans ses projets, et si elle suit les recommandations de l'OWASP. Renseignez-vous sur les tests de sécurité inclus dans le prix et sur ceux qui seraient facturés en plus. Vérifiez comment elle gère les composants tiers et à quelle vitesse elle applique les correctifs de sécurité après le lancement. Demandez qui a accès à vos systèmes et données de production, et comment cet accès est contrôlé et journalisé. Enfin, demandez ce qui se passe si elle détecte un incident de sécurité : qui elle prévient, en combien de temps et ce qu'elle fait ensuite.
Un partenaire qui répond clairement à ces questions, exemples à l'appui, est généralement un partenaire qui y a déjà été confronté. Notre article sur la sécurité des données dans l'externalisation du développement logiciel détaille ce qu'il faut vérifier quand on travaille avec une équipe externalisée.
Serdao développe et maintient des logiciels d'entreprise depuis plus de 18 ans, avec des équipes de développement et de support basées à Hô Chi Minh-Ville, au Vietnam, et une gestion de projet assurée depuis notre siège en France. La sécurité fait partie de notre façon de concevoir, de développer et d'exploiter les applications, ce n'est pas une option ajoutée à part.
Selon vos besoins, nous pouvons intervenir sur :
Si vous voulez savoir où en est votre application actuelle, notre guide de la gestion de la sécurité informatique est un bon point de départ. Vous pouvez aussi découvrir nos services de développement logiciel ou contacter notre équipe pour parler d'un audit de votre application.
Conclusion
La plupart des attaques contre les applications web exploitent une courte liste de faiblesses bien connues : des contrôles d'accès oubliés, des paramètres jamais modifiés, des extensions non mises à jour, des saisies non validées et des alertes que personne ne lit. Aucune de ces failles n'exige un budget énorme pour être corrigée. Elles demandent de l'attention à chaque étape, de la conception à l'exploitation quotidienne.
Si vous ne deviez retenir que trois actions après cette lecture, ce seraient celles-ci : vérifier que votre application contrôle les droits côté serveur, mettre en place une routine régulière de correctifs et vous assurer que quelqu'un surveille réellement les alertes de sécurité.
1. Quelle est la vulnérabilité la plus courante dans les applications web ?
Le contrôle d'accès défaillant est classé premier dans l'OWASP Top 10:2025. Il survient quand des utilisateurs peuvent consulter ou modifier des données ou des fonctions auxquelles ils ne devraient pas avoir accès, par exemple en changeant un identifiant dans une adresse web.
2. Qu'est-ce que l'OWASP Top 10 ?
C'est une liste régulièrement mise à jour des risques de sécurité les plus critiques pour les applications web, publiée par l'Open Worldwide Application Security Project. Développeurs et équipes de sécurité l'utilisent comme référence commune pour concevoir, développer et tester les applications.
3. Un pare-feu applicatif web suffit-il à sécuriser mon application ?
Un WAF bloque beaucoup d'attaques courantes et constitue une couche supplémentaire utile, mais il ne remplace pas un code sûr. Des failles comme un contrôle d'accès défaillant ressemblent souvent à du trafic normal, si bien qu'un pare-feu ne peut pas les détecter de façon fiable.
4. À quelle fréquence faut-il tester la sécurité d'une application web ?
Les analyses automatisées doivent tourner en continu ou avant chaque mise en production. Un test d'intrusion manuel est généralement recommandé avant le lancement d'une application qui traite des données sensibles, après des changements importants, puis périodiquement, souvent une fois par an.
5. Les sites des petites entreprises sont-ils vraiment exposés ?
Oui. Beaucoup d'attaques sont automatisées et visent des vulnérabilités connues dans des logiciels courants, pas des entreprises précises. Un petit site qui utilise une extension obsolète peut être repéré et attaqué aussi facilement qu'un grand.
6. Que faire si je pense que mon application web a été piratée ?
Contactez immédiatement votre équipe de développement ou de support, conservez les journaux et les preuves, changez les mots de passe administrateur et évaluez les données qui ont pu être touchées. Selon les données concernées, vous pouvez aussi avoir l'obligation légale de prévenir les autorités ou les clients concernés.
7. Qui est responsable de la sécurité d'une application web, le développeur ou l'entreprise ?
Les deux. L'équipe de développement répond d'un code et d'une configuration sûrs, l'hébergeur de l'infrastructure, et l'entreprise de décisions comme les droits d'accès, les données collectées et la rapidité de validation des mises à jour. Des accords clairs évitent les zones grises.