Partage via

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

  • Article

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 communauté 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 de 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 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 requête donnée peut produire des niveaux de détail différents dans la réponse, en fonction des autorisations du demandeur et de l’autorisation.

  • Si une API vulnérable actuelle ne peut pas être modifiée au niveau du serveur principal, 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 serveur principal 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 rompue

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.
  • Vous pouvez utiliser la limitation de débit 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. Vous pouvez appliquer des groupes de sécurité réseau aux réseaux virtuels intégrés à Gestion des API.
  • Si possible, authentifiez-vous auprès des back-ends à partir de Gestion des API en utilisant des protocoles sécurisés et une identité managée ou un gestionnaire d’informations d’identification.
  • 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 à Gestion des API et les requêtes sortantes destinées aux back-ends.
  • Utilisez Microsoft Entra pour sécuriser l’accès au portail des développeurs Gestion des API.

Autorisation au niveau de la propriété d’objet rompue

Une bonne conception d’interface API est étonnamment difficile. 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 plus de champs de données que les applications consommatrices n’en ont besoin, donnant lieu à 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 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éconseillés, puis supprimés.
  • Dans Gestion des API, utilisez des révisions pour contrôler de manière appropriée les changements non cassants, comme l’ajout d’un champ à une interface, et utilisez des versions pour implémenter des changements cassants. 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 principaux.
  • 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 l’exécution de ressources, 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 appliquer 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 back-end prend de temps pour répondre, plus la connexion est occupée dans Gestion des API, ce qui réduit le nombre de requêtes pouvant être traitées dans un délai d’exécution 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 des jetons qui ne sont pas émis par Microsoft Entra, définissez une stratégie validate-jwt et appliquez les revendications de jeton requises. Si possible, exigez un délai 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 en raison d’autorisations insuffisantes.
  • 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 génériques (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 garantir qu’un certificat présenté par un client à une instance Gestion des API correspond aux règles de validation et 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 digitales du client. 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 Gestion des API 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 Gestion des API, 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.

Configuration incorrecte 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 protocole TLS de 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 Azure API Management :
    • 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’une limite réseau, la validation d’adresse IP du client est toujours possible à l’aide de la stratégie de limitation des adresses IP de l’appelant. Assurez-vous qu’il utilise une liste verte, et non une liste rouge.
    • Si des certificats clients sont utilisés entre l’appelant et Gestion des API, 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 serveur principal. Le serveur principal doit :
    • Avoir des informations d’identification d’autorisation configurées
    • 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 des valeurs nommées 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é managée pour vous authentifier auprès des coffres de clés.
  • Lorsque vous utilisez la passerelle auto-hébergée, 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 principaux en tant qu’entités principales. 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.
  • Si possible, utilisez le gestionnaire d’informations d’identification ou l’identité managée pour vous authentifier auprès des services back-end.
  • En cas d’utilisation du portail des développeurs :
    • Si vous choisissez d’héberger automatiquement 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 Microsoft Entra ID ou Azure Active Directory B2C pour l’inscription et la connexion des utilisateurs. Désactivez l’authentification par défaut du nom d’utilisateur et du mot de passe, ce qui est moins sécurisé.
    • Affectez des groupes d’utilisateurs aux produits pour contrôler la visibilité des API dans le portail.
  • Utilisez Azure Policy pour appliquer des autorisations de configuration au niveau des ressources et de contrôle d’accès en fonction du rôle (RBAC) API Management pour 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é déconseillée.

Gestion incorrecte des stocks

Les vulnérabilités liées à la gestion incorrecte des ressources 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 (Gestion incorrecte des stocks)

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 correctement 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 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 zone de surface d’attaque et compliquent l’évolution de l’API.
  • Utilisez des révisions et des versions dans Gestion des API pour gérer les modifications apportées aux API. Disposer d’une stratégie de contrôle de version principale forte et valider 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. Vérifiez que des contrôles de sécurité sont implémentés dans toutes les versions d’API disponibles.
  • Environnements distincts (comme développement, test et production) avec différents services Gestion des API. Vérifiez que chaque instance Gestion des API 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 principaux. 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 à l’aide d’espaces de travail.
  • Utilisez des balises pour organiser les API et les produits, et les regrouper pour la publication.
  • Publiez des API à des fins de consommation 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 Centre API de Microsoft Azure 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 fiables que les entrées d’API de l’appelant ou de l’utilisateur final. Si les normes de sécurité et de nettoyage appropriées 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 Gestion des API 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 Gestion des API ou consommées avec une stratégie send-request dans Gestion des API, utilisez les recommandations des autres sections de cette documentation pour garantir leur consommation sécurisée et contrôlée, notamment :
    • Vérifier que le transport sécurisé est activé et appliquer la configuration TLS/SSL
    • Si possible, s’authentifier avec le gestionnaire d’informations d’identification ou l’identité managée
    • Contrôler la consommation avec les stratégies rate-limit-by-key et quota-limit-by-key policies
    • 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
    • Configurer des délais d’attente et limiter la concurrence

Contenu connexe

Pour en savoir plus :