Sécurité des API en entreprise : une stratégie d’interfaces robuste en 5 étapes

12 min de lecture

Vos développeurs viennent de déployer la dernière mise à jour d’une API, le responsable produit fête le lancement – et personne n’a vérifié si le nouvel endpoint divulgue des données clients sans authentification. C’est précisément ainsi que surviennent les incidents de sécurité les plus coûteux dans les PME : non pas à cause de hackers sophistiqués, mais d’interfaces oubliées.

L’essentiel en bref

• 🚨 99 % des entreprises ont subi au moins un incident de sécurité lié aux API l’année dernière – les API sont le vecteur d’attaque numéro un
• 💰 Les incidents de sécurité liés aux API entraînent des coûts estimés à 186 milliards de dollars US par an dans le monde, y compris les sanctions de conformité et les dommages à la réputation
• 🔍 Les OWASP API Security Top 10 couvrent 128 types de vulnérabilités et constituent le cadre de vérification standard
• ⚙️ Un programme structuré de sécurité des API peut être mis en place en cinq étapes, de l’inventaire au monitoring
• 🎯 Les entreprises doivent prévoir un budget initial de 15 000 à 45 000 euros, selon l’ampleur de leur paysage d’API

Pourquoi la sécurité des API est une affaire de direction en 2026

Les API constituent le système nerveux de toute architecture IT moderne. CRM, ERP, plateforme cloud ou application mobile : sans interfaces de programmation, rien ne fonctionne. En parallèle, les API se développent plus vite que la capacité de la plupart des entreprises à les protéger. Dès 2022, Gartner prévoyait que les API deviendraient le principal vecteur d’attaque. En 2026, cette prédiction est devenue réalité.

Les chiffres sont éloquents : selon des études récentes, 99 % des organisations ont subi au moins un incident de sécurité lié aux API l’année dernière. Plus de 90 % des attaques web ciblent désormais des endpoints d’API. Et la plupart des entreprises ne peuvent même pas répondre à des questions fondamentales : combien d’endpoints d’API existent dans leur propre réseau ? Quelles autorisations chaque accès possède-t-il ?

Le cas Samsung Allemagne : quand une interface oubliée expose 270 000 enregistrements

La réalité du danger est illustrée par un incident survenu en mars 2025. Un attaquant utilisant le pseudonyme « GHNA » a obtenu un accès au système de tickets clients de Samsung Allemagne. La méthode n’était pas particulièrement sophistiquée : il a utilisé des identifiants volés en 2021 par le logiciel malveillant Racoon Infostealer sur l’ordinateur d’un employé de la société partenaire Spectos GmbH.

Résultat : 270 000 enregistrements clients contenant noms, adresses e-mail, numéros de commande, URL de suivi et communications de support ont été publiés publiquement. Le prestataire de sécurité Hudson Rock avait alerté Samsung des années auparavant sur ces identifiants compromis. Ils n’avaient jamais été réinitialisés.

Ce cas met en lumière trois problèmes fondamentaux présents dans de nombreuses entreprises : l’absence de rotation des identifiants dans les intégrations partenaires, l’absence de surveillance des modèles d’accès API inhabituels, et une visibilité insuffisante sur le paysage d’interfaces propre à l’entreprise.

„Les OWASP API Security Top 10 constituent un guide idéal pour une vérification structurée de la sécurité des API, offrant un bon rapport entre effort et bénéfice.“

GUTcert / Nimrod Briller, expert en sécurité informatique, février 2026

Étape 1 : Établir un inventaire des API – on ne peut pas protéger ce qu’on ne connaît pas

La première et plus importante étape semble banale, mais échoue le plus souvent en pratique. Moins de la moitié des API d’entreprise sont, selon Gartner, activement gérées. Le reste correspond aux soi-disant « Shadow APIs » : des interfaces créées par des équipes de développement pour des tests, utilisées pour des migrations ou oubliées lors d’un relancement.

Commencez par un scan automatisé de découverte d’API. Des outils comme Salt Security, Traceable ou Noname Security détectent les endpoints actifs dans le trafic réseau. Complétez ces résultats par une enquête manuelle auprès de toutes les équipes de développement : quelles API existent ? Lesquelles sont documentées ? Lesquelles ont des accès externes ?

Délai : Pour une entreprise de taille moyenne, prévoyez 2 à 4 semaines pour un inventaire complet. Le résultat doit être une documentation OpenAPI/Swagger de tous les endpoints actifs.

Étape 2 : Renforcer l’authentification et l’autorisation

L’autorisation défaillante au niveau des objets (Broken Object Level Authorization, BOLA) figure en première position des OWASP API Security Top 10 – et ce depuis des années. La raison : de nombreuses API vérifient bien qu’un utilisateur est connecté, mais pas qu’il est autorisé à accéder à l’objet demandé. Un attaquant modifie simplement l’ID dans l’URL et obtient accès à des données appartenant à d’autres utilisateurs.

La solution repose sur trois niveaux :

• OAuth 2.0 avec OpenID Connect comme standard d’authentification. Utilisation de jetons JWT avec algorithme RS256 et une durée de validité maximale de 15 minutes.
• Autorisation au niveau de l’objet pour chaque appel API. Chaque requête doit être vérifiée par rapport aux droits de l’utilisateur demandeur – et pas uniquement lors de la connexion.
• Moteur de politiques centralisé comme Open Policy Agent (OPA) ou Casbin, plutôt que de disperser la logique d’autorisation dans le code.

Budget : Pour la mise en œuvre d’une solution d’authentification centralisée via un service géré comme Auth0, Okta ou Keycloak, comptez entre 5 000 et 15 000 euros de frais de configuration, plus des frais de licence récurrents d’environ 2 euros par utilisateur et par mois.

Étape 3 : Mettre en œuvre la limitation de débit et la validation des entrées

Sans limitation de débit, toute API constitue une porte ouverte aux attaques par force brute, au credential stuffing et à l’exfiltration de données. Un modèle progressif s’est avéré efficace : limiter les accès anonymes à 100 requêtes par heure, les utilisateurs standard authentifiés à 1 000, et les intégrations premium à 10 000.

Parallèlement, chaque entrée d’API doit être strictement validée. Cela signifie : validation de schéma pour les charges utiles JSON, requêtes paramétrées contre les injections SQL, limitation de la taille des charges utiles et seuils de complexité pour les requêtes imbriquées. Les API Gateway comme Kong, Apigee ou AWS API Gateway offrent ces fonctionnalités par défaut.

Délai : La configuration de base d’un API Gateway avec limitation de débit prend 1 à 2 semaines pour une équipe expérimentée. L’ajustement fin par endpoint peut nécessiter 2 à 4 semaines supplémentaires.

Étape 4 : Intégrer les tests de sécurité dans la pipeline CI/CD

La sécurité des API ne doit pas se limiter à un audit ponctuel. Chaque mise à jour de code, chaque nouvel endpoint et chaque modification d’autorisation doivent être testés automatiquement. Cela s’obtient en intégrant des tests de sécurité directement dans la pipeline de déploiement.

Évaluez trois niveaux de test :

• Analyse statique (SAST) : SonarQube, Semgrep ou CodeQL analysent le code source à la recherche de vulnérabilités connues avant déploiement. Les hooks pre-commit détectent les secrets codés en dur.
• Analyse dynamique (DAST) : OWASP ZAP ou Burp Suite testent automatiquement les API en production sur les OWASP Top 10. Intégrez ces scans comme étape dans votre pipeline CI/CD.
• Tests d’intrusion manuels : pour les endpoints critiques traitant des données de paiement, des données personnelles ou des fonctions de contrôle, un test d’intrusion manuel par des experts externes reste indispensable.

Budget : OWASP ZAP est open source. Les solutions DAST commerciales coûtent à partir de 5 000 euros par an. Un test d’intrusion externe pour 20 à 50 endpoints API coûte entre 8 000 et 20 000 euros.

Étape 5 : Surveillance, réponse aux incidents et amélioration continue

La meilleure protection est inutile si personne ne remarque qu’un attaquant extrait des données depuis des semaines via une API oubliée. Mettez en place une surveillance spécifique aux API qui recueille au minimum les signaux suivants :

• Toutes les tentatives d’authentification ayant échoué
• Des modèles d’accès inhabituels sur des ID séquentiels (typique des attaques BOLA)
• Des pics de dépassement de limitation de débit
• Des accès à des endpoints marqués comme obsolètes (deprecated)
• Des charges utiles de réponse anormalement volumineuses

Outils comme Datadog, le stack ELK ou Splunk peuvent être étendus avec des tableaux de bord spécifiques aux API. Des plateformes spécialisées comme Salt Security ou Traceable offrent en outre des analyses comportementales et une détection automatique d’anomalies.

Important : Définissez un plan de réponse aux incidents spécifique aux API. Qui doit être alerté si un endpoint montre des accès inhabituels ? À quelle vitesse des clés API peuvent-elles être révoquées ? Samsung Allemagne aurait pu éviter l’incident si une alerte automatique avait été déclenchée à l’utilisation d’identifiants datant de quatre ans.

La position contraire : la sécurité des API n’est-elle pas simplement du bon génie logiciel ?

Certaines voix au sein de la communauté des développeurs affirment que la sécurité des API ne devrait pas être un sujet à part entière. Selon eux, qui écrit un code propre, valide les entrées et implémente correctement l’authentification n’a pas besoin d’une stratégie dédiée de sécurité des API.

Cet argument contient une part de vérité. En pratique, il échoue toutefois à cause de trois facteurs : premièrement, les écosystèmes d’API croissent plus vite que la capacité des équipes à les superviser. Deuxièmement, les architectures de microservices font que des dizaines d’équipes développent indépendamment des API sans standards de sécurité centralisés. Troisièmement, les données OWASP montrent que même les équipes expérimentées omettent systématiquement certains types de vulnérabilités, notamment les erreurs de logique métier et les vérifications d’autorisation.

La réponse se situe au milieu : un bon génie logiciel est la base, mais sans cadres organisationnels, vérifications automatisées et gouvernance centralisée, cela ne suffit pas.

Ce que change le BSI en 2026 : Grundschutz++ et sécurité lisible par machine

L’Office fédéral de la sécurité informatique (BSI) mène, avec le projet « Grundschutz++ », une modernisation approfondie. À partir de 2026, le référentiel IT-Grundschutz sera converti en un format JSON lisible par machine, qui fournira des interfaces pour les outils de gestion de la sécurité. Pour les entreprises, cela signifie concrètement que les exigences de sécurité des API pourront désormais être vérifiées automatiquement par rapport au catalogue Grundschutz.

Parallèlement, la directive NIS2 accentue la pression sur les entreprises pour sécuriser systématiquement l’ensemble de leur infrastructure IT – y compris les interfaces API. Toute entreprise qui exploite ou met en place un système de management de la sécurité de l’information (ISMS) devrait intégrer la sécurité des API comme module autonome.

Checklist : sécurité des API en entreprise en 90 jours

Semaine 1 à 4 : Découverte et inventaire

• Réaliser un scan automatisé de découverte d’API
• Documenter tous les endpoints actifs au format OpenAPI/Swagger
• Identifier et désactiver ou documenter les Shadow APIs
• Établir un inventaire des identifiants : quels API-Keys et comptes de service existent ?

Semaine 5 à 8 : Renforcement et tests

• Mettre en œuvre OAuth 2.0 / OpenID Connect comme méthode d’authentification standard
• Configurer la limitation de débit par endpoint
• Intégrer un scanner DAST dans la pipeline CI/CD
• Commander le premier test d’intrusion externe pour les endpoints critiques

Semaine 9 à 12 : Surveillance et gouvernance

• Mettre en place un tableau de bord de surveillance des API
• Définir des règles d’alerte pour les anomalies
• Publier une politique de sécurité des API pour toutes les équipes de développement
• Établir un cycle de revue trimestriel

Budget total estimé : Pour une entreprise de taille moyenne disposant de 50 à 200 endpoints API, comptez entre 15 000 et 45 000 euros pour la configuration initiale (outils, conseil, premier test d’intrusion). Les coûts récurrents de surveillance et de licences se situent entre 2 000 et 5 000 euros par mois.

Conclusion : Commencez par l’inventaire

La sécurité des API n’est pas un projet qui s’achève un jour. C’est un processus continu qui commence par une seule question : quelles interfaces existent dans notre entreprise, et qui y a accès ? Si vous ne pouvez pas répondre à cette question aujourd’hui, c’est votre première action à entreprendre.

Commencez cette semaine par l’inventaire des API. Pas d’achat d’outil, pas de conseil externe : rassemblez dans un tableau partagé avec vos équipes de développement tous les endpoints API connus, leur méthode d’authentification et la date du dernier examen. Cette simple démarche révélera des lacunes nécessitant une action immédiate.

Questions fréquentes

Qu’entend-on par sécurité des API ?

La sécurité des API englobe toutes les mesures destinées à protéger les interfaces de programmation contre les accès non autorisés, les abus de données et les attaques. Cela inclut l’authentification, l’autorisation, le chiffrement, la validation des entrées, la limitation de débit et une surveillance continue. Le cadre de référence est constitué par les OWASP API Security Top 10, qui décrivent les dix types de vulnérabilités les plus critiques pour les API.

Quelle est la vulnérabilité API la plus dangereuse ?

L’autorisation défaillante au niveau des objets (Broken Object Level Authorization, BOLA) figure en tête des OWASP API Security Top 10 depuis des années. Dans une attaque BOLA, un attaquant manipule l’ID d’objet dans une requête API et obtient ainsi accès aux données d’autres utilisateurs. Cette vulnérabilité survient lorsque l’API vérifie bien l’identité de l’utilisateur, mais pas ses droits d’accès à l’objet demandé.

Combien coûte la mise en œuvre de la sécurité des API dans les PME ?

Pour une entreprise de taille moyenne disposant de 50 à 200 endpoints API, les coûts initiaux se situent entre 15 000 et 45 000 euros. Cela inclut les outils de découverte d’API, la mise en œuvre d’une solution d’authentification centralisée, l’intégration de tests de sécurité dans la pipeline CI/CD et un premier test d’intrusion externe. Les coûts récurrents de surveillance et de licences d’outils s’élèvent à 2 000 à 5 000 euros par mois.

Combien d’API une entreprise typique possède-t-elle ?

Le nombre varie fortement, mais même les entreprises de taille moyenne exploitent souvent entre 50 et 300 endpoints API. Moins de la moitié sont, selon Gartner, activement gérés et documentés. Les Shadow APIs, c’est-à-dire les interfaces non documentées ou oubliées, représentent le plus grand risque, car elles fonctionnent souvent avec des autorisations obsolètes et sans surveillance.

Quel lien existe-t-il entre sécurité des API et NIS2 ?

La directive NIS2 oblige les entreprises des secteurs critiques à mettre en place une gestion systématique des risques pour leur infrastructure IT. Les API, en tant qu’interfaces de communication centrales, entrent explicitement dans son champ d’application. Les entreprises doivent prouver qu’elles ont inventorié, sécurisé et surveillé leurs interfaces. Les violations peuvent entraîner des amendes sévères.

Articles complémentaires sur le réseau SecurityToday

• Zero Trust pour les PME : démarrer en 5 étapes (SecurityToday)
• Sécurité de la chaîne d’approvisionnement 2026 : comment les entreprises protègent leur chaîne d’approvisionnement logiciel (SecurityToday)
• NIS2 en Allemagne : ce que les entreprises doivent savoir et mettre en œuvre maintenant (SecurityToday)
• Sécurité multi-cloud 2026 : les 5 plus grands risques et comment les résoudre (SecurityToday)
• AIOps : comment l’IA automatise l’exploitation cloud et prévient les pannes (cloudmagazin)
• Revenue Operations : ce qui se cache derrière l’essor du RevOps (MyBusinessFuture)

Source de l’image : Pexels / Tima Miroshnichenko

À propos de l'auteur: Tobias Massow

Plus d'articles de Tobias Massow