Qu'est-ce qu'une API REST ?
Une API REST est une API qui se conforme à des contraintes architecturales spécifiques associées aux applications web, notamment la communication sans état et les données pouvant être mises en cache. Les API REST permettent aux applications de navigateur, aux applications mobiles et à d'autres clients API de communiquer avec un serveur. Voici les 10 principales directives de sécurité pour les API REST, basées sur les expériences des clients et les problèmes mis en évidence dans le récent rapport sur l'état de la sécurité des API de Salt Security. Dès que le temps et les ressources le permettent, envisagez d'adopter l'ensemble complet des bonnes pratiques de sécurité des API décrites dans le guide des bonnes pratiques de sécurité des API de Salt. Vous pouvez également utiliser la liste de contrôle de sécurité des API correspondante pour suivre les tâches associées.
Contrairement à d'autres types d'API, REST est un style plutôt qu'une norme stricte. Les API REST peuvent être conçues de nombreuses manières, ce qui influe sur la façon dont les fonctionnalités sont invoquées ou dont les données sont transmises dans une requête. Le schéma de l'API REST et la structure des URL des points de terminaison qui en résultent peuvent varier considérablement d'une organisation à l'autre. Les API REST sont mises en œuvre, exploitées ou utilisées par de nombreux rôles au sein d'une organisation, notamment les équipes de développement, de produit, d'exploitation, de sécurité des applications et des opérations de sécurité. Les API REST sont l'un des types de services web les plus courants aujourd'hui. Il est impératif de concevoir correctement les API REST en tenant compte de la sécurité, des performances et de la facilité d'utilisation pour les consommateurs de l'API REST.
Top 10 des directives de sécurité pour les API REST
1. Lors de la génération de la documentation de l'API REST, privilégiez les formats machine et les définitions de schéma plutôt que la documentation traditionnelle ou les diagrammes visuels.
Pour les API REST, ces formats machine sont le plus souvent Swagger ou OAS. Selon la conception de votre API REST, le développement ou les outils de publication, d'autres formats comme RAML ou REST API Blueprint peuvent être utilisés. La documentation traditionnelle peut être utile pour les revues par un public moins technique, mais ces formes de documentation ne sont pas facilement maintenables. Les formats de définition de schéma d'API REST sont conçus pour une génération rapide de documentation dans le cadre de la conception et du prototypage d'API REST, et sont également réutilisables pour les tests, l'intégration, la publication et les opérations.
2. Découvrez les API REST dans les environnements hors production, et pas seulement en production.
Il est crucial de suivre les environnements inférieurs, notamment QA, UAT, staging, SIT et pré-production, en plus de vos environnements de production. Les attaquants savent que les environnements hors production ont souvent des contrôles de sécurité plus souples, voire inexistants, alors que les API REST dans ces environnements peuvent toujours permettre d'accéder à des ensembles similaires de fonctionnalités et de données. Les organisations configurent souvent des environnements inférieurs avec un durcissement minimal pour favoriser un développement et une intégration rapides afin de respecter les objectifs de production et les calendriers de publication. Les environnements inférieurs peuvent également être exposés à Internet, ce qui augmente encore le risque de sécurité.
3. Incluez les dépendances de vos API REST.
Ne vous limitez pas aux API REST développées en interne ; incluez également les API REST issues de logiciels open source, de progiciels acquis et de services SaaS tiers. Les préoccupations de sécurité des API REST ne commencent et ne se terminent pas avec vos seules API REST personnalisées. L'attestation des risques des fournisseurs et les clauses contractuelles sont principalement des mesures réactives offrant un recours juridique, mais elles n'offrent qu'une garantie minimale au niveau technologique. Les organisations sont intrinsèquement limitées par les options de configuration qui relèvent de leur contrôle pour les services tiers. Cette limitation n'exonère toutefois pas l'organisation des risques de sécurité. Des écarts importants existent souvent entre la conception perçue d'une application et ses API REST par rapport au système intégré livré. La combinaison d'API créées, intégrées et acquises définit la chaîne d'approvisionnement numérique au sein de laquelle toutes les organisations travaillent. De même, vous devez également prendre en compte d'autres types d'API, tels que gRPC, GraphQL et SOAP.
4. Analysez automatiquement le code de l'API REST dans la mesure du possible.
Analysez le code automatiquement avec des outils d'analyse statique tels que des vérificateurs de qualité de code et des tests de sécurité des applications statiques (SAST) lors de la validation du code dans les systèmes de contrôle de version tels que git et/ou dans les pipelines de build CI/CD. Si vous examinez le code manuellement, le processus atteindra rapidement ses limites face au rythme de changement que la plupart des organisations connaissent dans leur code et leurs API REST. Analysez la base de code intégrée dans le cadre de la construction au sein de la CI/CD pour obtenir l'analyse la plus précise, bien que certaines organisations choisissent également d'analyser des morceaux de code au fur et à mesure qu'ils sont validés dans le contrôle de version pour plus de rapidité. Un vérificateur de qualité de code est l'outil le moins spécialisé, mais ils sont souvent nombreux dans les organisations car de nombreux outils de conception et de développement incluent des capacités natives de vérification de la qualité du code. Le SAST peut être fourni via des linters spécifiques au langage ou une offre d'analyse de qualité commerciale. Quel que soit l'outil que vous choisissez, attendez-vous à un nombre élevé de résultats concernant des faiblesses potentielles et des faux positifs, en particulier si une base de code n'a jamais été analysée. Les analyseurs statiques nécessitent notoirement un réglage pour être utilisés efficacement. L'analyse statique ne pourra pas couvrir les failles de logique métier par conception, ce qui nécessite une analyse du comportement au moment de l'exécution.
5. Médiatisez les API REST pour appliquer le contrôle d'accès.
Les passerelles d'API sont souvent déployées pour assurer la visibilité et le contrôle des appels d'API REST destinés aux échanges de données ou aux fonctionnalités. Ces passerelles constituent des mécanismes de médiation fondamentaux qui assurent la gestion du trafic, l'authentification et l'autorisation. Les fonctions de gestion du trafic correspondent aux contrôles de sécurité réseau classiques, tels que la limitation du débit ou les listes d'autorisation et de refus d'adresses IP. Les passerelles d'API sont également l'endroit idéal pour appliquer l'authentification et l'autorisation pour les API REST, comme OpenID Connect (OIDC) et OAuth2 respectivement. En règle générale, les passerelles d'API sont associées à des systèmes externes de gestion des identités et des accès (IAM) afin de répartir la charge liée au stockage de tous les types d'identités d'utilisateurs ou de machines, à l'authentification de ces identités, à leur autorisation et au maintien de pistes d'audit de toute activité. La consommation de vos API REST par des machines (dans le cadre de cas d'utilisation d'automatisation ou d'intégration de partenaires, par exemple) peut être tout aussi prédominante que la consommation traditionnelle par les utilisateurs finaux via des applications basées sur navigateur ou des applications mobiles.
6. Utilisez un transport chiffré pour protéger les données transmises par vos API REST.
Le protocole TLS doit être activé pour tous les points de terminaison d'API REST afin de protéger les données en transit. Visez au minimum TLS 1.2 et, idéalement, activez TLS 1.3 si les autres éléments architecturaux le permettent. Toutes les versions de SSL doivent être désactivées en raison du nombre de faiblesses inhérentes au protocole ou aux suites de chiffrement associées. Des composants d'infrastructure hérités subsistent parfois au sein des organisations ou chez les fournisseurs, imposant le maintien de SSL ou d'anciennes versions de TLS. Certains outils d'inspection du trafic peuvent également ne pas prendre en charge les protocoles de chiffrement plus récents, ce qui place les organisations dans une situation délicate lorsqu'elles souhaitent conserver une visibilité sur leur trafic réseau. Malheureusement, la prise en charge d'anciens protocoles et suites de chiffrement expose l'organisation à un certain nombre d'attaques cryptographiques et de rétrogradation, pouvant rendre les données chiffrées lisibles par des parties non autorisées. Appliquez les politiques de chiffrement via vos couches de médiation d'API REST dans la mesure du possible et assurez-vous que les protocoles et suites de chiffrement obsolètes restent désactivés. Si nécessaire, refondez ou réarchitecturez l'infrastructure de support de vos API REST en optant pour des points de terminaison TLS qui vous permettent de maintenir la visibilité du trafic tout en atténuant les risques de sécurité liés aux attaques sur les protocoles de chiffrement.
7. Évitez d'envoyer trop de données aux clients de l'API REST.
Les clients d'API REST ou le code front-end prennent généralement la forme de JavaScript s'exécutant dans un navigateur web ou de binaires d'application sur un appareil mobile. Les API REST back-end sont parfois conçues pour fournir une grande quantité de données en réponse aux appels d'API, et il incombe alors au code client front-end de filtrer ce qui doit être visible en fonction des objectifs de l'expérience utilisateur (UX) ou des niveaux d'autorisation. Ce modèle de conception va à l'encontre des meilleures pratiques de sécurité des API REST, car ces données sont entièrement visibles en observant les requêtes et les réponses de l'API REST. Les attaquants procèdent couramment à l'ingénierie inverse du code front-end et interceptent directement le trafic de l'API REST pour voir quelles données sont réellement transmises. Ce problème figure dans le Top 10 de la sécurité des API REST de l'OWASP sous la référence API3:2019 Exposition excessive de données, car il est très courant. N'envoyez pas trop de données, en particulier des données sensibles ou privées, aux clients front-end et présumez toujours qu'ils sont compromis. Filtrez les données de manière appropriée dans le back-end et n'envoyez que les données nécessaires à ce consommateur d'API REST particulier.
8. Authentifiez et autorisez en continu les consommateurs d'API REST.
Le contrôle d'accès a toujours impliqué l'authentification et l'autorisation. L'authentification (AuthN) consiste à identifier le demandeur d'une fonction ou d'une ressource donnée et à mettre cette entité au défi de fournir des éléments d'authentification ou des identifiants. L'autorisation (AuthZ) consiste à vérifier si cette entité authentifiée dispose réellement des autorisations nécessaires pour exercer une fonction ou pour lire, écrire, mettre à jour ou supprimer des données. Traditionnellement, ces deux opérations étaient traitées au début d'une session. Dans le monde du web, et par extension des API REST, les sessions sont sans état. Les environnements d'exploitation des back-ends et des front-ends ne sont pas garantis et sont souvent éphémères. De plus, les environnements sont de plus en plus sujets à des problèmes d'intégrité ou de compromission, d'où l'essor des architectures « zero trust ». Par conséquent, vous devez vérifier en permanence si une identité d'utilisateur ou de machine doit avoir accès à une ressource donnée et toujours présumer que la session authentifiée pourrait être compromise. Cette approche nécessite d'analyser les comportements d'une session donnée pour un consommateur d'API REST, et potentiellement de mettre fin à cette session, d'exiger une authentification renforcée ou de bloquer l'accès si nécessaire.
9. Explorez l'analyse comportementale et la détection d'anomalies.
À mesure que les organisations adoptent les API REST, elles réalisent rapidement le besoin d'analyses de données automatisées et d'analyse comportementale pour comprendre la consommation normale des API REST et identifier les attaquants qui en abusent. Les algorithmes doivent être alimentés par les métadonnées des API REST ainsi que par la collecte du trafic, apprendre en continu et prendre des décisions de manière dynamique en fonction de la logique métier unique de l'organisation. La détection et la protection automatisées doivent également être intégrées dans une plateforme de services et d'intégration plus large, afin qu'une action d'atténuation appropriée, telle que la définition d'une limite de débit dynamique pour un demandeur abusif, puisse être mise en œuvre temporairement au niveau de l'entrée réseau appropriée de l'architecture globale. Même les organisations matures disposant de ressources en développement et en science des données se heurtent rapidement à des obstacles lorsqu'elles tentent de développer une telle détection et intégration. Vous devrez inévitablement explorer les outils de sécurité des API REST pour combler cette lacune.
10. Créez des plans d'intervention en cas d'incident centrés sur les API REST.
Assurez-vous de documenter les processus de criminalistique numérique et de réponse aux incidents (DFIR) pour savoir comment réagir face aux modèles d'attaque inévitables sur les API REST. Si vous avez déjà fait évoluer votre stratégie SecOps pour inclure l'utilisation de l'orchestration, de l'automatisation et de la réponse de sécurité (SOAR), automatisez également certains éléments du flux de travail dans le cadre de la réponse aux incidents. Arrêter une API REST cible d'une activité malveillante est rarement une décision commerciale prudente, sans compter que cela réduit votre capacité à obtenir des renseignements supplémentaires sur un attaquant et ses techniques. Plutôt que de bloquer le trafic en bloc, vous préférerez probablement employer une approche plus précise, comme limiter le débit du seul appelant suspect, le mettre au défi avec des facteurs d'authentification supplémentaires ou surveiller son comportement plus étroitement. Créez des plans d'intervention pour les modèles d'attaque courants sur les API REST, notamment le déni de service au niveau de l'application, les attaques par force brute, le credential stuffing, l'énumération et le scraping.
Résumé des meilleures pratiques de sécurité des API REST
Cet ensemble de meilleures pratiques de sécurité des API est spécifiquement adapté aux types d'API REST et aux problèmes de sécurité les plus courants auxquels les organisations sont confrontées. Commencez par choisir quelques domaines de meilleures pratiques qui vous sont les plus familiers. Développez votre stratégie de sécurité des API au fil du temps pour couvrir toutes les meilleures pratiques et éviter les lacunes dans la posture de sécurité des API de votre organisation. Envisagez d'adopter l'ensemble complet des meilleures pratiques de sécurité des API décrites dans le guide des meilleures pratiques de sécurité des API de Salt dans le cadre d'une approche globale couvrant tous les types d'API. Vous pouvez également utiliser la liste de contrôle correspondante pour suivre les tâches associées.
Si vous souhaitez voir la plateforme de protection des API de Salt Security en action, contactez-nous pour une démo personnalisée dès aujourd'hui !