Sécurité des APIs : 7 principes à respecter

Les APIs, qui sont au cœur de l’intégration et des échanges techniques entre plateformes, doivent être sécurisées dans un contexte de plus en plus sensible avec la montée des cyber attaques et la multiplication des points d’exposition.

Je vous propose 7 principes à respecter pour sécuriser les APIs en s’appuyant sur 3 principaux drivers : Fiabilité – Traçabilité – Confidentialité :

#1 Exposer en HTTPS

Bien que le HTTPS sécurise le canal et non pas les données, il est important d’authentifier le serveur, de chiffrer la communication et protéger le flux réseau dans une architecture Client-Serveur, ce qui va permettre d’assurer l’intégrité des données au niveau de la session.

A noter que le TLS 1.1 est déprécié depuis 2018 et que la pratique actuellement dans la majorité des entreprises reste le TLS 1.2, la RFC 8446 vient mettre à jour le protocole TLS avec la version 1.3 qui apporte beaucoup d’améliorations en terme de sécurité et de performance : suppression des algorithmes obsolètes (SHA-1, DES, MD5, …), un handshake en un seul aller-retour grâce au 0-RTT et donc une latence optimisée, …

#2 Identifier les clients (Certificat, Authorization Basic, IP) 

Un serveur qui expose une API doit identifier et authentifier son client pour éviter de retourner des réponses à des clients non autorisés ou malveillants. Des mécanismes existent côté réseau et peuvent être exploités pour compléter les vérifications côté applicatif :

• Un serveur qui requête une ressource en back to back est généralement identifiable sur le réseau via son IP (pas systématiquement). Cette adresse pourra être utilisée comme un "id" pour identifier l’appelant ce qui permet d’ajouter une iRule côté Proxy ou LB pour n’autoriser que les IP déclarées. Ce mécanisme est applicable pour un échange entre 2 serveurs (partenaire qui consomme un service du SI, 2 serveurs du même SI, ...)
• Avec le SSL 2-way (RFC 8120), le Serveur authentifie et identifie le Client en vérifiant son certificat auprès d’une PKI après la vérification du certificat Serveur côté Client. Comme son nom l’indique, c’est une double authentification qui permet un échange sécurisé bout en bout et c’est plutôt recommandé dans un environnement non maitrisé : échange entre 2 serveurs qui n’appartiennent pas à la même zone de confiance ou appel à un serveur distant dans le Cloud.
• Le Basic Authentication (RFC 7617) reste le moyen le plus standard pour identifier et authentifier un client applicatif qui souhaite consommer des ressources exposées via des APIs. Cela passe par la déclaration de credentials sous forme d’un client_id/client_secret auprès du serveur de ressources. Le Client requêtera le serveur avec le Header Authorization Basic qui contiendra l’encodage en base 64 URL des credentials de l’appelant. Des règles spécifiques pourraient être rajoutées lors de la déclaration des consommateurs pour rajouter des facteurs d’authentification plus élevés afin de renforcer la sécurité.

#3 Centraliser la gestion des autorisations

Déléguer la gestion des autorisations à un serveur central qui porte la fonction de « Authorization Server (AS) » fait partie des bonnes pratiques de sécurité dans un SI APIsé. Le serveur de ressources n’aura plus la charge d’authentifier tous les clients (s’assurer de la cohérence des credentials), les identifier (récupérer les infos/droits associés aux clients) et ainsi les autoriser à accéder aux ressources.

Le Framework OAuth (RFC 6749) a standardisé les rôles et mécanismes d’échange entre les acteurs concernés via des cinématiques/Grant propres à chaque usage :

• Client Credentials pour les échanges entre serveurs et sans AuthN end-user
• Ressource Owner Client Credentials (ROPC) pour les applications confidentielles qui manipulent les Credentials des end-users
• AuthZ Code pour les authentifications 3-legged où le end-user autorise une application tierce à accéder à ses ressources en son nom (avec ou sans consentement)
• Implicit pour les applications publiques qui ne peuvent pas garder les secrets de l’end-user. Le jeton d’autorisation lui est retourné après l’AuthN et est renvoyé à l’application qui demande l’accès à la ressource avec le jeton.

A noter que ROPC et Implicit Grant sont dépréciés, et le PKCE (prononcé « pixie ») est fortement recommandé pour l’AuthZ Code pour couvrir le risque de vol et rejeu de jeton en intégrant une logique de génération/vérification de Code Challenge et Code Verifier.

2 choix d’implémentation possibles : un Authorization Server (AS) indépendant du type Spring Security, Keycloak, Okta, … ou une fonction d’AS intégrée à une plateforme plus globale comme WSO2, Apigee ou Mulesoft.

#4 Rajouter des contrôles fonctionnels

Une API exposée qui respecte les principes REST peut contrôler l’appel de requête avant de déclencher les traitements métiers et renvoyer la réponse au client ce qui permet de se prémunir contre les injections :

• « Check Header » pour contrôler la présence des Headers Authorization, le bon Content-Type ou le User-Agent
• « Check Method » pour vérifier que l’appel est bien avec le bon verbe HTTP (un POST et non un DELETE par exemple)
• « Check Parameters » avec des contrôles sur le format des paramètres passés en entrée

Ces étapes de vérifications se font au niveau de l'Endpoint d’exposition ce qui permet de ne pas exposer la « logique » API à un risque sécurité.

D’autres contrôles peuvent être rajoutés à travers la vérification des méta données associées au Token lors de la consommation de l’API pour couvrir le risque de vol et rejeu de Token.

La RFC 8705 - OAuth 2.0 MTLS propose un mécanisme de « binding » de l’Access Token au certificat SSL échangé au « handshake » lors d’une authentification mutuelle entre le client et l’AS (AuthZ Server). le claim "CNF" qui correspond au hash du certificat X.509 est rajouté par l'AS (pour un Token auto-porteur) et doit être vérifié par le Ressources Server lors de l'Introspect avant d'autoriser l'accès.

#5 Fixer un Rate limit

Une API ou un domaine fonctionnel qui regroupe un ensemble d’APIs exposées doit définir un seuil au delà duquel les appels clients doivent être rejetés pour protéger le serveur contre un trafic anormalement élevé. Ne pas fixer de limite peut déclencher des défaillances en cascade, interrompre une orchestration d’appels nécessaire pour un flux fonctionnel critique et expose le serveur au risque DDOS.

Le Rate limit ne doit jamais être à la limite capacitaire du ou des serveurs de ressources, doit être fixé au regard des usages clients même dans une infrastructure virtualisée ou conteneurisée avec une élasticité « sans limite »

Des contournements existent pour ne pas renvoyer un méchant HTTP 429 sur certains appels en activant le cache, mettre une file d’attente au niveau du front ou déclencher un "Retry" et éviter de retourner une erreur au client.

#6 Exposer via une API Gateway

L’API Gateway est un composant central et indispensable dans un SI APIsée avec de multiples services et ressources. Point d’entrée de l’ensemble des systèmes techniques du SI, il permet de :

• Exposer aux clients applicatifs en un seul point d’entrée les APIs de tous les backends qui intègrent de la logique métier
• Protéger le réseau privé dans lequel sont déployés les serveurs et ne pas l’exposer sur Internet
• Centraliser les fonctions de sécurité, de filtrage ou de transformation plutôt que les multiplier sur tous les serveurs
• Administrer et superviser l’exposition des services d’API
• Protéger contre les attaques du top 10 OWASP avec des Policies nativement intégrés

Le Portail et le module de monétisation viennent compléter les fonctions cœur d’une API Gateway pour la transformer en une API Management.

#7 Logger tous les événements

Activer la journalisation au niveau de l’API Gateway permet d’avoir une source de données non négligeable pour le SIEM qui dispose des mécanismes adéquat pour analyser les logs et détecter ainsi d’éventuelles menaces.

En bonus :

• Eviter les réponses verbeuses en retournant des messages d’erreur génériques pour ne pas divulguer des informations potentiellement exploitables
• Décommissionner les versions « legacy » pour ne pas garder des points d’exposition qui n’évoluent pas et donc susceptibles d’être vulnérables