--- title: "L'OWASP Top 10 API – 2023" description: "Les 10 failles de sécurité API à connaître selon l’OWASP 2023, avec exemples et bonnes pratiques pour s’en protéger." url: "https://lonestone.io/blog/owasp-top-10-api-2023" --- [Lonestone](/) ⟩ [Blog](/blog) # Le Top 10 OWASP des vulnérabilités API – 2023 18 juillet 2023 · 12 min de lecture Dans le monde du web, le développement d’API web est en constante augmentation depuis des années. Cela s’explique par de multiples raisons, comme la multiplication d’architectures orientées services ou encore l’intégration de nouvelles applications plus rapides. L’avènement des objets connectés contribue également à cette tendance. Ces avantages ont également leurs lots d’inconvénients, la principale est l’élargissement de la zone d’attaque, car on passe d’applications web générées coté serveur (Server Side Rendering) à un développement où l’on découple le client et le serveur. Face à la multiplication des attaques sur les applications web, l’OWASP, pour Open Web Application Security Project, dresse tous les 4 ans un Top 10 des risques les plus rencontrés sur les applications web, les API web ou même sur mobile. > 💡 Focus mot clé : En sécurité, un **risque** est défini par la probabilité qu’une **vulnérabilité** soit exploitée, multipliée par la **gravité** potentielle de l’exploitation de cette **vulnérabilité**.Exemple -très- simplifié : le **risque** de prendre l’avion est faible, car ces derniers sont très lourdement contrôlés (**probabilité** d’accident très faible), malgré une **gravité** élevée en cas d’accident. Commençons alors à détailler les 10 risques identifiés par l’OWASP. A chaque fois nous y trouverons une brève description du risque, un scénario d’attaque, volontairement simple, pour s’imaginer les enjeux et quelques conseils de développement. Pour plus de détails, vous pouvez consulter les travaux officiels de l’OWASP ici : [https://owasp.org/API-Security/editions/2023/en/0x03-introduction/](https://owasp.org/API-Security/editions/2023/en/0x03-introduction/) ## 1\. Broken object level authorization (BOLA) Héritant de la vulnérabilité [Insecure Direct Object Reference](https://portswigger.net/web-security/access-control/idor), on parle ici d’un défaut lors de la vérification de l’autorisation. Les APIs exposent des données qui sont facilement interrogeables à travers des routes dédiées et des identifiants (exemple : `/user/25156` ou encore `/invoices/854`). Lorsqu’une requête est effectuée sur une API en vue de récupérer des données, l’API doit vérifier que le requérant (utilisateur ou application) est bien **autorisé** à lire les données. Cela peut passer par plusieurs mécanismes, comme le contrôle d’accès basé sur le rôle (`RBAC`). Le risque ici est l’autorisation n’est pas complètement gérée, ce qui peut donner accès en lecture à des données où il n’a pas l’autorisation. La gestion des autorisations peut devenir complexe suivant l’augmentation du type de données / nombre de rôles et l’erreur humaine est toujours possible. ### Scénario d’attaque Nous disposons d’une API /invoices/``. Les factures sont liées à des entreprises et des personnes. Cependant, si le contrôle est mal réalisé (vérification que la requête appartient bien à l’entreprise liée à la facture), il serait possible de récupérer des factures. Pire encore, si l’ID est un nombre incrémental, il serait possible d’énumérer et récupérer toutes les factures de l’API. ### Conseils * La route /users est souvent sensible, utilisez /me au lieu de /users/`` pour récupérer les données personnelles de l’utilisateur courant * Intégrer du contrôle d’accès dans vos tests automatisés (un accès non autorisé doit renvoyer un code HTTP 403) * Préférer refuser les accès par défaut et donner les droits aux utilisateurs/rôles (principe du moindre privilège) * Utiliser des UUID (`123e4567-e89b-12d3-a456-426652340000`) au lieu d’ID incrémental ## 2\. Broken Authentication Cette fois-ci, c’est l’authentification qui est en jeu. Pour rappel, cette notion concerne l’identification d’un utilisateur (et pas ses droits, tel que mentionné précédemment). L’authentification “cassée” est le deuxième risque identifié par l’OWASP. Le vrai impact ici est qu’un attaquant se fasse passer pour un utilisateur, usurpant alors ses droits. Cela passe par une ou plusieurs vulnérabilités techniques lors du processus d’authentification, comme : * Un jeton JWT mal contrôlé (plus d’informations [ici](https://www.vaadata.com/blog/fr/jetons-jwt-et-securite-principes-et-cas-dutilisation/)) * Le bruteforce du mot de passe sur un point de terminaison permettant l’authentification * Politique de mot de passe faible ### Scénario d’attaque Nous avons un site web gérant l’authentification par un token JWT, sauvegardé dans les cookies du navigateur web. La vérification de la validité du token a été implémentée directement par le développeur, et ce dernier décode le token pour extraire l’algorithme de hashage de la signature. Il est alors possible de forger un token valide en utilisant le claim `alg` à `none`. ### Conseils * Ne pas réinventer la roue mais utiliser des bibliothèques dédiées et rodées (exemple : utiliser _Passport_ sous [NodeJS](https://www.passportjs.org/)) * Mettre en place un rate-limiter pour limiter le nombre de requête et éviter les attaques par brute-force * Comprendre parfaitement les mécanismes d’authentification, prendre le temps de se former et assimiler les concepts ## 3\. Broken Object Property Level Authorization La combinaison de deux items d’OWASP Top 10 2019 : **Excessive Data Exposure** et **Mass Assignment**. Ici, c’est là le défaut d’autorisation au sein des propriétés d’un objet qui est en jeu, que ce soit en lecture avec le retour de données sensibles non appropriées (Excessive Data Exposure) ou en écriture (Mass Assignment). ### Scénarios d’attaque **Excessive Data Exposure** : Un utilisateur utilise une requête `SELECT \* FROM users` pour récupérer les données des utilisateurs (id, pseudo, role). Une évolution fait ajouter un mot de passe dans cette même table. Si la requête n’est pas modifiée, l’API va désormais exposer le mot de passe des utilisateurs. **Mass Assignment** : Une API permet de modifier les données de notre profil utilisateur, qui envoie le body `{ pseudo : "test" }`. Cependant, en inspectant le trafic réseau, l’attaque peut tenter d’envoyer `{ pseudo : "test", role : "admin" }`. L’API peut contrôler que l’utilisateur est autorisé à écrire, mais doit vérifier quels champs il peut écrire. Cela peut se produire lors de l’utilisation d’un ORM, par exemple : ``` // désérialisation du contenu en entrée const user = new db.User(req.body); // sauvegarde de l'objet en base de données user.save() ``` ### Conseils * Spécifiez explicitement quels champs des objets doivent être retournés (évitez donc les méthodes comme `toString()`) * Utiliser un schéma de réponse (DTO) * Évitez les fonctionnalités qui connectent directement l’entrée utilisateur aux variables ## 4\. Unrestricted Resource Consumption Son nom est plutôt clair : on parle ici du problème de la gestion des ressources du serveur. Savoir si l’API est sensible à ce risque peut venir de plusieurs facteurs : la RAM du serveur, la taille maximum des fichiers lors de l’upload, le timeout du serveur, nombre d’opérations maximum à effectuer lors d’une seule requête HTTP GraphQL (Batching GraphQL) et autre. Ce risque englobe également les risques liés à la consommation de fonctionnalités payantes accessible à travers des API. ### Scénario d’attaque Une entreprise a développé une application web qui affiche une carte et effectue des requêtes de géocoding qui sont payantes. Si le développeur requête directement l’API de géocoding, la clé API est embarquée dans le code client. Cela signifie que n’importe qui peut récupérer la clé et écrire un script qui va requêter l’API avec cette clé… Qui peut engendrer des coûts importants. On pourrait également imaginer la même chose lors d’envoi de sms en cas de mot de passe perdu. Si aucune limite de requête par minute n’est mise en place, l’attaquant pourrait déclencher l’envoi de milliers de sms, payants pour l’entreprise. ### Conseils * Mettre en place un rate limiter sur les routes API sensibles * Limiter la taille des fichiers pouvant être téléversés * Déployer un proxy web pour contrôler l’appel aux fonctionnalités payantes (et, si possible, mettre en place un cache coté serveur) * Utiliser des limiters à la scabilité des infrastructures Cloud ## 5\. Broken Function Level Authorization Ce risque est similaire à **Broken Object Level Authorization**, sauf qu’on parle ici de l’accès à certaines fonctionnalités qui sont mal protégées. Comme le BOLA, ce risque provient de la complexité à hiérarchiser et configurer les rôles et droits utilisateurs. ### Scénario d’attaque Une route admin qui n’est appelée que si l’on est connecté en tant qu’admin mais qui peut être découverte par une attaque en “devinant” la route (comme `/api/admin/users/all`), et qui a été mal protégée, donnant accès à des utilisateurs non autorisés. ### Conseils * Idem que BOLA ## 6\. Unrestricted Access to Sensitive Business Flows C’est ici un cas simple à comprendre mais difficile à anticiper, qui n’est pas forcément lié à des malfaçons de développements. Ce risque est lié à toutes les conséquences qui peuvent être induites si un attaquant utilise de manière excessive des fonctionnalités de l’application, comme la création de tickets, commentaires, réservations etc… ### Scénario d’attaque * Un restaurant dispose d’une application pour réserver une table en ligne. Un attaquant pourrait alors écrire un script pour réserver toutes les tables, rendant les prochaines réservations impossibles. ### Conseils **Note : Il est très difficile de protéger à 100%. Cependant, ces mesures auront pour but de ralentir / décourager les potentielles attaques** * Utiliser l’empreinte de l’appareil qui émet la requête pour n’en autoriser qu’une * Mettre en place une détection d’humain : captcha, modèle de frappe, mesure du temps entre différentes actions (mise en panier ⇒ validation ⇒ achat). * Utiliser les IP pour filtrer, en bloquant les IPs connues des nœuds VPNs / Tor ## 7\. Server Side Request Forgery Ce risque arrive quand l’attaquant contrôle les urls qui seront appelées par le serveur. Grâce à cela, l’attaque peut se servir de l’application web comme d’un proxy pour interroger différentes applications web dans le même réseau. ### Scénarios d’attaque 1. Si une application web prend en entrée une url pour changer une photo de profile d’un utilisateur, l’attaquant pourrait utiliser l’adresse `localhost:` pour scanner le réseau interne (et donc les ports ouverts sur la machine) en fonction de la réponse 2. Un service web peut être configuré pour appeler un webhook, et va logguer la réponse HTTP pour qu’elle soit consultable par le développeur. Si le serveur autorise de mettre des ip locales ou privées, il sera possible d’envoyer des requêtes HTTP vers des services normalement non accessible à l’extérieur (comme une console admin non protégée) et voir le contenu de la page html. ### Conseils * Désactiver les redirections HTTP * Ne pas communiquer les réponses des requêtes HTTP * Valider le protocole et les ports de destination * Utiliser une liste d’urls autorisées, et / ou une liste d’url non autorisées (exemple : bloquer les ip et les domaines pointant vers le réseau local) ## 8\. Security Misconfiguration Les systèmes logiciels peuvent vite devenir complexes à mesure de l’ajout de composants : infrastructure, système de déploiement automatisé, réseau etc… La pile totale des technologies peut des fois faire intervenir différents métiers, qui peuvent faire des erreurs de configuration ou ne pas suivre les bonnes pratiques de sécurité. Cela peut alors entraîner une multitudes d’attaques possibles. ### Scénario d’attaque 1. Un serveur apache qui autorise l’exécution de toutes les extensions de code php (exemple : .phtml). Si une fonctionnalité d’upload de fichier n’empêche que les fichiers contenant “.php”, l’attaquant pour exécuter du code sur le serveur en connaissant le répertoire destination. 2. Dans un cadre de requêtes CORS, le serveur renvoi systématiquement l’origine de l’appelant dans l’entête [Access-Control-Allow-Origin](https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) , pouvant conduire à des attaques CSRF si l’attaque arrive à faire venir les visiteurs sur une copie du site qu’il contrôle. ### Conseils * Créer une tâche dédiée à la revue des configurations et le respect de leurs bonnes pratiques de sécurité (la majorité des systèmes disposent d’une page à cet effet dans leurs documentations) * Faites attention aux différents verbes HTTP utilisés, désactiver ceux qui ne sont pas utilisés * Prenez le temps de comprendre et implémenter les bonnes entêtes HTTP, utiliser [https://securityheaders.com/](https://securityheaders.com/) pour les vérifier ## 9\. Improper Inventory Management Au fur et à mesure qu’une APIs se développe, le nombre de ses points de terminaisons, arguments, ou encore de versions augmente. En tant que développeur d’API, il est important de tenir un inventaire de toutes les routes qui sont exposées. Le risque ici est de continuer à rendre accessible des routes dépréciées, non protégées ou souffrant de patch, qui peuvent devenir une brèche dans le système ou encore exposer des données qui ne devraient pas l’être. ### Scénarios d’attaque * Un rate limiter qui a été mis en place sur un environnement en version 2, mais pas en version 1, qui n’est plus utilisé officiellement. Cependant, une attaque peut réussir à découvrir cette route (fuzzing, guessing etc..) et lancer une attaque de brute force, le rate limiter n’étant pas installé sur cette version. ### Conseils * Documenter toutes les endpoints et version de l’API * Ne plus exposer les routes inutilisées * Ne pas utiliser des données de production en dehors d’environnement de préproduction (dans le cas où c’est inévitable, mettre en place les même mesures de sécurité) ## 10\. Unsafe Consumption of APIs Les applications web utilisent souvent des données de tierces APIs et injectent directement ces données dans leurs traitements. Cependant, ces données étant considérées comme “sûres”, ne sont pas nettoyées ou contrôlées. ### Scénarios d’attaque 1. Un serveur va récupérer des données d’une API tiers qu’il va ensuite stocker en base. Une attaque pourrait s’attaquer au fournisseur pour modifier les données renvoyer en intégrant une charge utilise pour une injection SQL. Cette dernière pourrait alors être déclenchée lors du traitement par le serveur. 2. Un serveur renvoi des données personnelles sur une API. Si cette dernière a été corrompue, elle peut retourner une erreur 308 (Permanent Redirect) qui va faire envoyer les données vers une autre API, contrôlée par l’attaque ### Conseils * Évaluer le niveau de sécurité des API tiers * Communiquer toujours en TLS * Valider et nettoyer les données avant de les utiliser En conclusion, on observe qu’il est primordial d’au moins sensibiliser les développeurs et développeuses à ces différents risques. Cela pourra leur donner des outils et des réflexes à adopter lors des développements d’API. Pour aller plus loin, nous recommandons fortement de former les équipes techniques aux rudiments du développement sécurisé.‍ ![L'OWASP Top 10 API – 2023](/.netlify/images?url=_astro%2Fthumbnail.Bd0nqvsv.png&w=1754&h=959&dpl=69e9deed41371b000857cf89) Sommaire [1 / Broken object level authorization (BOLA)](#1-broken-object-level-authorization-bola) [2 / Broken Authentication](#2-broken-authentication) [3 / Broken Object Property Level Authorization](#3-broken-object-property-level-authorization) [4 / Unrestricted Resource Consumption](#4-unrestricted-resource-consumption) [5 / Broken Function Level Authorization](#5-broken-function-level-authorization) [6 / Unrestricted Access to Sensitive Business Flows](#6-unrestricted-access-to-sensitive-business-flows) [7 / Server Side Request Forgery](#7-server-side-request-forgery) [8 / Security Misconfiguration](#8-security-misconfiguration) [9 / Improper Inventory Management](#9-improper-inventory-management) [10 / Unsafe Consumption of APIs](#10-unsafe-consumption-of-apis) Sommaire 1 / Broken object level authorization (BOLA) 2 / Broken Authentication 3 / Broken Object Property Level Authorization 4 / Unrestricted Resource Consumption 5 / Broken Function Level Authorization 6 / Unrestricted Access to Sensitive Business Flows 7 / Server Side Request Forgery 8 / Security Misconfiguration 9 / Improper Inventory Management 10 / Unsafe Consumption of APIs Lonestone est une agence qui conçoit et développe des produits web et mobile innovants intégrant de l'IA. Nos experts partagent leurs expériences sur le blog. Contactez-nous pour discuter de vos projets ! [En savoir plus sur Lonestone](/) [Parler à un expert](/contact) ![](/_astro/use-case-corner.3qL77H9h.png) Besoin d'accompagnement ? Nos experts sont disponibles pour discuter de votre projet. [Parler à un expert](/contact) ## On continue la lecture ? [Tous les articles](/blog) [![Adoptez une gestion sécurisée de vos mots de passe](/.netlify/images?url=_astro%2Fthumbnail.BNOuZMDe.jpg&w=1920&h=1281&dpl=69e9deed41371b000857cf89) Adoptez une gestion sécurisée de vos mots de passe Vous pensez bien gérer vos mots de passe ? Découvrez les erreurs courantes, les vrais risques et les bonnes pratiques pour sécuriser vos comptes. ](/blog/arretez-de-gerer-vos-mots-de-passe-nimporte-comment)[![Notre méthode pour estimer un projet web chez Lonestone](/.netlify/images?url=_astro%2Fthumbnail.JYnQhgbE.jpeg&w=1400&h=933&dpl=69e9deed41371b000857cf89) Notre méthode pour estimer un projet web chez Lonestone Chez Lonestone, estimer un projet web ne se résume pas à un chiffre. Complexité, design, retours d’expérience, rôle d’estimateur… Voici notre méthode pour mieux chiffrer. ](/blog/comment-on-estime-les-projets-web-chez-lonestone)[![Débugger les requêtes réseaux des apps avec un proxy Web](/.netlify/images?url=_astro%2Fthumbnail.B5capxRg.png&w=640&h=360&dpl=69e9deed41371b000857cf89) Débugger les requêtes réseaux des apps avec un proxy Web Un proxy web peut devenir un précieux allié pour analyser les requêtes réseau d’une app mobile. Découvrez comment l’utiliser avec Burp Suite pour déboguer efficacement. ](/blog/debugger-les-requetes-reseaux-des-apps-avec-un-proxy-web) [Tous les articles](/blog) ## Nos guides ### Guide de l'IA générative [ 01\. IA, Machine Learning & Deep Learning ](/ai/deep-learning)[ 02\. LLM (Large Language Model) : définition et fonctionnement ](/ai/llm)[ 03\. RAG + MCP : Architecture pour agents IA ](/ai/rag-mcp)[ 04\. Agents IA : définition et cas d'usage ](/ai/agents-ia)[ 05\. Boostez vos logiciels avec l'intégration de l'IA ](/ai/integration-ia)[ 06\. Meilleurs outils IA pour les entreprises ](/ai/outils-ia) ### Guide pour créer un SaaS IA [ 01\. Construire un SaaS IA rentable : la méthode qui fonctionne ](/creer-saas-ia/roadmap)[ 02\. Comparatif LLM 2026 : quel modèle choisir pour votre SaaS ? ](/creer-saas-ia/comparatif-llm-saas)[ 03\. Héberger un SaaS IA en France : performances, coûts et souveraineté ](/creer-saas-ia/heberger-ia)[ 04\. Framework d’évaluation IA : pourquoi et comment le mettre en place ](/creer-saas-ia/evaluation)[ 05\. MCP (Model Context Protocol) : le standard pour connecter IA et logiciels ](/creer-saas-ia/mcp)[ 06\. Bien choisir entre RAG et ses alternatives : ce que personne ne vous explique vraiment ](/creer-saas-ia/rag)[ 07\. Comment concevoir un copilote IA qui crée de la vraie valeur dans un SaaS ](/creer-saas-ia/copilote-ia)[ 08\. POC IA : comment valider votre idée avant d’investir dans un SaaS IA ](/creer-saas-ia/poc) ### Blog de Lonestone Retrouvez nos derniers articles sur le développement web, l'IA, le product design et les retours d'expérience de nos projets. [Accéder au blog](/blog) Lonestone apporte son expertise product à 200+ grands comptes, PME et startups depuis 11 ans. Avec notre équipe senior et nos méthodes rodées, vous pouvez comptez sur une livraison rapide d'un produit robuste vraiment utile. ## Nos solutions [ 01\. Intégration IA pour éditeurs logiciels ](/solutions/integration-ia-editeurs)[ 02\. Automatisation de process avec IA ](/solutions/automatisation-process-ia)[ 03\. Création de SaaS pour startup ](/solutions/creation-saas)[ 04\. Développement d'outils internes ](/solutions/developpement-outil-metier)[ 05\. Création d'app mobile ](/solutions/creation-app-mobile)[ 06\. Création de site web ](/solutions/creation-site-web)[ 07\. Création de CRM sur mesure ](/solutions/crm-sur-mesure) ## On discute de votre projet ? Échange gratuit et sans engagement, directement avec un expert du sujet. Devis sous 48h. [Demander un devis](/contact) Prendre rdv Contacter l'équipe de Lonestone