Recommandations pour atténuer les 10 principales menaces de la sécurité des API OWASP à l’aide d’API Management

S’APPLIQUE À : Tous les niveaux de Gestion des API

Remarque

Cet article a été mis à jour pour refléter la dernière liste OWASP API Security Top 10 pour 2023.

La fondation OWASP (Open Web Application Security Project) travaille pour améliorer la sécurité logicielle par le biais de ses projets logiciels open source communautaires, des centaines de chapitres dans le monde entier, des dizaines de milliers de membres et en hébergeant des conférences locales et internationales.

Le Projet de sécurité des API OWASP se concentre sur les stratégies et solutions pour comprendre et atténuer les vulnérabilités uniques et les risques de sécurité des API. Dans cet article, nous discutons des dernières recommandations pour atténuer les 10 principales menaces sur les API identifiées par OWASP dans sa liste 2023 à l’aide d’Gestion des API Azure.

Même si Gestion des API fournit des contrôles complets pour la sécurité des API, d’autres services Microsoft fournissent des fonctionnalités complémentaires pour détecter les menaces sur les API identifiées par OWASP ou s’en protéger :

Autorisation au niveau de l’objet rompue

Les objets API qui ne sont pas protégés avec le niveau d’autorisation approprié peuvent être vulnérables aux fuites de données et à la manipulation de données non autorisées par le biais d’identificateurs d’accès aux objets faibles. Par exemple, un attaquant peut exploiter un identificateur d’objet de type entier, qui peut être itéré.

Pour plus d’informations sur cette menace : API1:2023 Broken Object Level Authorization (Autorisation au niveau de l’objet rompue)

Recommandations

  • Le meilleur endroit pour implémenter l’autorisation au niveau de l’objet se trouve dans l’API back-end elle-même. Au niveau du back-end, les décisions d’autorisation correctes peuvent être prises au niveau de la requête (ou de l’objet), le cas échéant, en utilisant la logique applicable au domaine et à l’API. Envisagez des scénarios où une demande donnée peut produire des niveaux de détail différents dans la réponse, en fonction des autorisations et de l’autorisation du demandeur.

  • Si une API vulnérable actuelle ne peut pas être modifiée au niveau du backend, API Management peut être utilisé comme solution de secours. Par exemple :

    • Utilisez une stratégie personnalisée pour implémenter une autorisation au niveau de l’objet, si elle n’est pas implémentée dans le back-end.

    • Implémentez une stratégie personnalisée pour mapper les identificateurs de la requête au back-end et à partir du back-end au client, afin que les identificateurs internes ne soient pas exposés.

      Dans ces cas, la stratégie personnalisée peut être une expression de stratégie avec une recherche (par exemple, un dictionnaire) ou une intégration à un autre service via la stratégie send-request.

  • Pour les scénarios GraphQL, appliquez l’autorisation au niveau de l’objet via la stratégie validate-graphql-request, à l’aide de l’élément authorize.

Authentification défaillante

Le mécanisme d’authentification d’un site ou d’une API est particulièrement vulnérable, car il est ouvert aux utilisateurs anonymes. Les ressources et points de terminaison requis pour l’authentification, notamment les flux liés à l’oubli et à la réinitialisation de mots de passe, doivent être protégés pour empêcher toute exploitation.

Pour plus d’informations sur cette menace : API2:2023 Broken Authentication (Authentification rompue)

Recommandations

  • Utilisez Microsoft Entra pour implémenter l’authentification d’API. Microsoft Entra fournit automatiquement des points de terminaison de connexion protégés, résilients et distribués géographiquement. Utilisez la stratégie validate-azure-ad-token pour valider les jetons Microsoft Entra dans les requêtes d’API entrantes.
  • Lorsque l’authentification est requise, Gestion des API prend en charge la validation des jetons OAuth 2, l’authentification de base, les certificats clients et les clés API.
    • Vérifiez la configuration appropriée des méthodes d’authentification. Par exemple, définissez require-expiration-time et require-signed-tokens sur true lors de la validation des jetons OAuth2 à l’aide de la stratégie validate-jwt.
  • La limitation du débit de requêtes peut être utilisée pour réduire l’efficacité des attaques par force brute.
  • Vous pouvez utiliser le filtrage IP des clients pour réduire la surface d’attaque. Les groupes de sécurité réseau peuvent être appliqués aux réseaux virtuels intégrés à API Management.
  • Si possible, authentifiez-vous auprès des backends depuis API Management à l'aide de protocoles sécurisés et d'une identité managée ou d'un gestionnaire d'informations d'identification pour vous authentifier auprès des backends.
  • Vérifiez que les jetons ou les clés sont passés dans des en-têtes, et non des URL, pour les requêtes entrantes destinées à API Management et les requêtes sortantes destinées aux back-ends.
  • Utilisez Microsoft Entra pour sécuriser l’accès au portail des développeurs d’API Management.

Autorisation défaillante au niveau des propriétés des objets

Une bonne conception d’interface API est plus difficile qu’il n’y paraît. Souvent, en particulier avec les API héritées qui ont évolué au fil du temps, les interfaces de requête et de réponse contiennent davantage de champs de données que ce dont les applications clientes ont besoin, ce qui permet des attaques par injection de données. Les attaquants peuvent également découvrir des interfaces non documentées. Ces vulnérabilités peuvent permettre à l’attaquant d’obtenir des données sensibles.

Pour plus d’informations sur cette menace : API3:2023 Broken Object Property Level Authorization (Autorisation au niveau de la propriété d’objet rompue)

Recommandations

  • La meilleure approche pour atténuer cette vulnérabilité consiste à s’assurer que les interfaces externes définies sur l’API back-end sont conçues avec soin et, dans l’idéal, indépendamment de la persistance des données. Ils doivent contenir uniquement les champs requis par les consommateurs de l’API. Les API doivent être examinées fréquemment et les champs hérités dépréciés, puis supprimés.
  • Dans API Management, utilisez des révisions pour contrôler de manière appropriée les changements non disruptifs, comme l’ajout d’un champ à une interface, et utilisez des versions pour implémenter des changements avec rupture de compatibilité. Vous devez également versionner les interfaces back-end, qui ont généralement un cycle de vie différent de celui des API destinées aux consommateurs.
  • Découplez les interfaces API externes de l’implémentation des données internes. Évitez de lier des contrats d’API directement aux contrats de données dans les services back-end.
  • S’il n’est pas possible de modifier la conception de l’interface principale et si les données excessives sont une préoccupation, utilisez les stratégies de transformation API Management pour réécrire les charges utiles de réponse et masquer ou filtrer les données. Vous pouvez utiliser la validation du contenu dans Gestion des API avec un schéma XML ou JSON pour bloquer les réponses avec des propriétés non documentées ou des valeurs incorrectes. Par exemple, supprimez les propriétés JSON inutiles d’un corps de réponse. Le blocage des requêtes avec des propriétés non documentées atténue les attaques, tandis que le blocage des réponses avec des propriétés non documentées rend plus difficile l’ingénierie inverse des vecteurs d’attaque potentiels. La stratégie validate-content prend également en charge le blocage des réponses dépassant une taille spécifiée.
  • Utilisez la stratégie validate-status-code pour bloquer les réponses avec des erreurs non définies dans le schéma de l’API.
  • Utilisez la stratégie validate-headers pour bloquer les réponses avec des en-têtes qui ne sont pas définis dans le schéma ou qui ne sont pas conformes à leur définition dans le schéma. Supprimez les en-têtes indésirables avec la stratégie set-header.
  • Pour les scénarios GraphQL, utilisez la stratégie de validate-graphql-request pour valider les requêtes GraphQL, autoriser l’accès à des chemins d’accès de requête spécifiques et limiter la taille des réponses.

Consommation de ressources illimitée

Les API nécessitent des ressources pour fonctionner, comme la mémoire ou le processeur, et peuvent inclure des intégrations en aval qui représentent un coût d’exploitation (par exemple, des services avec paiement par requête). L’application de limites peut aider à protéger les API contre une consommation excessive de ressources.

Pour plus d’informations sur cette menace : API4:2023 Unrestricted Resource Consumption (Consommation de ressources illimitée)

Recommandations

  • Utilisez la stratégie rate-limit-by-key ou rate-limit pour appliquer une limitation sur des fenêtres de temps plus courtes. Appliquez des stratégies de limitation de débit plus strictes sur les points de terminaison sensibles, notamment concernant les opérations de réinitialisation de mot de passe, de connexion ou d’inscription, ou sur les points de terminaison qui consomment des ressources importantes.
  • Utilisez la stratégie quota-by-key ou quota-limit pour contrôler le nombre autorisé d’appels d’API ou la bande passante pendant des périodes plus longues.
  • Optimisez les performances avec la mise en cache intégrée, réduisant ainsi la consommation de ressources processeur, mémoire et réseau pour certaines opérations.
  • Appliquez des stratégies de validation.
    • Utilisez l’attribut max-size dans la stratégie validate-content pour imposer la taille maximale des requêtes et des réponses.
    • Définissez des schémas et des propriétés, tels que la longueur de chaîne ou la taille maximale du tableau, dans la spécification de l’API. Utilisez les stratégies validate-content, validate-parameters et validate-headers pour appliquer ces schémas pour les requêtes et les réponses.
    • Utilisez la stratégie validate-graphql-request pour les API GraphQL et configurez les paramètres max-depth et max-size.
    • Configurez des alertes dans Azure Monitor en cas de consommation excessive de données par les utilisateurs.
  • Pour les API d’IA générative :
  • Réduisez le temps nécessaire à un service back-end pour répondre. Plus le service backend met de temps à répondre, plus la connexion reste occupée dans API Management, ce qui réduit le nombre de requêtes pouvant être traitées dans un laps de temps donné.
    • Définissez timeout dans la stratégie forward-request et efforcez-vous d’obtenir la valeur acceptable la plus courte.
    • Limitez le nombre de connexions back-end parallèles avec la stratégie limit-concurrency.
  • Appliquez une stratégie CORS pour contrôler les sites web autorisés à charger les ressources servies via l’API. Pour éviter les configurations trop permissives, n'utilisez pas de valeurs génériques (*) dans la stratégie CORS.
  • Bien qu’Azure offre à la fois une protection au niveau de la plateforme et une protection renforcée contre les attaques par déni de service distribué (DDoS), il est possible d’améliorer la protection des applications (couche 7) pour les API en déployant un service de protection bot devant Gestion des API, comme Azure Application Gateway, Azure Front Door ou Azure DDoS Protection. Lorsque vous utilisez une stratégie de pare-feu d’applications web (WAF) avec Azure Application Gateway ou Azure Front Door, envisagez d’utiliser Microsoft_BotManagerRuleSet_1.0.

Autorisation au niveau de la fonction rompue

Les stratégies de contrôle d’accès complexes avec des hiérarchies, groupes et rôles différents, et une séparation peu claire entre les fonctions administratives et régulières, entraînent des failles d’autorisation. En exploitant ces problèmes, les attaquants accèdent aux fonctions administratives ou aux ressources d’autres utilisateurs.

Pour plus d’informations sur cette menace : API5:2023 Broken function level authorization (Autorisation au niveau de la fonction rompue)

Recommandations

  • Par défaut, protégez tous les points de terminaison d’API dans Gestion des API avec des clés d’abonnement ou la stratégie d’autorisation au niveau de toutes les API. Le cas échéant, définissez d’autres stratégies d’autorisation pour des API ou des opérations d’API spécifiques.
  • Validez les jetons OAuth à l’aide de stratégies.
    • Utilisez la stratégie validate-azure-ad-token pour valider les jetons Microsoft Entra. Spécifiez toutes les revendications requises et, le cas échéant, spécifiez les applications autorisées.
    • Pour valider les jetons qui n'ont pas été émis par Microsoft Entra, définissez une stratégie validate-jwt et imposez les revendications de jeton requises. Si possible, exigez une heure d'expiration.
    • Si possible, utilisez des jetons chiffrés ou listez des applications spécifiques pour l’accès.
    • Surveillez et examinez les requêtes rejetées faute d’autorisation.
  • Utilisez un réseau virtuel Azure ou Private Link pour masquer les points de terminaison d’API à partir d’Internet. En savoir plus sur les options de réseau virtuel avec API Management.
  • Ne définissez pas d’opérations d’API avec caractère générique (autrement dit, les API qui interceptent tout avec *  comme chemin d’accès). Assurez-vous qu’API Management sert uniquement les requêtes pour les points de terminaison définis explicitement et que les requêtes aux points de terminaison non définis sont rejetées.
  • Ne publiez pas d’API avec des produits ouverts qui ne nécessitent pas d’abonnement.
  • Si les adresses IP des clients sont connues, utilisez une stratégie ip-filter pour autoriser le trafic uniquement à partir d’adresses IP autorisées.
  • Utilisez la stratégie validate-client-certificate pour vérifier qu'un certificat présenté par un client à une instance d'API Management correspond aux règles de validation et aux revendications spécifiées.

Accès illimité aux flux métier sensibles

Les API peuvent exposer un large éventail de fonctionnalités à l’application consommatrice. Il est important que les auteurs d’API comprennent les flux métier fournis par l’API et la sensibilité associée. Le risque pour l’entreprise est plus élevé si les API qui exposent les flux sensibles n’implémentent pas les protections appropriées.

Pour plus d’informations sur cette menace : API6:2023 Unrestricted Access to Sensitive Business Flows (Accès illimité aux flux métier sensibles)

Recommandations

  • Réduisez ou bloquez l'accès en fonction des empreintes numériques des clients. Par exemple, utilisez la stratégie return-response avec la stratégie choose pour bloquer le trafic provenant de navigateurs sans interface utilisateur graphique en fonction de l’en-tête User-Agent ou de la cohérence des autres en-têtes.
  • Utilisez la stratégie validate-parameters pour garantir que les en-têtes de requête correspondent à la spécification de l’API.
  • Utilisez la stratégie ip-filter pour autoriser uniquement les requêtes provenant d’adresses IP connues ou refuser l’accès à partir d’adresses IP spécifiques.
  • Utilisez des fonctionnalités de mise en réseau privée pour limiter la connectivité externe aux API internes.
  • Utilisez la stratégie rate-limit-by-key pour limiter les pics de consommation d’API en fonction de l’identité de l’utilisateur, de l’adresse IP ou d’une autre valeur.
  • Placez le service Azure Application Gateway ou Azure DDoS Protection devant Gestion des API pour détecter et bloquer le trafic de bots.

Falsification de requête côté serveur

Une vulnérabilité à la falsification de requête côté serveur peut se produire lorsque l’API récupère une ressource en aval en fonction de la valeur d’une URL qui a été passée par l’appelant d’API sans contrôles de validation appropriés.

Pour plus d’informations sur cette menace : API7:2023 Server Side Request Forgery (Falsification de requête côté serveur)

Recommandations

  • Si possible, n’utilisez pas les URL fournies dans les charges utiles des clients, par exemple, comme paramètres pour les URL back-end, la stratégie send-request ou la stratégie rewrite-url.
  • Si API Management ou les services back-end utilisent les URL fournies dans la charge utile de la requête pour la logique métier, définissez et appliquez une liste limitée de noms d’hôtes, de ports, de types de supports ou d’autres attributs avec des stratégies dans API Management, telles que la stratégie choose et les expressions de stratégie.
  • Définissez l’attribut timeout dans les stratégies forward-request et send-request.
  • Validez et nettoyez les données de requête et de réponse avec des stratégies de validation. Si nécessaire, utilisez la stratégie set-body pour traiter la réponse et éviter de retourner des données brutes.
  • Utilisez la mise en réseau privée pour restreindre la connectivité. Par exemple, si l’API n’a pas besoin d’être publique, limitez la connectivité à partir d’Internet pour réduire la surface d’attaque.

Mauvaise configuration de la sécurité

Les attaquants peuvent tenter d’exploiter des vulnérabilités de configuration incorrecte de la sécurité, telles que :

  • Renforcement de la sécurité manquant
  • Fonctionnalités activées inutilement
  • Connexions réseau à Internet inutilement ouvertes
  • Utilisation de protocoles ou de chiffrements faibles

Pour plus d’informations sur cette menace : API8:2023 Security misconfiguration (Mauvaise configuration de la sécurité)

Recommandations

  • Configurez correctement le TLS de la passerelle. N’utilisez pas de protocoles (par exemple, TLS 1.0, 1.1) ni de chiffrements vulnérables.
  • Configurez les API pour accepter le trafic chiffré uniquement, par exemple via des protocoles HTTPS ou WSS. Vous pouvez auditer et appliquer ce paramètre en utilisant Azure Policy.
  • Envisagez de déployer API Management derrière un point de terminaison privé ou attaché à un réseau virtuel déployé en mode interne. Dans les réseaux internes, l’accès peut être contrôlé à partir du réseau privé (via un pare-feu ou des groupes de sécurité réseau) et à partir d’Internet (via un proxy inverse).
  • Utilisez des stratégies Gestion des API Azure :
    • Héritez toujours des stratégies parentes par le biais de la balise <base>.
    • Lorsque vous utilisez OAuth 2.0, configurez et testez la stratégie validate-jwt pour vérifier l’existence et la validité du jeton JWT avant qu’il n’atteigne le back-end. Vérifiez automatiquement l’heure d’expiration du jeton, la signature de jeton et l’émetteur. Appliquez les revendications, les audiences, l’expiration du jeton et la signature de jeton par le biais des paramètres de stratégie. Si vous utilisez Microsoft Entra, la stratégie validate-azure-ad-token offre un moyen plus complet et plus facile de valider les jetons de sécurité.
    • Configurez la stratégie CORS et n’utilisez le caractère générique * pour aucune option de configuration. Au lieu de cela, répertoriez explicitement les valeurs autorisées.
    • Définissez des stratégies de validation dans les environnements de production pour valider les schémas JSON et XML, les en-têtes, les paramètres de requête et les codes d’état, et pour appliquer la taille maximale pour la requête ou la réponse.
    • Si API Management se trouve en dehors d’un périmètre réseau, la validation d’adresse IP du client est toujours possible à l’aide de la stratégie restreindre les adresses IP de l’appelant. Assurez-vous qu’il utilise une liste d’autorisation, et non une liste de blocage.
    • Si des certificats clients sont utilisés entre l’appelant et API Management, utilisez la stratégie validate-client-certificate. Vérifiez que les attributs validate-revocation, validate-trust, validate-not-before et validate-not-after sont tous définis sur true.
  • Les certificats clients (TLS mutuel) peuvent également être appliqués entre API Management et le back-end. Le serveur principal doit :
    • Identifiants d’autorisation configurés
    • Valider la chaîne de certificats, le cas échéant
    • Valider le nom du certificat, le cas échéant
    • Pour les scénarios GraphQL, utilisez la stratégie validate-graphQL-request. Vérifiez que l’élément authorization et les attributs max-size et max-depth sont définis.
  • Ne stockez pas les secrets dans les fichiers de stratégie ou dans le contrôle de code source. Utilisez toujours les valeurs nommées d’API Management ou récupérez les secrets au moment de l’exécution à l’aide d’expressions de stratégie personnalisées. Les valeurs nommées doivent être intégrées à Azure Key Vault ou chiffrées dans Gestion des API en étant marquées comme « secrètes ». Ne stockez jamais de secrets dans des valeurs nommées en texte brut.
  • Publiez des API via des produits qui nécessitent des abonnements. N’utilisez pas de produits ouverts qui ne nécessitent pas d’abonnement.
  • Vérifiez que vos API exigent des clés d’abonnement, même si tous les produits sont configurés pour exiger ces clés. En savoir plus
  • Exigez l’approbation de l’abonnement pour tous les produits et examinez attentivement toutes les requêtes d’abonnement.
  • Utilisez l’intégration Key Vault pour gérer tous les certificats. Cela centralise la gestion des certificats et peut faciliter les tâches de gestion des opérations telles que le renouvellement ou la révocation de certificats. Utilisez une identité gérée pour vous authentifier auprès des coffres de clés Key Vault.
  • Lorsque vous utilisez la self-hosted-gateway, assurez-vous qu’il existe un processus en place pour mettre à jour l’image régulièrement vers la dernière version.
  • Représente les services backend en tant qu’entités backend. Configurez les informations d’identification d’autorisation, la validation de la chaîne de certificats et la validation de nom de certificat le cas échéant.
  • Assurez-vous que vos serveurs sont protégés contre les attaques de traversée de répertoire. La gestion API peut transférer des requêtes contenant ..%2f ou des séquences de traversées déguisées similaires (par exemple %2e%2e ou ..;) dans le chemin de l’URL vers un backend. Si le backend les décode en ../, il pourrait être vulnérable à une attaque de traversée de chemin. Vous pouvez également appliquer une politique dans la gestion d’API pour détecter et bloquer les requêtes contenant de telles séquences dans le chemin.
  • Si possible, utilisez le gestionnaire d’informations d’identification ou l’identité managée pour vous authentifier auprès des services back-end.
  • Lors de l’utilisation du portail développeur :
    • Si vous choisissez d’héberger vous-même le portail des développeurs, assurez-vous qu’il existe un processus en place pour mettre régulièrement à jour le portail auto-hébergé vers la dernière version. Les mises à jour de la version gérée par défaut sont automatiques.
    • Utilisez l’ID Microsoft Entra ou l’ID externe Microsoft Entra pour l’inscription et la connexion de l’utilisateur. Désactivez l’authentification par nom d’utilisateur et mot de passe par défaut, car elle est moins sécurisée.
    • Affectez des groupes d’utilisateurs aux produits pour contrôler la visibilité des API dans le portail.
  • Utilisez Azure Policy pour appliquer la configuration au niveau des ressources d’API Management et les autorisations de contrôle d’accès en fonction du rôle (RBAC) afin de contrôler l’accès aux ressources. Accordez les privilèges minimaux requis à chaque utilisateur.
  • Utilisez une approche de processus DevOps et d’infrastructure en tant que code en dehors d’un environnement de développement pour garantir la cohérence des modifications de configuration et de contenu API Management et réduire les erreurs humaines.
  • N’utilisez aucune fonctionnalité obsolète.

Gestion incorrecte des stocks

Les vulnérabilités liées à la gestion incorrecte des actifs sont les suivantes :

  • Absence de documentation sur l’API ou d’informations de propriété appropriées
  • Nombre excessif de versions d’API plus anciennes, qui peuvent manquer de correctifs de sécurité

Pour plus d’informations sur cette menace : API9:2023 Improper inventory management (Mauvaise gestion de l’inventaire)

Recommandations

  • Utilisez une spécification OpenAPI bien définie comme source pour l’importation d’API REST. La spécification permet l’encapsulation de la définition d’API, y compris les métadonnées auto-documentées.
  • Utilisez des interfaces API avec des chemins précis, des schémas de données, des en-têtes, des paramètres de requête et des codes d’état. Évitez les opérations avec caractères génériques. Fournissez des descriptions pour chaque API et opération, et incluez les informations de contact et de licence.
  • Évitez les points de terminaison qui ne contribuent pas directement à l’objectif métier. Ils augmentent inutilement la surface d’attaque et compliquent l’évolution de l’API.
  • Utilisez des révisions et des versions dans API Management pour gérer les modifications apportées aux API. Disposer d’une solide stratégie de gestion de versions côté back-end et s’engager à prendre en charge un nombre maximal de versions d’API prises en charge (par exemple, 2 ou 3 versions antérieures). Envisagez de déprécier et de supprimer rapidement les versions plus anciennes, souvent moins sécurisées, d’API. Assurez-vous que des contrôles de sécurité sont implémentés dans toutes les versions d’API disponibles.
  • Séparez les environnements (par exemple, développement, test et production) à l'aide de services API Management distincts. Assurez-vous que chaque service API Management se connecte à ses dépendances dans le même environnement. Par exemple, dans l’environnement de test, la ressource de test API Management doit se connecter à une ressource de test Azure Key Vault et aux versions de test des services back-end. Utilisez des pratiques d’automatisation et d’infrastructure en tant que code DevOps pour vous aider à maintenir la cohérence et la précision entre les environnements et à réduire les erreurs humaines.
  • Isolez les autorisations administratives sur les API et les ressources associées au moyen des espaces de travail.
  • Utilisez des balises pour organiser les API et les produits, et les regrouper pour la publication.
  • Publiez des API pour permettre leur utilisation via un portail des développeurs. Vérifiez que la documentation de l’API est à jour.
  • Découvrez les API non documentées ou non managées, et exposez-les via API Management pour un meilleur contrôle.
  • Utilisez le Azure API Center pour conserver un inventaire complet et centralisé des API, des versions et des déploiements, même si les API ne sont pas gérées dans Gestion des API Azure.

Consommation non sécurisée des API

Les ressources obtenues par le biais d’intégrations en aval ont tendance à être plus dignes de confiance que les entrées d’API de l’appelant ou de l’utilisateur final. Si les normes appropriées de validation des entrées et de sécurité ne sont pas appliquées, l’API peut être vulnérable, même si l’intégration est fournie via un service approuvé.

Pour plus d’informations sur cette menace : API10:2023 Unsafe Consumption of APIs (Consommation non sécurisée des API)

Recommandations

  • Envisagez d’utiliser API Management pour servir de façade aux dépendances en aval avec lesquelles les API back-end s’intègrent.
  • Si les dépendances en aval sont frontalisées avec API Management ou consommées avec une stratégie send-request dans API Management, utilisez les recommandations des autres sections de cette documentation pour garantir leur consommation sécurisée et contrôlée, notamment :
    • Vérifiez que le transport sécurisé est activé et imposez la configuration TLS/SSL
    • Si possible, s’authentifier avec le gestionnaire d’identifiants ou l’identité gérée
    • Contrôler la consommation avec les stratégies rate-limit-by-key et quota-limit-by-key
    • Consigner ou bloquer les réponses non conformes à la spécification de l’API à l’aide des stratégies validate-content et validate-header
    • Transformer les réponses avec la stratégie set-body, par exemple pour supprimer des informations inutiles ou sensibles
    • Configurez les délais d'expiration et limitez la concurrence

Contenu connexe

Pour en savoir plus :

  • Dernière mise à jour :