Pourquoi êtes-vous ici ?
Vous savez que vos applications sont vulnérables à toutes sortes d'attaques. Globalement, la cybercriminalité devrait coûter 9,5 billions de dollars en 2025, selon Cybersecurity Ventures – soit une augmentation de trois fois par rapport à 2015. Et l'année dernière, les attaques d'applications web ont représenté 12 % de toutes les violations de données, contre 9 % l'année précédente. Cette augmentation constante, associée au fait que le défaut de sécurisation des applications web peut enfreindre de nombreuses réglementations, signifie que les développeurs sont désireux de mieux comprendre les menaces qui les impactent le plus.
Nous allons donc réduire le bruit autour des vulnérabilités courantes et nous concentrer sur trois détails essentiels :
- Le TL;DR, qui vous informera mieux sur le type d'attaque.
- Une réponse concise à la question, “Est-ce que cela m'affecte ?” avec un oui ou un non clair (✅ ou 🙅) et une brève explication.
- Conseils rapides en réponse à « Comment puis-je le corriger ? » qui n'impliquent pas d'outils coûteux ou de refactorisations onéreuses.
1. Injection SQL et injection NoSQL
TL;DR : Cette vulnérabilité classique est rendue possible par des entrées utilisateur non assainies et non validées, ce qui permet aux attaquants d'exécuter des requêtes directement sur votre base de données. À partir de là, ils peuvent extraire des données, modifier des enregistrements ou les supprimer à volonté.
Cela m'affecte-t-il ?
✅ si votre application interagit avec une base de données SQL ou NoSQL à un moment donné. Les attaques par injection existent depuis des décennies, et les attaques automatisées commenceront immédiatement à sonder vos points d'accès avec des exploits courants.
🙅 si vous n'avez aucun contenu dynamique basé sur des enregistrements de base de données. Cela peut être parce que vous êtes entièrement côté client, utilisant un générateur de site statique (SSG), ou effectuant un rendu côté serveur avec une base de données sans jamais accepter d'entrée des utilisateurs.
Comment y remédier ? Tout d'abord, nettoyez et validez toutes les entrées utilisateur pour éliminer les caractères ou chaînes indésirables. Tirez parti des bibliothèques et frameworks open source qui permettent les requêtes paramétrées, et ne concaténez jamais les entrées utilisateur dans une requête de base de données. Si vous utilisez Node.js, envisagez notre moteur de sécurité open source Runtime, qui vous protège de manière autonome contre les attaques par injection SQL/NoSQL et bien plus encore.
2. cross-site scripting (XSS)
En bref : Le XSS est une autre attaque par injection qui permet à un attaquant d'envoyer un script malveillant à un autre utilisateur, pouvant potentiellement collecter ses identifiants d'authentification ou des données confidentielles.
Cela m'affecte-t-il ?
✅ si votre application accepte les entrées utilisateur et les affiche ailleurs comme contenu dynamique.
🙅 si vous n'acceptez aucune entrée utilisateur.
Comment le résoudre ? Comme pour les attaques par injection SQL/NoSQL, vous devriez valider les entrées utilisateur lorsque vous incluez ces entrées dans le href attribut des balises d'ancrage pour s'assurer que le protocole n'est pas javascriptSoyez vigilant lors de l'utilisation de méthodes JavaScript telles que innerHTML ou de React dangerouslySetInnerHTML, qui peut exécuter arbitrairement tout code intégré dans la chaîne lors de la sortie. Quelle que soit votre approche, nettoyez la sortie HTML avec des nettoyeurs open source comme DOMPurify pour n'envoyer que du HTML propre et non exécutable à vos utilisateurs.
3. Server-side request forgery (SSRF)
En bref : Les attaques SSRF (Server-Side Request Forgery) se produisent lorsqu'un acteur malveillant abuse de votre application pour interagir avec son réseau sous-jacent, l'utilisant comme un proxy pour accéder à des services potentiellement plus vulnérables ou lucratifs.
Cela m'affecte-t-il ?
✅ si votre application s'interface avec un autre service ou une API qui effectue une opération spécifique avec les données utilisateur – même si vous avez utilisé des listes d'autorisation pour restreindre le trafic entre des points de terminaison connus et fiables uniquement.🙅 si vous êtes vraiment statique.
Comment y remédier ? Bien qu'une expression régulière pour valider les adresses IP ou les noms d'hôte soit un bon début, elle est généralement sujette à des contournements comme l'encodage octal. Deux solutions plus fiables consistent à utiliser une liste blanche et l'analyseur d'URL natif de votre plateforme pour restreindre les entrées aux hôtes sûrs et connus uniquement, et à désactiver les redirections dans les requêtes fetch. Selon votre framework, vous pouvez également tirer parti de projets open source – comme ssrf-req-filter pour Node.js – pour refuser correctement toute requête vers des hôtes internes.
4. Path traversal
TL;DR : Cette faille de sécurité permet aux attaquants d'accéder aux fichiers et répertoires de votre serveur web en référençant des fichiers à l'aide de séquences ../ ou même de chemins absolus. En utilisant des tactiques sournoises comme le double encodage, les attaquants peuvent exploiter les hiérarchies de dossiers/fichiers spécifiques aux frameworks ou les noms de fichiers courants pour trouver des informations précieuses.
Cela m'affecte-t-il ?
✅ Votre application s'exécute sur un serveur web et inclut des références au système de fichiers — il n'y a pas moyen de contourner cela.
Comment y remédier ? Votre première étape consiste à supprimer tout fichier sensible, tel que ceux contenant des variables d'environnement ou des secrets, du répertoire racine de votre serveur web, et à établir un processus pour éviter de nouvelles erreurs.
est de ne jamais stocker de fichiers sensibles, comme ceux contenant des variables d'environnement ou des secrets, dans le répertoire racine de votre serveur web. De même, ne stockez pas ces fichiers dans un dossier destiné à être publiquement accessible, comme le /static et /public dossiers d'un Projet Next.js. Enfin, supprimez les séparateurs de chemin ../ et leurs variantes encodées des entrées utilisateur.
Runtime fonctionne aussi incroyablement bien pour le path traversal… pour information.
5. Injection d'entités externes XML (XXE)
En bref : Les attaques XXE (XML External Entity) exploitent une faiblesse dans les parseurs XML qui permet de récupérer et de traiter des entités externes, référencées par une définition de type de document (DTD), sans validation ni assainissement. Le type et la gravité de l'attaque sont principalement limités par les compétences de l'attaquant et les mesures de sécurité/permissions au niveau du système d'exploitation de votre fournisseur d'infrastructure.
Cela m'affecte-t-il ?
✅ si vous analysez du XML pour quelque raison que ce soit, y compris les flux d'authentification par authentification unique (SSO) utilisant SAML.
🙅 si vous n'avez pas à gérer de XML dans votre application !
Comment y remédier ? Désactivez la résolution de DTD externes dans votre analyseur XML. Vous ne pouvez probablement pas refuser entièrement les DTD, car il est normal que certaines charges utiles XML en contiennent – assurez-vous simplement que votre analyseur XML n'en fait rien.
6. Désérialisation
TL;DR : Les attaquants peuvent envoyer des données malveillantes via une fonction de désérialisation intégrée à votre application (comme unserialize() de node-serialize) pour exécuter du code à distance, lancer une attaque par déni de service, ou même créer un reverse shell.
Cela m'affecte-t-il ?
✅ si votre application désérialise des données directement à partir d'une interaction utilisateur ou via des fonctions/services d'arrière-plan comme les cookies, les formulaires HTML, les API tierces, la mise en cache, et plus encore.
🙅 si vous exécutez une application entièrement statique sans aucune des conditions ci-dessus.
Comment y remédier ? En général, évitez de désérialiser les données d'entrée utilisateur (c'est-à-dire non fiables). Si vous devez le faire, n'acceptez ces données que d'utilisateurs authentifiés et autorisés, en vous basant sur des signatures, des certificats et des fournisseurs d'identité de confiance.
7. Injection de shell/injection de commandes
En bref : Votre application transmet directement les entrées utilisateur au shell sous-jacent du système d'exploitation sur lequel votre serveur web et votre application s'exécutent, permettant aux attaquants d'exécuter des commandes arbitraires ou de parcourir le système de fichiers, souvent avec des privilèges suffisants pour extraire des données ou pivoter vers un autre système.
Cela m'affecte-t-il ?
✅ si votre application interagit directement avec le système de fichiers ou le shell, par exemple avec une commande UNIX telle que cat.
🙅 si vous utilisez déjà une API ou une méthode de framework pour passer en toute sécurité des arguments à la commande que vous devez exécuter, ou si vous n'avez pas besoin d'interagir avec le système de fichiers/shell, comme dans un SSG.
Comment le résoudre ? Évitez d'accepter directement les entrées utilisateur dans les commandes ou de les appeler directement. Utilisez plutôt l'API/méthode de votre framework, comme child_process.execFile() en Node.js, qui permet de passer des arguments dans une liste de chaînes de caractères. Même avec cette protection, exécutez toujours vos applications avec les privilèges les moins élevés nécessaires à la logique métier requise afin d'empêcher un attaquant de « s'échapper » du serveur web et d'accéder à root-uniquement les dossiers et les fichiers.
Et oui, nous sommes de retour pour un dernier rappel amical d'ajouter Runtime à tout projet Node.js avec une seule commande (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) pour protéger instantanément votre application contre les attaques courantes d'injection shell/commande.
8. Inclusion de fichiers locaux (LFI)
TL;DR: Les attaques LFI consistent à tromper votre application pour qu'elle expose ou exécute des fichiers sur le système hébergeant votre serveur web, ce qui permet aux attaquants d'extraire des informations ou d'exécuter du code à distance. Alors que la traversée de répertoire (path traversal) permet uniquement aux attaquants de lire des fichiers, les attaques LFI exécutent ces fichiers au sein de votre application, vous exposant à une multitude de vulnérabilités comme l'exécution de code à distance (RCE).
Cela m'affecte-t-il ?
✅ si votre application utilise le chemin d'accès à un fichier comme entrée utilisateur.
🙅 si votre application ne demande pas aux utilisateurs de fournir des chemins pour effectuer une action.
Comment le résoudre ? Assainissez toujours les entrées utilisateur pour prévenir les méthodes de path traversal abordées ci-dessus. Si vous devez inclure des fichiers sur le système de fichiers local au-delà de ceux que l'on trouve généralement dans des répertoires « sûrs » /public ou /static dossiers, utilisez une liste blanche pour les noms de fichiers et les emplacements que votre application est autorisée à lire et à exécuter.
9. Pollution de prototype
TL;DR : Ceci Vulnérabilité spécifique à JavaScript permet à un attaquant de manipuler les objets globaux de votre application en utilisant __proto__Le nouvel objet est ensuite hérité dans toute votre application, leur donnant potentiellement accès à des données confidentielles ou leur permettant d'escalader davantage leurs privilèges.
Cela m'affecte-t-il ?
✅ si vous utilisez JavaScript.
🙅 si vous utilisez n'importe quoi sauf JavaScript !
Comment le résoudre ? Commencez par assainir les clés provenant des entrées utilisateur en utilisant des listes blanches ou une bibliothèque d'aide open-source. Vous pouvez étendre votre protection en utilisant Object.freeze() pour empêcher les modifications d'un prototype, ou même en utilisant le --disable-proto=delete option proposée avec Node.js.
10. Redirections ouvertes
TL;DR : Dans ce vecteur courant de phishing, les attaquants élaborent une URL personnalisée telle que https://www.example.com/abc/def?&success=false&redirectURL=https://example.phishing.com pour inciter votre application à rediriger des utilisateurs non avertis vers un site web malveillant. De plus, les attaquants peuvent enchaîner les redirections avec d'autres vulnérabilités pour un impact encore plus grand, menant à des prises de contrôle de compte et plus encore.
Est-ce que cela m'affecte ?
✅ si votre application redirige les utilisateurs vers une autre page/vue après avoir terminé une action, comme les envoyer vers example.app/dashboard après authentification réussie.
🙅 si vous êtes toujours adepte du contenu statiquement généré.
Comment y remédier ? Tout d'abord, supprimez les redirections basées sur des paramètres de votre application et remplacez-les par des redirections fixes basées sur une liste blanche de domaines et de chemins de confiance vers lesquels vous pouvez rediriger les utilisateurs après qu'ils aient effectué des actions spécifiques. Cela pourrait légèrement dégrader l'expérience utilisateur, mais c'est un compromis significatif pour offrir une expérience sécurisée, et non une expérience qui les laisserait vous blâmer pour les dépenses étranges sur leur relevé de carte de crédit.
Quelle est la suite ?
Si vous vous sentez dépassé par l'ampleur des attaques et tout le travail nécessaire pour vous en protéger, sachez que vous n'êtes pas seul.
Personne ne s'attend à ce que vous résolviez vous-même tous ces problèmes de sécurité et ces vulnérabilités potentielles. Les attaques par injection SQL existent depuis des décennies, et des CVE sont encore régulièrement découvertes dans des applications, frameworks et bibliothèques sophistiqués. Cela ne signifie pas pour autant que vous devriez prendre ces problèmes de sécurité à la légère — si votre application correspond au ✅ pour l'un de ces 10 principaux problèmes de sécurité, vous devriez commencer à agir.
Il est probable que vous utilisiez des outils de sécurité de niveau entreprise (c'est-à-dire coûteux et complexes), ou que vous ayez assemblé une poignée de projets open source dans un pipeline CI/CD ou des hooks de commit Git en espérant le meilleur. Cela pourrait laisser des lacunes en matière de sécurité, telles que :
- Comment votre application pourrait être vulnérable en raison de pratiques de programmation sous-optimales, de dépendances non sécurisées, et au-delà.
- Où les vulnérabilités se cachent très probablement, jusqu'à des lignes de code uniques (LOCs) ou des entrées dans votre
package.jsonfichier. - Pourquoi vous devriez corriger certaines vulnérabilités immédiatement et pourquoi d'autres sont de moindre priorité.
Aikido Security aide à combler ces lacunes en 2 étapes simples :
1. Scannez votre code avec Aikido
Inscrivez-vous (gratuit, 2 min) et scannez vos dépôts. Obtenez une liste ciblée de vulnérabilités critiques basée sur l'architecture et l'utilisation réelles de votre application. Voyez exactement ce qui compte, obtenez des correctifs guidés et recevez des alertes pour les nouveaux problèmes dans vos derniers commits.
2. Protégez vos applications Node.js avec Runtime
Ajoutez notre Runtime open source pour bloquer les attaques par injection, pollution de prototype et traversée de répertoire au niveau du serveur — sans la surcharge des WAF ou des agents. Runtime envoie également des données d'attaque en temps réel à Aikido afin que vous puissiez voir ce qui est ciblé et prioriser les correctifs.
Vous êtes maintenant sur la bonne voie, avec une vision plus claire quant à :
- Comment votre application est vulnérable de plus de façons que vous n'auriez pu le penser.
- Où vous devriez concentrer votre temps et votre attention pour corriger les problèmes les plus critiques en premier.
- Pourquoi l'analyse de sécurité et de vulnérabilités n'est pas un effort ponctuel, mais un processus continu.
Sécurisez votre logiciel dès maintenant.
.avif)
