Les 10 principales vulnérabilités de sécurité des applications web que chaque équipe devrait connaître

‍Introduction : À quand remonte la dernière fois que vous avez examiné la sécurité de votre application web au-delà de son simple fonctionnement ? Voici la vérité effrayante : chaque champ de formulaire, point d'API, script tiers et fichier de configuration de votre application pourrait être un vecteur d'attaque s'il n'est pas vérifié. Les applications web modernes sont plus riches et plus complexes que jamais – ce qui signifie une surface d'attaque croissante pour les attaquants. En fait, des données récentes montrent que les applications web sont impliquées dans près de la moitié des incidents de sécurité. Des risques du célèbre Top 10 OWASP aux CVEs récemment découvertes, les vulnérabilités web ne sont pas une théorie abstraite – elles sont à l'origine de failles réelles touchant des organisations de toutes tailles.

L'objectif de cet article est de mettre en lumière les vulnérabilités les plus critiques des applications web, tant du point de vue frontend que backend. Nous couvrirons les risques bien connus du Top 10 OWASP, ainsi que les exploits très médiatisés (comme Log4Shell et d'autres) et les erreurs de codage courantes que les développeurs commettent dans des projets réels. Pour chaque vulnérabilité, nous expliquerons ce qu'elle est, donnerons un exemple réel ou un incident, et décrirons comment l'atténuer. Vous verrez également – soulignant comment la plateforme de sécurité axée sur les développeurs d'Aikido (avec des fonctionnalités comme l'analyse de code, la détection de secrets, le SAST et l'analyse IaC) peut aider à détecter ou à prévenir ces problèmes avant qu'ils ne vous affectent en production.

La Liste :

1. Attaques par injection (SQL, Commande, LDAP)
2. Cross-Site Scripting (XSS)
3. Authentification défaillante
4. Contrôle d’accès défaillant
5. Configurations de sécurité inadéquates
6. Exposition de données sensibles et fuite de secrets
7. Utilisation de composants présentant des vulnérabilités connues
8. Cross-Site Request Forgery (CSRF)9. Server-Side Request Forgery (SSRF)
10. Désérialisation non sécurisée

Que sont les vulnérabilités des applications web ?

Les vulnérabilités des applications web sont des faiblesses ou des défauts dans la conception, l'implémentation ou la configuration d'une application web que les attaquants peuvent exploiter pour compromettre le système. Celles-ci peuvent aller des bugs de codage comme les failles d’injection, aux mauvaises configurations comme laisser une console d'administration ouverte, en passant par des problèmes de logique qui permettent aux utilisateurs de contourner les contrôles de sécurité. Certaines vulnérabilités permettent aux attaquants de voler des données ou de prendre le contrôle de comptes utilisateurs ; d'autres permettent une compromission complète du serveur ou la propagation de malwares à vos utilisateurs. Bon nombre des bugs « classiques » sont connus depuis des années (et sont résumés par la liste du Top 10 OWASP), mais ils restent répandus en raison de l'évolution des stacks technologiques et de la simple erreur humaine.

Ci-dessous, nous allons nous pencher sur les principales vulnérabilités des applications web que chaque développeur et équipe DevSecOps devrait connaître. Il ne s'agit pas d'une liste exhaustive de tous les bugs existants, mais plutôt des problèmes les plus courants et les plus dangereux que nous rencontrons actuellement – ainsi que des conseils pour les éviter.

Les principales vulnérabilités des applications web (Frontend et Backend)

Les vulnérabilités suivantes sont tirées du Top 10 OWASP et de récents exploits réels. Chacune représente un risque sérieux pour les applications web. Explorons-les une par une :

1. Attaques par injection (SQL, Commande, LDAP, etc.)

Ce que c'est : Les failles d’injection se produisent lorsque des données non fiables sont envoyées à un interpréteur dans le cadre d'une commande ou d'une requête. Les plus notoires sont l'injection SQL (entrée malveillante dans les requêtes SQL) et l'injection de commandes OS (entrée malveillante exécutée sur le serveur). Lorsqu'une application inclut directement une entrée utilisateur dans des requêtes de base de données, des commandes shell, des requêtes LDAP ou des filtres ORM sans validation appropriée, les attaquants peuvent « injecter » leurs propres commandes. Cela peut entraîner un vol de données, une corruption de données ou une prise de contrôle complète de l'hôte. Selon l'OWASP, l'injection est un risque de premier ordre, et elle englobe désormais le cross-site scripting dans leur classification.

Exemple : Un exemple très médiatisé est la faille de sécurité de MOVEit Transfer en 2023. Des attaquants ont exploité une injection SQL zero-day (CVE-2023-34362) dans l'application web de partage de fichiers MOVEit, leur permettant d'exécuter du code à distance sur le serveur. Le groupe de ransomware Clop a utilisé cette faille pour voler des données à des centaines d'organisations, démontrant comment un seul bug d'injection peut dégénérer en une faille massive. Cet incident a montré que l'injection SQL n'est pas seulement un problème « de la vieille école » – elle est toujours bien vivante et peut être catastrophique.

Impact : Les attaques par injection réussies peuvent être dévastatrices. Une injection SQL peut exfiltrer des mots de passe d'utilisateurs, des dossiers personnels ou des données commerciales. L'injection de commandes OS peut donner à un attaquant un shell sur votre serveur, entraînant une compromission complète de l'infrastructure. En bref, les vulnérabilités par injection entraînent souvent des pertes de données graves, des compromissions de comptes ou l'exécution de code à distance – ce qui en fait une cible privilégiée des attaquants.

Prévention : La clé est de ne jamais mélanger directement des entrées non fiables avec des commandes. Utilisez des requêtes paramétrées ou des instructions préparées pour l'accès aux bases de données (afin que l'interpréteur SQL ne confonde jamais l'entrée avec le code). Pour les commandes OS, évitez de construire des chaînes de commandes ; utilisez des API sécurisées ou mettez sur liste blanche les valeurs attendues. La validation des entrées et l'encodage des sorties sont également des couches défensives importantes. Le SAST (analyse statique du code) basé sur l'IA d'Aikido peut aider à détecter les schémas d'injection dangereux dans votre code avant le déploiement. Par exemple, l'analyse de code d'Aikido signalera les occurrences où l'entrée utilisateur est concaténée dans des instructions SQL ou transmise à des appels système sans assainissement. En intégrant de tels scanners dans votre CI/CD ou votre IDE, vous pouvez automatiquement détecter et corriger les failles d’injection. Avec Aikido, vous auriez pu détecter cette requête SQL vulnérable bien avant les attaquants !

2. Cross-Site Scripting (XSS)

Qu'est-ce que c'est : Le Cross-Site Scripting est un type d'injection ciblant les navigateurs des utilisateurs. Une vulnérabilité XSS permet à un attaquant d'injecter des scripts malveillants côté client (généralement JavaScript) dans des pages web consultées par d'autres utilisateurs. Contrairement aux injections SQL (SQLi) qui ciblent votre base de données, le XSS permet à un attaquant de manipuler le contenu vu par les utilisateurs – potentiellement en volant des jetons de session, en défigurant l'interface utilisateur ou en distribuant des malwares. Le XSS se présente sous différentes formes, telles que le XSS réfléchi (le script malveillant provient d'une requête et est reflété dans la réponse), le XSS stocké (le script est stocké sur le serveur, par exemple dans un champ de commentaire de base de données, et servi à chaque visiteur), et le XSS basé sur le DOM (la vulnérabilité se trouve dans le code côté client qui modifie la page).

Exemple : L'un des incidents XSS les plus célèbres a été la violation de données de British Airways en 2018. Le groupe de hackers Magecart a injecté un script malveillant dans une bibliothèque JS tierce (Feedify) utilisée sur le site web de BA. Ce script a collecté les détails de cartes de crédit depuis la page de paiement, envoyant les données à un serveur contrôlé par l'attaquant. Les attaquants ont réussi à voler des informations personnelles et de cartes de crédit d'environ 380 000 transactions avant que la violation ne soit découverte. En substance, une vulnérabilité XSS dans un composant de la chaîne d'approvisionnement a conduit à un vol de données massif – et à de lourdes amendes pour BA. D'autres exemples concrets de XSS incluent un bug sur une page web de Fortnite qui aurait pu exposer des millions de comptes, et un XSS sur le site d'eBay que des attaquants ont exploité pour détourner des comptes de vendeurs de grande valeur.

Impact : Le XSS compromet principalement les utilisateurs, mais il peut affecter indirectement la sécurité de votre application (et certainement votre réputation). Les attaquants peuvent voler des cookies de session (pour usurper l'identité des utilisateurs), effectuer des actions en tant que victime (comme des transferts de fonds ou des changements de mot de passe si les protections CSRF sont insuffisantes), ou afficher des formulaires de phishing pour tromper les utilisateurs. Si la session d'un utilisateur administrateur est détournée via XSS, l'attaquant peut obtenir le contrôle total de l'application. Même les sites non sensibles devraient se préoccuper du XSS – personne ne veut que son site affiche de fausses invites de connexion ou redirige les utilisateurs vers des kits d'exploitation.

Prévention : Se défendre contre le XSS implique l'encodage de sortie et les politiques de sécurité du contenu. Chaque fois que votre application affiche des données fournies par l'utilisateur sur une page web, elle doit correctement échapper/encoder ces données pour le contexte (HTML, JavaScript, CSS, etc.) afin qu'elles ne puissent pas être interprétées comme du code. La plupart des frameworks web disposent de bibliothèques de templating ou d'encodage – utilisez-les de manière cohérente (évitez de créer du HTML à partir de chaînes brutes). Mettez en œuvre une politique de sécurité du contenu (CSP) robuste pour limiter les scripts pouvant s'exécuter sur vos pages (bien que la CSP soit une deuxième ligne de défense). Le scan de code d'Aikido peut détecter les zones où l'entrée utilisateur est insérée dans la page sans assainissement approprié. Par exemple, si vous utilisez par inadvertance innerHTML ou la concaténation de chaînes pour injecter des données utilisateur dans le DOM, l'analyseur statique d'Aikido le signalera. Aikido peut également identifier les drapeaux HTTP-only manquants ou les en-têtes de politique de sécurité du contenu via son scan de configuration. En détectant ces problèmes tôt, vous prévenez la prochaine attaque de type Magecart contre vos utilisateurs. (Bonus : la base de connaissances intégrée des vulnérabilités d'Aikido peut même suggérer des pratiques de codage sécurisées, comme l'utilisation de textContent plutôt que innerHTML pour éviter le XSS basé sur le DOM.)

3. Authentification défaillante

Qu'est-ce que c'est : L'authentification défaillante fait référence aux faiblesses dans la manière dont un site gère la connexion et la gestion des sessions – des éléments tels que les identifiants utilisateur, les ID de session, la réinitialisation de mot de passe et la récupération de compte. Si des attaquants peuvent facilement compromettre des mots de passe, des clés ou des jetons de session en raison d'une mauvaise implémentation, il s'agit d'une authentification défaillante. Les pièges courants incluent des politiques de mots de passe faibles (ou l'absence de limitation de débit lors de la connexion, permettant la force brute), le défaut de stockage sécurisé des mots de passe (par exemple, stockage en texte clair ou de hachages non salés), l'utilisation d'ID de session prévisibles ou non sécurisés, la non-invalidation des sessions lors de la déconnexion, et une logique de « se souvenir de moi » ou de réinitialisation de mot de passe défectueuse. Toute faille permettant à un attaquant soit d'usurper l'identité de quelqu'un d'autre (en devinant ou en volant des identifiants/sessions), soit de se connecter sans les identifiants appropriés, relève de cette catégorie. Selon OWASP, ces échecs d'authentification peuvent entraîner des prises de contrôle de comptes et des violations de données importantes.

Exemple : Il n'est pas nécessaire de chercher loin pour trouver des exemples – une grande partie des violations proviennent d'identifiants compromis. En fait, 81 % des violations liées au piratage en 2022 étaient dues à des mots de passe faibles ou volés. Un incident spécifique : début 2023, Uber a révélé qu'un compte d'entrepreneur avait été compromis parce que l'entrepreneur avait réutilisé un mot de passe trouvé lors d'une violation antérieure. Les attaquants ont accédé aux systèmes internes d'Uber en utilisant ce compte – il s'agissait essentiellement d'un échec d'authentification (réutilisation de mot de passe et manque de MFA). Autre exemple : une violation en 2024 chez une entreprise de services financiers où l'absence d'authentification multi-facteurs (MFA) a permis aux attaquants d'utiliser des mots de passe divulgués pour accéder à des comptes, affectant des millions de personnes (cela a été noté dans le contexte de l'incident de données client de Snowflake – bien que la plateforme de Snowflake n'ait pas été directement piratée, une authentification faible côté utilisateur a conduit à la violation). Ces cas montrent que même si le code de votre application est solide, des pratiques d'authentification faibles (par les utilisateurs ou les développeurs) peuvent ouvrir grand la porte.

Impact : L'authentification défaillante peut entraîner la compromission complète du compte de tout utilisateur du système – des clients réguliers aux administrateurs. Si un attaquant obtient les identifiants d'un utilisateur (via la force brute, le credential stuffing utilisant des mots de passe divulgués, ou en exploitant une faille dans votre logique d'authentification), il peut usurper l'identité de cet utilisateur et accéder à toutes ses données. C'est particulièrement grave si des comptes administrateur ou privilégiés sont compromis – l'attaquant pourrait voler toutes les données, modifier les paramètres ou pivoter davantage vers les réseaux internes. Même à une échelle plus petite, les comptes utilisateur compromis peuvent entraîner des fraudes, des violations de la vie privée et une perte de confiance des utilisateurs.

Prévention : Des défenses d'authentification robustes sont indispensables. Appliquez des exigences de mots de passe forts et utilisez le hachage (avec un algorithme robuste comme bcrypt ou Argon2) ainsi que le salage pour les mots de passe stockés – ne stockez jamais de mots de passe bruts. Mettez en œuvre l'authentification multi-facteurs (MFA) pour les comptes ou actions sensibles ; la MFA peut contrecarrer de nombreuses attaques basées sur les mots de passe. Utilisez une gestion de session sécurisée : rendez les ID de session aléatoires et imprévisibles, définissez leur expiration et invalidez les sessions lors de la déconnexion. Évitez d'exposer les ID de session dans les URL (utilisez des cookies avec les drapeaux Secure et HttpOnly). Mettez en œuvre une protection contre la force brute (verrouillages ou CAPTCHAs après plusieurs tentatives de connexion échouées) et surveillez le credential stuffing.

‍La plateforme d'Aikido peut vous aider en détectant les faiblesses d'authentification courantes dans votre code et votre configuration. Par exemple, le scanner d'Aikido vous avertira si vous utilisez une méthode de hachage de mot de passe faible (ou pire, si vous stockez des mots de passe en texte clair). Il peut également détecter si les cookies de session ne sont pas marqués Secure/HttpOnly, ou si les paramètres de sécurité de votre framework web (comme ceux de Django ou Express) sont mal configurés pour la gestion des sessions. De plus, la détection de secrets d'Aikido pourrait vous alerter si vous codez accidentellement en dur une clé API ou un mot de passe de compte de service dans votre code (empêchant ainsi ces secrets de devenir une porte dérobée pour un attaquant). En détectant ces problèmes tôt, vous mettez en œuvre un schéma d'authentification plus robuste dès le départ.

4. Contrôle d’accès défaillant (Failles d'autorisation et IDOR)

Qu'est-ce que c'est : Le contrôle d’accès défaillant est actuellement le risque d'application web le plus critique selon OWASP. Il fait référence aux échecs dans l'application de l'autorisation – c'est-à-dire les règles concernant ce que les utilisateurs authentifiés sont autorisés à faire. Même si un utilisateur est bien celui qu'il prétend être (authentification réussie), l'application doit le restreindre aux seules données et fonctions autorisées. Les échecs courants du contrôle d'accès incluent la non-vérification des rôles/permissions des utilisateurs sur certaines actions, la confiance accordée à l'application côté client (que les attaquants peuvent contourner), ou l'exposition de références à des objets internes sans vérification de la propriété. Une variante extrêmement courante est IDOR (Référence directe non sécurisée à un objet), où une application utilise des identifiants fournis par l'utilisateur (tels que les numéros de compte, les identifiants de document, etc.) pour récupérer des données sans confirmer que l'utilisateur actuel est autorisé à accéder à l'objet spécifié. Par exemple, si GET /api/orders/12345 renvoie la commande #12345 pour tout utilisateur qui y accède, un attaquant pourrait simplement modifier l'ID en 12346 et récupérer la commande d'un autre utilisateur – un scénario IDOR classique. D'autres exemples incluent des contrôles d'accès manquants sur des points d'accès administrateur "cachés", ou des failles d'escalade de privilèges où un utilisateur régulier peut devenir administrateur en modifiant un paramètre ou un jeton JWT.

Exemple : La prévalence du contrôle d’accès défaillant est stupéfiante – une étude a révélé que 94 % des applications testées présentaient une forme de faiblesse de contrôle d'accès. Quant aux incidents réels, considérez la vulnérabilité de l'API de Kia Motors (2024) : Des chercheurs ont découvert qu'en fournissant uniquement le numéro VIN ou la plaque d'immatriculation d'une voiture, ils pouvaient appeler certains points d'accès API de Kia/Hyundai et exécuter à distance des commandes de véhicule (comme le déverrouillage des portes), sans aucun jeton d'authentification. Cette faille critique s'est résumée à une défaillance du contrôle d'accès dans une API – le système ne garantissait pas que la requête provenait d'un propriétaire autorisé. Un autre exemple est la faille MOVEit que nous avons mentionnée précédemment : bien que principalement un problème de SQLi, il a été noté qu'un manque d'authentification sur le point d'accès vulnérable permettait aux attaquants de l'exploiter directement. Nous voyons également régulièrement des failles IDOR dans les applications web où un utilisateur peut visualiser ou modifier les données d'un autre : par exemple, une vulnérabilité de 2021 dans l'API d'une plateforme de médias sociaux populaire a permis aux attaquants d'énumérer les identifiants de profil utilisateur pour récupérer des informations de profil privées qui auraient dû être restreintes. En bref, les contrôles d’accès défaillants conduisent souvent à une escalade de privilèges verticale (l'utilisateur devient administrateur) ou une escalade horizontale (l'utilisateur A peut agir comme l'utilisateur B).

Impact : Lorsque le contrôle d'accès est défaillant, les conséquences vont des fuites de données à la prise de contrôle complète du système. Un attaquant pourrait lire les données sensibles d'autres utilisateurs (violant la confidentialité) ou modifier des données qu'il ne devrait pas (violant l'intégrité). Dans les cas graves, le contrôle d’accès défaillant peut permettre à une partie externe d'obtenir des privilèges d'administrateur – ce qui signifie la fin de l'application. Par exemple, une faille IDOR sur un site e-commerce pourrait permettre à quelqu'un de voir les commandes ou les informations personnelles d'autres clients ; un contrôle administrateur manquant pourrait permettre à un utilisateur régulier d'accéder à un /admin/deleteUser point d'accès et d'effacer des données. Ces failles conduisent directement à des violations de confidentialité et sont souvent très faciles à exploiter pour les attaquants une fois découvertes (pas besoin de charges utiles sophistiquées – juste une URL ou un paramètre modifié).

Prévention : Le principe ici est “refuser par défaut.” Chaque requête accédant à une opération sensible ou à un enregistrement de données doit être soumise à des contrôles d'accès côté serveur. Utilisez des frameworks ou des middlewares qui centralisent l'application des rôles/permissions. Par exemple, si vous avez des rôles d'utilisateur, assurez-vous que chaque fonction d'administration vérifie le rôle de l'utilisateur sur le serveur (ne vous fiez jamais uniquement aux contrôles côté client comme le masquage des boutons d'administration dans l'interface utilisateur). Pour l'accès au niveau de l'objet (comme la visualisation ou la modification d'une ressource par ID), implémentez des vérifications de propriété – par exemple, confirmez que le orderId demandé appartient à l'utilisateur authentifié effectuant la requête. Des tests automatisés peuvent aider à vérifier que l'accès non autorisé est correctement bloqué.

‍Aikido vous aide à détecter les contrôles d’accès défaillants de plusieurs manières. Premièrement, le pentest autonome (Aikido Attack) d'Aikido peut sonder dynamiquement votre application en cours d'exécution pour ces failles – par exemple, il peut simuler un attaquant avec un compte utilisateur normal essayant d'accéder aux API d'administration ou aux données d'autres utilisateurs, et il signalera tout contournement de privilèges réussi. Côté code, l'analyse statique d'Aikido peut identifier les routes ou les contrôleurs avec des vérifications d'authentification manquantes (en particulier dans les frameworks où les routes devraient être annotées avec des rôles). Si votre base de code utilise l'infrastructure-as-code ou la configuration pour les politiques d'accès (par exemple, les règles de passerelle API ou l'IAM cloud), les scanners d'Aikido peuvent également les évaluer. En utilisant Aikido pour tester en continu la logique d'autorisation, vous détectez ces erreurs du type "oups, j'ai oublié d'appliquer la connexion sur ce point d'accès" avant les attaquants. N'oubliez jamais : à l'exception des ressources véritablement publiques, tout devrait nécessiter une autorisation appropriée – Aikido peut vous aider à vérifier que vous respectez ce principe.

5. Configurations de sécurité inadéquates

Qu'est-ce que c'est : Même une application parfaitement codée peut être compromise par une configuration non sécurisée. La configuration de sécurité inadéquate est une catégorie large couvrant tout paramètre ou configuration non sécurisé dans l'infrastructure ou la pile d'applications. Cela inclut des éléments tels que : laisser des identifiants par défaut actifs sur les serveurs (par exemple, admin/admin), utiliser des fichiers de configuration ou des secrets par défaut, laisser des points d'accès sensibles (comme les panneaux d'administration de base de données ou les tableaux de bord cloud) accessibles au public, ne pas désactiver les listes de répertoires sur un serveur web, avoir des en-têtes HTTP mal configurés (par exemple, des en-têtes de sécurité manquants), ou oublier de définir les permissions appropriées sur le stockage cloud. Les configurations inadéquates résultent souvent de paramètres de développement/test non renforcés pour la production, ou simplement d'une erreur humaine lors du déploiement. Dans les environnements cloud, une configuration inadéquate classique consiste à laisser un bucket S3 ou un stockage blob Azure lisible publiquement alors qu'il contient des données privées. Essentiellement, c'est lorsque votre système dit "Bienvenue aux attaquants, la porte est ouverte !" en raison d'une négligence dans les paramètres.

Exemple : Malheureusement, les erreurs de configuration sont à l'origine de nombreuses violations de données réelles. Un cas frappant de 2024 : 1,3 million de dossiers de patients ont été exposés sur un serveur public pendant deux semaines en raison d'une simple erreur de configuration de serveur. Aucun exploit n'a été nécessaire – les données ont été essentiellement publiées au monde entier à cause d'une négligence. Autre exemple : un incident chez Prudential Financial (2024) où une seule erreur de configuration dans un système de contrôle d'accès a permis aux attaquants d'accéder discrètement à 2,5 millions de dossiers clients. Et qui peut oublier la violation de données de Capital One (2019) – bien qu'elle ait impliqué le SSRF comme mécanisme d'attaque, la cause profonde était un pare-feu applicatif web mal configuré dans leur environnement AWS, ce qui a permis à l'attaquant d'atteindre des ressources internes. Dans le cas de Capital One, un compartiment de stockage AWS S3 contenant des données sensibles était accessible une fois la mauvaise configuration du WAF exploitée – entraînant le vol de plus de 100 millions de dossiers clients. Ces exemples soulignent que de « petites » erreurs de configuration (comme un port ouvert, une accréditation oubliée ou un contrôle de sécurité désactivé) peuvent souvent avoir des conséquences énormes.

Impact : l'impact varie en fonction de ce qui a été mal configuré. Dans le meilleur des cas, une mauvaise configuration peut « seulement » entraîner la fuite d'informations non critiques (par exemple, une page d'erreur détaillée révélant les versions logicielles, utile pour les pirates mais ne constituant pas en soi une violation). Dans le pire des cas, une mauvaise configuration peut conduire directement à une compromission totale : une interface d'administration ouverte peut permettre aux pirates de se connecter (en particulier si les identifiants par défaut n'ont pas été modifiés), un compartiment cloud ouvert peut exposer des millions d'enregistrements, ou un paramètre de sécurité désactivé peut permettre des exploits triviaux. Les mauvaises configurations sont l'une des principales causes de violations de données dans cloud . Elles sont également faciles à détecter par les pirates : il existe des moteurs de recherche et des robots qui recherchent en permanence des éléments tels que des tableaux de bord Elasticsearch/Kibana ouverts, des ports de base de données exposés ou des compartiments publics. En bref, les erreurs de configuration peuvent transformer votre application sécurisée en « terrain de jeu pour les pirates » si vous ne faites pas attention.
‍
Prévention : la diligence et l'automatisation sont essentielles. Modifiez toujours les mots de passe et les clés par défaut (rien ne doit fonctionner avec « admin/admin » ou des valeurs par défaut similaires). Renforcez les configurations de votre serveur et de votre infrastructure : par exemple, désactivez les modes de débogage et les applications d'exemple en production, assurez-vous que la navigation dans les répertoires est désactivée et appliquez les en-têtes de sécurité recommandés (Content Security Policy, X-Frame-Options, etc.). Appliquez le principe du moindre privilège pour cloud : si un service ou un compartiment ne nécessite pas d'accès public, verrouillez-le (et pour ceux qui doivent être publics, assurez-vous qu'ils n'exposent que ce qui est prévu). Vérifiez régulièrement votre infrastructure en tant que code ou vos paramètres d'environnement par rapport aux normes de sécurité.

analyse IaC l'audit de configurationAikidopeuvent s'avérer très utiles dans ce cas. Si vous utilisez Terraform, CloudFormation, Kubernetes YAML ou un outil similaire, Aikido les analyser pour détecter les paramètres non sécurisés (tels que les groupes de sécurité ouverts, les compartiments S3 publics ou les paramètres de chiffrement manquants). Il peut également vérifier votre cloud en cours d'exécution pour détecter les erreurs de configuration. Pour les serveurs web et les applications, les scanners Aikidosignaleront les en-têtes de sécurité manquants ou les messages d'erreur trop détaillés. De plus, Aikidoprotection en temps d’exécution peuvent surveiller les utilisations anormales qui pourraient indiquer qu'une personne exploite une erreur de configuration. La conclusion est d'intégrer les vérifications de configuration à votre pipeline. Aikido automatiser cette tâche et détecter les erreurs du type « oups, j'ai laissé ce compartiment public » avant le déploiement. Et gardez toujours un œil sur les nouveaux correctifs et mises à jour ; parfois, les erreurs de configuration proviennent de l'exécution de logiciels obsolètes présentant des faiblesses par défaut connues.

6. exposition de données sensibles fuite de secrets

Description : cette catégorie couvre les défaillances dans la protection des informations sensibles, qu'il s'agisse des données utilisateur ou des clés secrètes.exposition de données sensibles(également appelée défaillance cryptographique) signifie qu'une application ne sécurise pas correctement les données en transit ou au repos. Parmi les exemples, on peut citer le fait de ne pas utiliser le protocole HTTPS pour les communications sensibles, d'utiliser un cryptage faible ou inexistant pour les données stockées (comme des hachages non salés pour les mots de passe ou des données personnelles en clair dans une sauvegarde de base de données), ou d'exposer accidentellement des données lors du débogage ou dans les journaux. La fuite de secrets est étroitement liée à cela : elle se produit lorsque les développeurs exposent involontairement des informations si vous ne faites pas attention.

Prévention : la diligence et l'automatisation sont essentielles. Modifiez toujours les mots de passe et les clés par défaut (rien ne doit fonctionner avec « admin/admin » ou des valeurs par défaut similaires). Renforcez les configurations de votre serveur et de votre infrastructure : par exemple, désactivez les modes de débogage et les applications d'exemple en production, assurez-vous que la navigation dans les répertoires est désactivée et appliquez les en-têtes de sécurité recommandés (Content Security Policy, X-Frame-Options, etc.). Appliquez le principe du moindre privilège pour cloud : si un service ou un compartiment ne nécessite pas d'accès public, verrouillez-le (et pour ceux qui doivent être publics, assurez-vous qu'ils n'exposent que ce qui est prévu). Vérifiez régulièrement votre infrastructure en tant que code ou vos paramètres d'environnement par rapport aux normes de sécurité.

analyse IaC l'audit de configurationAikidopeuvent s'avérer très utiles dans ce cas. Si vous utilisez Terraform, CloudFormation, Kubernetes YAML ou un outil similaire, Aikido les analyser pour détecter les paramètres non sécurisés (tels que les groupes de sécurité ouverts, les compartiments S3 publics ou les paramètres de chiffrement manquants). Il peut également vérifier votre cloud en cours d'exécution pour détecter les erreurs de configuration. Pour les serveurs web et les applications, les scanners Aikidosignaleront les en-têtes de sécurité manquants ou les messages d'erreur trop détaillés. De plus, Aikidoprotection en temps d’exécution peuvent surveiller les utilisations anormales qui pourraient indiquer qu'une personne exploite une erreur de configuration. La conclusion est d'intégrer les vérifications de configuration à votre pipeline. Aikido automatiser cette tâche et détecter les erreurs du type « oups, j'ai laissé ce compartiment public » avant le déploiement. Et gardez toujours un œil sur les nouveaux correctifs et mises à jour ; parfois, les erreurs de configuration proviennent de l'exécution de logiciels obsolètes présentant des faiblesses par défaut connues.

6. exposition de données sensibles fuite de secrets

Description : cette catégorie couvre les défaillances dans la protection des informations sensibles, qu'il s'agisse des données utilisateur ou des clés secrètes.exposition de données sensibles(également appelée défaillance cryptographique) signifie qu'une application ne sécurise pas correctement les données en transit ou au repos. Parmi les exemples, on peut citer le fait de ne pas utiliser le protocole HTTPS pour les communications sensibles, d'utiliser un cryptage faible ou inexistant pour les données stockées (comme des hachages non salés pour les mots de passe ou des données personnelles en clair dans une sauvegarde de base de données), ou d'exposer accidentellement des données par le biais du débogage ou des journaux. La fuite de secrets est étroitement liée à cela : elle se produit lorsque les développeurs exposent par inadvertance des secrets tels que des clés API, des mots de passe de base de données, des identifiants ou des jetons, que ce soit en les codant en dur dans le code, en les laissant dans des fichiers de configuration poussés vers des dépôts ou en les stockant dans le code côté client. Chaque année, une quantité impressionnante de secrets est divulguée par les développeurs (souvent sur le GitHub public). En bref, si votre application ne crypte pas correctement ce qui doit l'être, ou si vous ne prenez pas soin des informations confidentielles et des clés, vous invitez les pirates à obtenir ces données sans trop d'efforts.

Exemple : l'un des aspects de ce problème concerne les données non cryptées. Voici un exemple simple mais parlant : il y a plusieurs années, les sites web acceptaient parfois les identifiants de connexion via un protocole HTTP non sécurisé. Cette pratique a aujourd'hui largement disparu, mais des erreurs persistent. En 2023, une importante intégration API a été découverte, transmettant des données de santé personnelles sans cryptage approprié (en raison d'une chaîne de certificats TLS mal configurée), exposant ainsi des informations privées sur le réseau. Autre exemple : si un fichier de sauvegarde de base de données est stocké dans un cloud non sécurisé (en raison d'une mauvaise configuration), toutes les données personnelles qu'il contient peuvent être exposées. C'est ce qui est arrivé à une compagnie aérienne en 2022, qui a divulgué des centaines de milliers de dossiers clients parce que la sauvegarde n'était pas cryptée et ne faisait l'objet d'aucun contrôle d'accès.

Du côté des secrets, le problème est endémique. Rien qu'en 2024, les chercheurs ont détecté près de 23,8 millions de nouveaux secrets codés en dur dans les commits publics GitHub, soit une augmentation de 25 % par rapport à l'année précédente. Cette « prolifération des secrets » a conduit à de réelles violations. Par exemple, en 2023, un pirate a divulgué tout le code source du New York Times à partir d'un dépôt privé, apparemment en exploitant des identifiants divulgués. Dans un autre cas, une société de veille économique (Sisense) a vu ses identifiants internes divulgués sur un forum public, que des pirates ont utilisés pour accéder à des données sensibles sur les clients. Plus près de chez nous, pour les développeurs : combien de fois avons-nous entendu parler d'une clé secrète AWS accidentellement poussée vers GitHub, pour être utilisée en quelques minutes par des crypto-mineurs ou pire encore ? Ces exemples montrent que le fait de ne pas protéger les données par cryptage et de ne pas préserver la confidentialité des secrets peut conduire directement à des violations de données et à des accès non autorisés.

Impact : si des données sensibles des utilisateurs (informations personnelles, données financières, dossiers médicaux, etc.) sont exposées, l'impact se fait généralement sentir à la fois pour les utilisateurs (violation de la vie privée, risque d'usurpation d'identité) et pour l'entreprise (sanctions réglementaires, atteinte à la réputation). Par exemple, l'exposition de dossiers médicaux peut entraîner des amendes et des poursuites judiciaires en vertu de la loi HIPAA. L'exposition de mots de passe ou de numéros de carte de crédit conduit évidemment à des fraudes. Parallèlement, la divulgation de secrets (tels que des clés API ou des jetons) peut être un véritable trésor pour un pirate : par exemple, la divulgation d'un mot de passe de base de données pourrait permettre à un pirate de se connecter et de vider l'intégralité de votre base de données ; la divulgation d'une clé cloud pourrait lui permettre de lancer des serveurs (à vos frais) ou d'accéder à cloud sensibles. Une seule fuite d'identifiant administrateur peut parfois compromettre l'ensemble d'une application, voire un parc de systèmes. Il n'est donc pas surprenant que le rapport IBM sur le coût des violations de données constate régulièrement que les violations impliquant des identifiants compromis et des données sensibles sont parmi les plus coûteuses (tant en termes financiers qu'en termes de perte de confiance).

Prévention : il y a deux aspects à prendre en compte ici : protéger les données sensibles et gérer correctement les secrets. Pour les données sensibles des utilisateurs/entreprises, utilisez toujours le protocole HTTPS (appliquez le protocole TLS à tout le trafic et utilisez des protocoles/configurations modernes). Ne transmettez jamais d'informations sensibles telles que des mots de passe ou des jetons en texte clair, même dans les communications internes. Au repos, cryptez les champs de données critiques (de nombreuses bases de données et services cloud offrent un cryptage au repos : utilisez-le et envisagez un cryptage au niveau de l'application pour les champs extrêmement sensibles). Évitez l'exposition excessive des données : ne stockez pas inutilement des données dont vous n'avez pas besoin et purgez les données sensibles lorsqu'elles ne sont plus nécessaires. En ce qui concerne la gestion des secrets : ne codifiez jamais de secrets dans le code ou la configuration qui vont au contrôle de source. Utilisez des variables d'environnement, des services de gestion des secrets (tels que HashiCorp Vault ou des magasins cloud ), ou au moins stockez les secrets dans des fichiers de configuration sécurisés qui ne se trouvent pas dans le dépôt. Si vous devez valider certaines configurations, utilisez des outils pour rechercher les secrets avant de les pousser. Faites tourner les clés régulièrement afin que, en cas de fuite, elles ne soient valables que pendant une courte période.

La plateforme de sécuritéAikidodispose de fonctionnalités puissantes pour aider sur ces deux fronts. Sa détection de secrets analyse votre code et votre configuration à la recherche de clés API, mots de passe, certificats privés et autres identifiants. Par exemple, si quelqu'un laisse accidentellement une clé AWS ou une chaîne de connexion à une base de données dans un fichier validé, Aikido le Aikido immédiatement, vous évitant ainsi une éventuelle prise de contrôle de votre compte AWS. Aikido même surveiller vos référentiels en continu afin de détecter les fuites de secrets en temps réel. En matière de protection des données, l'analyse Aikidopermet d'identifier les faiblesses en matière de cryptographie (comme l'utilisation de fonctions de hachage ou d'algorithmes de chiffrement obsolètes). Elle permet également de vérifier certaines conformités (par exemple, en s'assurant que le protocole TLS est activé sur tous les points de terminaison en analysant l'infrastructure en tant que code ou les définitions d'API). En intégrant Aikido, vous bénéficiez d'un gardien automatisé qui vous avertit « Attention, c'est une clé API, supprimez-la ! » avant même qu'elle n'atteigne la production. Et si votre organisation compte de nombreux référentiels privés ou équipes de développeurs, ce type d'analyse automatisée des secrets est essentiel, comme en témoigne le nombre toujours croissant de secrets découverts dans le code chaque année.

7. Utilisation de composants présentant des vulnérabilités connues (risques liés à la chaîne d'approvisionnement)

De quoi s'agit-il ? Les applications web modernes sont construites à partir d'innombrables composants tiers : frameworks, bibliothèques, paquets, images de conteneurs et services. Utiliser des composants présentant des vulnérabilités connues signifie que votre application inclut une dépendance (ou s'exécute sur un serveur) qui présente une faille de sécurité connue du public, et que vous n'avez pas corrigée ni mise à jour. Il s'agit essentiellement d'un problème de « chaîne d'approvisionnement » : une vulnérabilité dans une bibliothèque que vous utilisez peut compromettre votre application , même si votre propre code est parfait. Les exemples abondent : une version vulnérable d'un framework web, une bibliothèque OpenSSL obsolète, un outil de débogage présentant des fuites, etc. Les pirates recherchent activement les applications utilisant des versions vulnérables spécifiques de logiciels afin de les exploiter. Top 10 OWASP mis l'accent sur ce risque (auparavant « Utilisation de composants présentant des vulnérabilités connues », désormais intégré dans une catégorie plus large en 2021), et le secteur a tiré de dures leçons d'incidents tels que Log4Shell, où une seule faille dans une bibliothèque a eu un effet domino à l'échelle mondiale.

Exemple : Le cas le plus emblématique est sans conteste Log4Shell (CVE-2021-44228). Il s'agissait d'une vulnérabilité RCE critique dans la bibliothèque de journalisation Log4j (largement utilisée dans les applications Java). Lorsqu'elle a été révélée en décembre 2021, elle a déclenché une vague d'inquiétude partout dans le monde, car des milliers d'applications étaient indirectement vulnérables si elles incluaient une certaine version de Log4j. Les pirates ont rapidement commencé à l'exploiter, provoquant des incidents dans de nombreuses entreprises. Comme l'indique un rapport, « la vulnérabilité Log4j a démontré comment un seul composant largement utilisé peut exposer l'ensemble d'une organisation ». Autre exemple : Apache Struts 2 présentait une faille RCE connue (CVE-2017-5638) qui a conduit à la célèbre violation d'Equifax en 2017. Equifax n'avait pas mis à jour le framework et les pirates l'ont exploité pour voler les données de 147 millions de personnes. Plus récemment, en 2022-2023, nous avons vu apparaître Spring4Shell (CVE-2022-22965), une vulnérabilité du framework Spring qui faisait écho à Log4Shell (bien que moins grave), ainsi que diverses vulnérabilités des paquets npm/PyPI qui permettaient aux pirates d'exécuter du code ou de voler des données si vous utilisiez ces paquets. Même les bibliothèques frontales ne sont pas épargnées : par exemple, une vulnérabilité dans la bibliothèque DOMPurify en 2021 pouvait compromettre protection contre les XSS elle n'était pas mise à jour. Tout cela montre que les CVE connus dans votre pile sont des bombes à retardement.

Impact : l'impact dépend entièrement de la vulnérabilité spécifique du composant, mais il peut être très grave : exécution de code à distance, fuite de données, contournement de l'authentification, etc. Le problème est que ces vulnérabilités sont connues de tous et que le code d'exploitation est souvent facilement accessible, ce qui permet aux pirates d'automatiser les analyses pour trouver tous les serveurs qui n'ont pas été corrigés. Un seul composant non corrigé peut entraîner une compromission massive s'il est susceptible d'être infecté par un ver (comme ce fut le cas avec les vulnérabilités MS Exchange ProxyShell/ProxyLogon en 2021 – il ne s'agissait pas exactement d'une « application web », mais le concept était similaire, à savoir l'exploitation massive de vulnérabilités connues). Pour votre application, l'utilisation d'un composant vulnérable peut signifier qu'un pirate n'a pas besoin de trouver un bug dans votre code, il lui suffit d'exploiter la bibliothèque. Le résultat peut être le même que pour les autres catégories : violation de données, prise de contrôle du serveur, etc., mais c'est particulièrement frustrant car un correctif était peut-être disponible et n'a tout simplement pas été appliqué.

Prévention : Cela revient à gestion des dépendances et discipline en matière de correctifs. Maintenez un inventaire de tous les composants (y compris leurs versions) utilisés dans votre application – c'est souvent appelé un Software Bill of Materials (SBOM). Abonnez-vous à des flux de vulnérabilités ou utilisez des outils automatisés pour vous alerter lorsqu'une bibliothèque que vous utilisez présente une CVE connue. De nombreux gestionnaires de paquets disposent de commandes d'audit (par exemple, audit npm, audit pip) pour identifier les vulnérabilités connues dans votre arborescence de dépendances. Maintenez vos dépendances à jour : effectuez rapidement les mises à niveau vers les versions corrigées. Dans la mesure du possible, utilisez des outils pour appliquer des correctifs virtuels ou des solutions de contournement si vous ne pouvez pas effectuer immédiatement la mise à niveau. Pour les composants tels que votre système d'exploitation, votre serveur web ou votre serveur de base de données, appliquez régulièrement les mises à jour de sécurité. Méfiez-vous également des paquets malveillants Dans l'écosystème open source, il arrive parfois que des pirates publient une bibliothèque compromise (ou détournent le compte d'un responsable de maintenance) afin que la prochaine fois que vous npm install, vous risquez d'installer une mise à jour piratée. Utiliser des sources fiables et verrouiller les versions des dépendances (et vérifier leur intégrité à l'aide de sommes de contrôle/signatures) peut aider à atténuer ce risque.

Aikido considérablement la gestion de ce risque grâce à ses analyse des dépendances analyse de la composition logicielle SCA) et analyse des dépendances . Le scanner de dépendances (SCA) Aikidodétecte automatiquement les bibliothèques open source et les versions utilisées par votre code, les compare aux bases de données de vulnérabilités et vous alerte en cas de CVE connues. Par exemple, si votre projet utilise Log4j 2.14.0 (qui est vulnérable à Log4Shell), Aikido le Aikido avec des détails sur le CVE et vous suggérera même la version corrigée vers laquelle vous devriez effectuer la mise à niveau. Il peut le faire directement dans votre IDE ou votre pipeline CI. Mieux encore, Aikido correction automatique par IA : dans de nombreux cas, il peut automatiquement ouvrir une pull request pour passer à une version plus sûre ou appliquer un correctif nécessaire. La plateforme peut également analyser les images de conteneurs à la recherche de composants obsolètes (en s'assurant que vos images de base et vos paquets OS sont à jour). En intégrant Aikido, vous externalisez essentiellement la tâche fastidieuse de suivi des CVE à un système automatisé qui ne dort jamais. Cela signifie une remédiation plus rapide, ce qui est essentiel lorsque les exploits sont souvent actifs quelques jours ou quelques heures après l'annonce d'une vulnérabilité. En résumé : gardez tout à jour et utilisez des outils tels que Aikido SCA pour garder une longueur d'avance sur les attaquants en matière de composants.

8. Falsification de requêtes intersites (CSRF)

De quoi s'agit-il ? La falsification de requêtes intersites (Cross-Site Request Forgery) est une attaque dans laquelle un site web malveillant incite le navigateur d'un utilisateur à envoyer des requêtes non intentionnelles à votre application web. Elle exploite le fait que les navigateurs incluent automatiquement des informations d'identification (telles que des cookies de session) dans les requêtes. Si un utilisateur est connecté à votre site et visite ensuite un site malveillant, ce dernier pourrait, par exemple, charger une image ou un formulaire caché qui envoie une requête à votre site (la cible) – et le navigateur inclura le cookie de session de l'utilisateur. Sans défense appropriée, votre serveur considère que l'utilisateur a légitimement effectué cette requête et l'exécutera. En substance, le CSRF « détourne » la session authentifiée d'un utilisateur pour effectuer une action que l'utilisateur n'avait pas l'intention d'effectuer. Exemple classique : un utilisateur est connecté à sa banque. Il visite la page d'un pirate qui contient un code caché qui envoie une demande de transfert de fonds au site de la banque. La banque voit un cookie de session valide et traite le transfert. Le CSRF ne vole pas directement les données, il incite le navigateur de la victime à devenir le complice du pirate. De nombreux frameworks modernes intègrent des protections CSRF (généralement via des jetons), et les navigateurs modernes ont ajouté des attributs de cookie SameSite pour atténuer le CSRF, mais celui-ci est loin d'être éradiqué. En 2025, le CSRF n'est « pas mort, juste différent », en particulier avec les applications monopages et les API utilisant des cookies pour l'authentification, où les développeurs peuvent oublier de mettre en œuvre les protections habituelles.

Exemple : un cas réel : Reddit (2023) présentait une vulnérabilité CSRF sur une page de paramètres qui permettait aux pirates de modifier discrètement les préférences d'un utilisateur et même de lier le compte de la victime à un compte de spam. Bien que la modification des préférences de notification ne soit pas aussi grave que les transferts d'argent, cela montre que le CSRF était présent dans les fonctionnalités d'un site majeur. Un autre exemple notable concerne les applications de portefeuille de cryptomonnaie: des pirates ont utilisé le CSRF pour modifier les adresses de paiement par défaut ou initier de petites transactions en exploitant l'interface web du portefeuille, vidant ainsi efficacement les fonds sans que l'utilisateur ne s'en rende compte. Historiquement, il y a eu des attaques CSRF encore plus dévastatrices : Gmail a subi une attaque CSRF en 2007 qui a permis à des pirates de modifier les adresses de transfert des e-mails des utilisateurs (espionnage des e-mails), et il y a eu le célèbre ver Samy sur MySpace en 2005, qui était en fait un CSRF auto-propagateur (combiné à un XSS) qui a permis au profil de Samy Kamkar d'accumuler un million d'« amis ». Ces exemples vont de simples méfaits à des violations importantes, mais tous soulignent la même idée : si vous ne disposez pas de protections CSRF, un attaquant peut amener vos utilisateurs à effectuer des actions qu'ils n'avaient pas l'intention de faire.

Impact : la gravité d'une attaque CSRF dépend des actions vulnérables. Si seules quelques modifications mineures des préférences sont possibles (comme dans l'exemple Reddit), l'impact est limité (gênant, mais pas catastrophique). Mais si des actions critiques telles que les transferts d'argent, les changements de mot de passe ou les suppressions de compte sont vulnérables, alors une attaque CSRF est très grave. Prenons l'exemple d'une attaque CSRF qui modifie le mot de passe d'un utilisateur connecté pour le remplacer par un mot de passe connu de l'attaquant : il s'agit là d'une prise de contrôle totale du compte. Ou encore, une attaque CSRF sur une application bancaire en ligne qui effectue un paiement : il s'agit là d'un vol financier direct. Dans un contexte d'entreprise, une attaque CSRF qui déclenche un changement d'état (comme la modification d'un paramètre de contrôle d'accès ou l'injection de données malveillantes) pourrait être un tremplin vers une compromission plus profonde. La nature silencieuse du CSRF (aucun logiciel malveillant sur l'ordinateur de l'utilisateur, aucun signe extérieur immédiat) signifie que de telles attaques peuvent passer inaperçues jusqu'à ce qu'il soit trop tard.

Prévention : la bonne nouvelle, c'est que le CSRF est bien compris et qu'il existe des moyens de défense standard :

• Jetons CSRF : implémentez des jetons anti-CSRF pour les requêtes modifiant l'état. Le serveur génère un jeton aléatoire, le définit dans la session de l'utilisateur (ou sous forme de cookie) et l'injecte également dans les formulaires ou les API (sous forme de champ ou d'en-tête caché). Lorsqu'une requête arrive, le serveur attend le jeton et le vérifie. La requête falsifiée d'un pirate ne comportera pas le jeton correct et sera donc rejetée.
• Attribut de cookie SameSite : Configurez vos cookies de session avec SameSite=Lax ou Strict. Cela permet d'empêcher le navigateur d'inclure des cookies dans les requêtes intersites (bien que Lax cela autorise toujours certaines requêtes GET – qui idéalement ne devraient pas avoir d'effets secondaires). De nombreux frameworks définissent désormais les cookies de session par défaut sur SameSite=Lax. Soyez juste prudent si votre application a légitimement besoin de requêtes intersites (par exemple, des intégrations tierces) – vous pourriez avoir besoin d'exceptions, mais isolez-les si c'est le cas.
• Assurez-vous que les actions modifiant l'état utilisent les verbes HTTP appropriés (par exemple, utilisez POST/PUT/DELETE, et non GET, pour les actions). Les navigateurs n'enverront pas de credentials sur un POST intersite si SameSite est Lax ou Strict, et il est plus difficile pour un attaquant de faire un POST caché qu'un GET.
• Vérifiez les en-têtes Origin/Referer : En tant que couche supplémentaire, vérifier que les requêtes proviennent de votre domaine attendu peut détecter les tentatives intersites dans certains cas (bien que ce ne soit pas infaillible).
• Sécurité du framework : Utilisez le middleware de protection CSRF intégré à votre framework – presque tous les frameworks modernes en ont un.
• Ne le désactivez pas pendant le développement (les développeurs désactivent parfois les vérifications CSRF pour tester les API et oublient ensuite de les réactiver).

Aikido peut vous aider à vous assurer que votre application n'est pas involontairement vulnérable aux attaques CSRF. D'une part, l'analyse dynamique (DAST) d'Aikido peut simuler des attaques CSRF en tentant d'effectuer des actions modifiant l'état depuis un contexte externe et en vérifiant si elles réussissent. Il signalera toute action qui manque de protection CSRF appropriée. Côté code, l'analyse statique d'Aikido (avec sa compréhension des frameworks) peut identifier les routes qui modifient les données mais n'ont pas de vérification de jeton CSRF en place. (En fait, des outils comme Ghost Security – un outil AppSec similaire – annoncent spécifiquement la détection d'« endpoints qui mutent l'état mais manquent de jetons CSRF », et Aikido offre des capacités comparables.) Aikido peut également détecter les attributs SameSite mal configurés en inspectant les en-têtes Set-Cookie dans vos réponses ou vos configurations de sécurité. En utilisant Aikido pour tester vos formulaires et vos endpoints d'API, vous serez alerté si un chemin critique manque de défenses CSRF, afin que vous puissiez le corriger (généralement en ajoutant le jeton ou les vérifications d'en-tête appropriés). Grâce à ces mesures, vous pouvez efficacement éliminer les attaques CSRF – en vous assurant que votre application ne honore que les requêtes qui proviennent réellement de votre site et de vos utilisateurs.

9. Server-Side Request Forgery (SSRF)

Qu'est-ce que c'est : Le SSRF est un ajout plus récent au Top 10 OWASP (il est devenu un élément du Top 10 dans l'édition 2021) et ce, pour de bonnes raisons. Server-Side Request Forgery se produit lorsqu'une application prend une URL ou un emplacement de ressource d'une source non fiable (comme une entrée utilisateur) et que le code côté serveur récupère cette URL sans validation appropriée. Essentiellement, un attaquant trompe votre serveur pour qu'il envoie une requête en son nom. Cela peut être exploité pour que le serveur effectue des requêtes vers des ressources internes que l'attaquant ne peut pas atteindre directement, ou vers des adresses externes en utilisant les identifiants du serveur. Un scénario classique est une application web dotée d'une fonctionnalité comme « récupérer le contenu de cette URL » (pour la prévisualisation ou l'importation de données) – un attaquant fournit alors une URL telle que http://localhost/admin ou une URL de métadonnées AWS (http://169.254.169.254) pour récupérer des informations internes sensibles via votre serveur. Le SSRF peut également permettre le balayage de ports de votre réseau interne via votre serveur, voire l'exploitation de services internes. Dans les environnements cloud, le SSRF est particulièrement dangereux car les instances cloud ont souvent accès à des points de terminaison de métadonnées qui fournissent des identifiants. La violation de données de Capital One en 2019 a été un excellent exemple de SSRF utilisé en situation réelle (combiné à une mauvaise configuration).

Exemple : La violation de données de Capital One : Une ancienne ingénieure AWS a exploité une vulnérabilité SSRF dans un WAF (pare-feu applicatif) mal configuré utilisé par Capital One. En élaborant des requêtes depuis une application web accessible de l'extérieur, elle a pu interroger le service de métadonnées AWS du serveur, qui a renvoyé des jetons d'accès AWS. En utilisant ces jetons, elle a ensuite accédé à des données sensibles (des buckets S3 contenant des informations client) – ce qui a entraîné le vol de plus de 100 millions d'enregistrements. En résumé, le SSRF a été le point d'entrée initial qui a contourné les barrières du réseau externe en tirant parti des privilèges propres au serveur. Autre exemple : en 2022, des chercheurs en sécurité ont découvert qu'un SSRF dans un outil DevOps populaire leur permettait d'atteindre des points de terminaison d'API internes non exposés autrement, permettant potentiellement des actions d'administration. Nous avons également observé des failles SSRF dans les fonctionnalités de traitement d'images ou de génération de PDF (où le serveur récupère une URL à partir d'une entrée) que les attaquants ont transformées en scanners de ports ou utilisées pour atteindre des consoles d'administration de bases de données internes. Un autre cas encore : certains services cloud présentaient des SSRF dans leurs webhooks, ce qui a permis aux attaquants de déclencher des requêtes vers des points de terminaison HTTP internes, obtenant ainsi l'accès à des éléments comme Redis ou des tableaux de bord internes.

Impact : À première vue, le SSRF consiste à effectuer des requêtes, ce qui peut sembler limité. Mais il peut avoir un impact critique :

• Accès au réseau interne : Si votre serveur peut atteindre des hôtes internes (par exemple, dans le même VPC ou centre de données), un SSRF peut potentiellement communiquer avec des services internes qui ne sont pas exposés publiquement. Cela pourrait conduire à la lecture de données sensibles (comme contacter une API HTTP interne qui renvoie des informations client) ou même à l'émission de commandes privilégiées si une interface d'administration interne manque d'authentification (car elle supposait que seuls les appels internes l'atteindraient).
• Fuite de métadonnées cloud : Chez les fournisseurs cloud (AWS, GCP, Azure), le SSRF est souvent utilisé pour récupérer des identifiants du service de métadonnées d'instance. Ces identifiants pourraient permettre une compromission supplémentaire des ressources cloud (comme dans le cas de Capital One).
• Contournement des restrictions basées sur l'IP : Si vous restreignez certaines fonctionnalités, par exemple, aux requêtes provenant de « localhost » ou de certaines adresses IP, un SSRF pourrait contourner cela en effectuant la requête depuis le serveur local lui-même.
• Potentiel de propagation (worm) : Dans certains cas, le SSRF peut être un point de pivot pour d'autres exploits – par exemple, un SSRF vers un service interne présentant une RCE connue pourrait entraîner une exécution de code à distance réelle sur le réseau interne.
  Compte tenu de la note de l'OWASP, les problèmes de SSRF sont effectivement en augmentation dans les applications modernes en raison des microservices et des complexités du cloud, et ils peuvent être assez graves.

Prévention : La prévention du SSRF implique principalement de valider et nettoyer toutes les URL fournies par l'utilisateur ou les requêtes de ressources distantes. Si votre application doit récupérer une URL fournie par un utilisateur (ou une adresse), implémentez une liste blanche stricte : par exemple, n'autorisez que les URL provenant d'un ensemble de domaines de confiance (et appliquez cela via la résolution DNS, etc., pour éviter les ruses). Ne permettez jamais à une entrée utilisateur brute de contrôler directement la destination des récupérations côté serveur. Vous pouvez également implémenter des protections au niveau du réseau : par exemple, désactivez la capacité de votre serveur à atteindre des adresses internes s'il n'en a pas besoin. Certains fournisseurs cloud vous permettent de désactiver ou de restreindre l'accès au service de métadonnées (AWS dispose d'IMDSv2 qui atténue les requêtes GET simples). De plus, le code devrait vérifier le schéma d'URL – interdire file:// les URI ou autres schémas locaux, et potentiellement interdire les littéraux IP ou les adresses link-local. Utilisez des bibliothèques ou des correctifs qui assurent la protection SSRF si disponibles (par exemple, certaines bibliothèques clientes HTTP permettent de restreindre les hôtes qui peuvent être contactés). Essentiellement, traitez les URL fournies de l'extérieur comme des entrées dangereuses – car elles le sont.

Les outils de scan d'Aikido peuvent aider à identifier les risques SSRF dans votre code. Par exemple, l'analyse statique d'Aikido peut détecter l'utilisation de fonctions ou de bibliothèques qui effectuent des requêtes HTTP (comme requests.get() en Python, HttpClient en Java, etc.) où l'URL est dérivée d'une entrée utilisateur. Il peut alors signaler cela comme un SSRF potentiel s'il n'y a pas de filtrage. Aikido peut également détecter si votre code tente de récupérer des éléments à partir d'URL sans validation, et il peut suggérer d'ajouter des vérifications de liste blanche. Côté dynamique, Les outils DAST et de pentest d'Aikido peuvent tenter des charges utiles SSRF courantes (comme fournir http://169.254.169.254 comme entrée à toute fonctionnalité de récupération d'URL) pour voir s'ils peuvent tromper le serveur afin qu'il réponde avec du contenu interne. Si un vecteur SSRF est trouvé, Aikido le signalera avec des preuves. Grâce à ce retour, vous pourrez alors implémenter une validation appropriée ou restreindre l'accès au réseau. Les fonctionnalités de scan cloud d'Aikido peuvent également vous avertir si vos instances ont des paramètres réseau trop permissifs (par exemple, si votre serveur web peut sortir vers internet ou le réseau interne alors qu'il ne devrait pas). En combinant l'analyse de code et les tests, vous pouvez détecter les faiblesses SSRF tôt – avant qu'un attaquant n'utilise votre application comme son proxy.

10. Désérialisation Insecure

Qu'est-ce que c'est : La désérialisation insecure est une vulnérabilité plus spécialisée, mais incroyablement dangereuse lorsqu'elle est présente. Elle survient lorsqu'une application désérialise des données provenant d'une source non fiable sans validation appropriée – ce qui signifie qu'il prend des données binaires ou structurées (comme des objets, du JSON/XML, ou des blobs binaires) du client et reconstruit un objet en mémoire. Certains formats de sérialisation (en particulier dans des langages comme Java, .NET, Python, PHP) peuvent être exploités pour exécuter du code pendant le processus de désérialisation. Les attaquants conçoivent des objets sérialisés malveillants (souvent appelés « gadget chains ») qui, lorsque le serveur les désérialise, déclenchent des commandes ou des comportements choisis par l'attaquant. Cela peut conduire à l'exécution de code à distance ou à la manipulation logique sur le serveur, sans même nécessiter une faille d’injection normale. Les vulnérabilités de désérialisation insecure sont essentiellement des bombes logiques cachées dans les données. Elles ont été mises en évidence dans le Top 10 OWASP 2017 et restent pertinentes, bien que le Top 10 2ASP 2021 l'ait élargi aux « Software and Data Integrity Failures ». Si une application accepte tout type d'objets sérialisés (comme Java Serializable objets, des ViewState .NET, ou même certains JSON avec des informations de type de classe) des utilisateurs, elle pourrait être à risque.

Exemple : Un exemple récent qui a fait des vagues est CVE-2025-55182 dans les React Server Components (divulgué en décembre 2025). Il s'agissait d'une RCE critique qui s'est avérée être causée par une désérialisation insecure dans le protocole des React Server Components. Essentiellement, un attaquant pouvait envoyer une charge utile HTTP malformée que le côté serveur React désérialiserait incorrectement, permettant l'exécution de code arbitraire. Elle avait un score CVSS de 10 et a affecté un grand nombre d'applications (React étant très répandu). Cela montre que même les frameworks de pointe ne sont pas à l'abri des problèmes de désérialisation. Un autre exemple classique : l' exploit Java Commons Collections de 2016 – une désérialisation insecure dans de nombreuses applications Java (via une bibliothèque) a permis aux attaquants d'envoyer un objet sérialisé qui, lors de la désérialisation, exécutait des commandes sur le serveur. Cela a été largement exploité dans des produits comme Jenkins, WebLogic, etc. Dans .NET, il y a eu la vulnérabilité de désérialisation ViewState (CVE-2017-8759) et d'autres où des données non assainies dans un view state ont conduit à une RCE. Les applications PHP ont eu des problèmes lorsque unserialize() est appelée sur l'entrée utilisateur. Même JavaScript (Node.js) en a eu une notoire dans le serialize-javascript package serialize-javascript. Ainsi, des systèmes d'entreprise aux frameworks modernes, la désérialisation insecure apparaît – souvent avec des résultats graves.

Impact : La désérialisation insecure est souvent un chemin direct vers l'exécution de code à distance (RCE). C'est l'une des pires situations possibles – l'attaquant peut exécuter du code arbitraire sur votre serveur, en prenant potentiellement le contrôle total. Même s'il ne s'agit pas d'une RCE complète, les failles de désérialisation peuvent être utilisées pour manipuler la logique (par exemple, modifier des structures de données pour s'octroyer des privilèges plus élevés sur les données d'objet). Mais généralement, l'impact est critique : si un attaquant peut l'exploiter, il peut souvent déposer un webshell, créer un utilisateur backdoor ou pivoter plus profondément dans le réseau. Le danger est amplifié par le fait que les exploits de désérialisation ne nécessitent souvent aucune authentification (si l'application désérialise les données avant l'authentification) et peuvent être réalisés avec une seule requête. C'est une méthode d'intrusion furtive – pas de requêtes SQL suspectes ou de scripts intersites, juste un blob de données apparemment inoffensif qui fait exploser votre application de l'intérieur.

Prévention : La meilleure façon d'éviter la désérialisation insecure est de ne jamais désérialiser des données non fiables. Si vous n'avez absolument pas besoin d'accepter des objets sérialisés des utilisateurs, ne le faites pas. Utilisez des formats de données plus sûrs (JSON, par exemple, sans métadonnées de type de classe qui pourraient invoquer des constructeurs arbitraires). Si vous devez sérialiser/désérialiser, envisagez de mettre en œuvre des contrôles d'intégrité : par exemple, signer les données sérialisées ou inclure un MAC, afin que toute altération soit détectable. Certains frameworks permettent de restreindre les classes qui peuvent être désérialisées (liste blanche de classes). Cela peut empêcher le fonctionnement de chaînes de gadgets arbitraires. Maintenez les bibliothèques à jour, car de nombreuses failles de désérialisation sont corrigées en renforçant le code exécuté lors de la construction d'objets. OWASP suggère également d'isoler le processus de désérialisation – peut-être en l'exécutant dans un environnement à faibles privilèges ou en sandbox, de sorte que si un exploit se déclenche, son impact soit minimal. En général, traitez les données sérialisées comme potentiellement hostiles. Soyez également conscient de la sérialisation cachée, comme dans les communications inter-services ou les caches.

L'intelligence des vulnérabilités et le scanning d'Aikido peuvent aider à détecter ces problèmes. Côté analyse statique, Aikido peut signaler l'utilisation de fonctions ou de patterns dangereux – par exemple, l'utilisation de ObjectInputStream.readObject() en Java, ou de la fonction PHP unserialize() sur les données utilisateur, ou des bibliothèques de désérialisation insecure connues pour être exploitables. Il vous avertira en vous disant : « attention, vous désérialisez quelque chose ici – est-ce sûr ? ». L'analyse des dépendances d'Aikido entre également en jeu : elle peut vous alerter si vous utilisez une version de bibliothèque connue pour avoir une vulnérabilité de désérialisation (par exemple, une version obsolète d'une bibliothèque de sérialisation courante). Si une CVE majeure comme CVE-2025-55182 (celle de React) apparaît, les flux de renseignement sur les menaces d'Aikido (comme Aikido Intel) mettraient en évidence les projets qui pourraient être affectés et nécessiteraient un patch. En termes de tests, c'est plus difficile pour les scanners dynamiques, mais Aikido Attack pourrait tenter des charges utiles d'exploit connues si votre application utilise un framework courant connu pour un bug de désérialisation. En fin de compte, l'atténuation nécessite souvent des modifications de code ou des mises à jour de bibliothèques, et le rôle d'Aikido est de vous informer rapidement du risque. En détectant la désérialisation insecure pendant le développement ou le scanning, vous pouvez refactoriser pour utiliser des formats de données sûrs ou mettre à jour vers des versions patchées avant de déployer une bombe à retardement.

Construire une posture de sécurité robuste pour les applications web

Comme nous l'avons vu, les applications web d'aujourd'hui sont confrontées à une multitude de vulnérabilités – des failles d’injection qui peuvent vider votre base de données, aux lacunes logiques qui permettent aux attaquants de contourner votre autorisation, en passant par les fuites de secrets et les risques liés aux dépendances des outils sur lesquels nous nous appuyons. Cela peut sembler décourageant, mais le fil conducteur est la sensibilisation et la défense proactive. En comprenant ces principales vulnérabilités, vous avez déjà une longueur d'avance pour les atténuer.

Quelques points clés pour une posture de sécurité robuste des applications web :

• Déplacer la sécurité vers la gauche (Shift Left) : Détectez les problèmes tôt dans le développement. Intégrez les outils SAST/SCA (comme Aikido) dans votre pipeline CI et votre IDE, afin que les vulnérabilités soient signalées et corrigées avant que le code ne soit fusionné. Il est bien plus facile de corriger une requête SQL insecure ou d'ajouter un contrôle d'authentification pendant le codage que de se démener après une violation.
• Défenses en couches : Utilisez plusieurs couches de contrôles de sécurité. Par exemple, pour prévenir les injections et les XSS, combinez des pratiques de codage sûres avec des bibliothèques de sécurité, et exécutez également un pare-feu applicatif (WAF) pour une protection supplémentaire. Pour l'authentification, appliquez la MFA et utilisez la surveillance pour détecter les connexions suspectes. La défense en profondeur signifie que même si une couche échoue, les autres détectent le problème.
• Restez à jour : Maintenez les dépendances et les serveurs à jour avec les correctifs. Envisagez d'activer les mises à jour automatiques pour les composants critiques lorsque cela est possible. Utilisez des flux de vulnérabilités ou des plateformes (Aikido, Dependabot, etc.) pour identifier les éléments vulnérables dans votre stack. Plus vous corrigez rapidement les problèmes connus, moins vous risquez d'être victime de campagnes d'exploitation de masse.
• Gestion des secrets et moindre privilège : Traitez les identifiants comme des actifs critiques. Utilisez des coffres-forts ou des configurations d'environnement pour les secrets, faites-les pivoter régulièrement et accordez à chaque service le minimum d'accès nécessaire. De cette façon, même si une clé est compromise, le rayon d'impact est limité.
• Sécurité dès la conception : Intégrez la modélisation des menaces et les principes de conception sécurisée dès le départ. Pour les nouvelles fonctionnalités, réfléchissez à la manière dont elles pourraient être exploitées et intégrez les contrôles nécessaires (par exemple, assurez-vous qu'une nouvelle fonctionnalité de téléchargement de fichiers valide les types et les tailles de fichiers pour prévenir les problèmes de désérialisation ou de DoS, assurez-vous qu'un nouveau point d'accès API vérifie les rôles des utilisateurs pour prévenir les failles de contrôle d'accès, etc.).
• Sensibiliser et automatiser : Informez l'équipe de développement des pièges courants (comme ceux du Top 10 OWASP). Utilisez des scanners et des tests automatisés comme filet de sécurité, mais encouragez également une culture où les développeurs réfléchissent à l'impact sur la sécurité. Une meilleure sensibilisation contribue grandement à éviter, par exemple, la tentation de désactiver les jetons CSRF « juste pour tester » ou de copier-coller du code de StackOverflow sans considérer la sécurité.

En vous concentrant sur ces pratiques fondamentales, vous pouvez réduire drastiquement le profil de risque de votre application. De nombreuses attaques réussissent non pas parce qu'elles sont ultra-sophistiquées, mais parce que l'hygiène de sécurité de base a été négligée. Comblez ces lacunes, et les attaquants se tourneront vers des cibles plus faciles.

Conclusion

Développer des applications web capables de résister aux menaces actuelles est tout à fait à la portée des équipes de développement – surtout avec les bons outils à leur disposition. Nous avons examiné les principales vulnérabilités web qui affectent les applications et avons vu comment elles se traduisent en incidents réels. Le dénominateur commun est que la sensibilisation et la détection précoce font toute la différence. Lorsque vous savez quoi chercher – qu'il s'agisse d'une entrée non assainie, d'un contrôle d'accès manquant ou d'une bibliothèque obsolète – vous pouvez y remédier de manière proactive plutôt que réactive.

En tant que développeur ou ingénieur DevSecOps, vous n'avez pas à gérer cela seul. Les solutions AppSec modernes comme Aikido Security sont conçues pour s'intégrer parfaitement à votre flux de travail et détecter rapidement ces problèmes. Imaginez un expert en sécurité automatisé examinant chaque commit : signalant cette faille XSS sournoise, détectant la clé AWS avant qu'elle ne quitte votre ordinateur portable, vous indiquant que vous utilisez une version de bibliothèque avec une CVE critique, et même suggérant ou appliquant des correctifs. C'est ce qu'Aikido apporte – une analyse tout-en-un pour le code, les dépendances, la configuration, et plus encore, conçue pour les développeurs. C'est comme avoir le Top 10 OWASP et la dernière base de données CVE qui veillent sur vous, sans vous ralentir.

Prochaines étapes : N'attendez pas un audit ou (pire) une violation pour découvrir ces vulnérabilités. Vous pouvez commencer par exécuter une analyse de sécurité sur votre base de code pour évaluer votre situation. Configurez des règles de linting pour la sécurité, ajoutez la vérification des dépendances et activez la 2FA partout. Si vous êtes intéressé par une plateforme axée sur les développeurs qui fait tout cela et plus encore, envisagez d'essayer Aikido – elle offre l'analyse de code, le SAST, la détection de secrets, les analyses IaC et de conteneurs, ainsi que des correctifs assistés par l'IA dans une interface unifiée. En fait, Aikido peut automatiquement cartographier le statut de votre projet par rapport à la couverture du Top 10 OWASP et vous aider à combler les lacunes.

En fin de compte, l'objectif est d'intégrer la sécurité au cœur du développement. En vous concentrant sur ces principales vulnérabilités, en écrivant du code sécurisé et en utilisant des outils pour automatiser les tâches lourdes, vous réduirez considérablement les risques pour vos applications web. Les données de vos utilisateurs restent sécurisées, votre application reste opérationnelle, et vous pouvez dormir un peu plus sereinement la nuit (tout comme les 42 % des équipes qui s'inquiètent de la sécurité des conteneurs et des applications, mentionnées précédemment !).

Vous pourriez aussi aimer :

• Principales vulnérabilités de sécurité du cloud
• Principales vulnérabilités de sécurité Kubernetes
• Principales vulnérabilités de sécurité des conteneurs Docker