Sécuriser une API gateway comme point de contrôle

Sécuriser une API gateway comme point de contrôle

Une API gateway (passerelle d’interface de programmation applicative) concentre l’authentification, les politiques d’accès et l’exposition réseau des interfaces applicatives. Ce point de contrôle réduit la dispersion des défenses, mais crée aussi une dépendance critique : une politique erronée ou une indisponibilité mal gérée devient visible partout, immédiatement.

Explication de la marmotte

Une passerelle d’API ressemble au contrôle à l’entrée d’un immeuble : elle vérifie qui peut entrer, vers quelle pièce et selon quelles règles. Elle évite que chaque occupant improvise son propre contrôle d’accès, avec des badges dessinés au feutre et des registres tenus sous une pile de pizzas.

→ Lire l’explication complète de la marmotte

API gateway : périmètre et compromis d’architecture

Une API gateway est le point d’entrée applicatif qui reçoit des requêtes externes ou inter-domaines avant de les transmettre à des services en amont. Elle peut terminer Transport Layer Security (TLS), authentifier un appelant, appliquer une autorisation, limiter le débit, transformer certains en-têtes et journaliser la décision. Elle ne remplace ni la sécurité applicative ni le contrôle réseau entre services.

Le compromis central est net : centraliser les politiques réduit les écarts de configuration, mais augmente le rayon d’impact d’une erreur et la valeur de la cible. La recommandation est donc de centraliser les contrôles transverses à forte répétition, pas la totalité de la sécurité. Authentification, limitation de débit, validation structurelle et observabilité appartiennent à la passerelle. Les règles métier, les droits fins sur une ressource et la validation sémantique restent dans le service propriétaire des données.

Une gateway qui décide seule qu’un sujet peut modifier une facture, un contrat ou un référentiel d’identité finit par reconstruire le modèle métier à distance. Les modèles métier dupliqués divergent. Puis ils divergent à 02:17, ce qui est leur manière préférée de participer à l’exploitation.

Le positionnement dépend du flux :

• Une passerelle Internet protège les interfaces publiques, termine TLS et absorbe les abus avant le réseau applicatif.
• Une passerelle partenaire impose un contrat d’accès distinct, avec des identités, des quotas et une journalisation séparés.
• Une passerelle interne peut contrôler les appels entre domaines de sécurité, mais ne doit pas devenir le maillage complet des appels est-ouest dans un cluster.
• Un service mesh (maillage de services) traite mieux l’authentification de service à service et le chiffrement mutuel à grande échelle. La frontière entre les deux doit être explicite, notamment avec une architecture décrite dans conteneurs, Kubernetes, CNI et service mesh.

Une gateway n’est pas un pare-feu applicatif universel. Elle ne détecte pas de manière fiable une fraude métier, une injection dans une requête correctement formée, ni une exfiltration autorisée par une identité compromise. Le reste doit venir du code, des contrôles de données, de la segmentation et de la supervision.

Chaîne de confiance : TLS, identité et autorisation

La terminaison TLS doit utiliser TLS 1.2 ou TLS 1.3, avec des suites cryptographiques maintenues par la plateforme retenue. Le certificat serveur doit couvrir le nom effectivement exposé, et la chaîne de certification doit être renouvelée avant expiration. Une gateway qui accepte un en-tête X-Forwarded-Host non filtré depuis Internet permet souvent de contourner le routage prévu ou de polluer les journaux d’audit.

Entre un proxy d’entrée et la gateway, la confiance dans les en-têtes de provenance doit être bornée par adresse réseau ou, mieux, par authentification mutuelle TLS. Mutual TLS (mTLS) authentifie les deux extrémités du canal avec des certificats. Sans cette borne, un client peut forger X-Forwarded-For, X-Forwarded-Proto ou une identité aval, puis offrir au journal de sécurité une fiction très bien mise en page. Les dépendances d’une telle architecture sont détaillées dans PKI et TLS.

Pour les utilisateurs, préférer OpenID Connect (OIDC), couche d’identité au-dessus d’OAuth 2.0, avec des jetons d’accès courts. La gateway vérifie au minimum la signature, l’émetteur, l’audience, la date d’expiration et, lorsque le protocole le permet, le type de jeton. Un JSON Web Token (JWT) signé mais destiné à une autre audience ne devient pas acceptable parce qu’il porte une belle signature.

La validation locale des JWT réduit la dépendance au fournisseur d’identité, mais retarde la révocation. Une clé de signature retirée ou un compte désactivé ne révoque pas les jetons déjà validables jusqu’à leur expiration. Pour des accès sensibles, combiner une durée de vie courte, une vérification d’état ciblée ou une introspection auprès du serveur d’autorisation. Le choix dépend du délai de révocation exigé, pas de la préférence esthétique pour les jetons autoportés.

L’autorisation doit distinguer trois niveaux :

1. La gateway vérifie que l’appelant dispose du droit d’atteindre une route ou une famille d’opérations.
2. Le service vérifie que l’appelant peut agir sur la ressource demandée.
3. Le magasin de données applique ses propres contrôles lorsque la technologie le permet.

Faire confiance à une identité transmise par en-tête n’est acceptable que si la gateway supprime toute valeur fournie par le client et ajoute elle-même une valeur signée ou protégée par mTLS. Sinon, X-User-Id: administrateur devient une stratégie IAM (Identity and Access Management) étonnamment économique.

Politiques de routage et exemple de contrôle reproductible

Le routage doit être à liste blanche. Chaque hôte, méthode HTTP et chemin exposé doit correspondre à une route attendue. Refuser les méthodes inutilisées, les chemins ambigus, les doubles encodages et les corps dépassant une taille définie. Les transformations de chemin sont particulièrement dangereuses : normaliser une fois, avant la décision d’autorisation, puis transmettre la forme normalisée. Autoriser deux interprétations du même chemin entre gateway et service ouvre la porte aux contournements de route.

La limitation de débit doit être définie par identité authentifiée, puis par adresse source en secours avant authentification. Un quota uniquement par adresse IP (Internet Protocol) pénalise les réseaux partagés et se contourne avec un botnet. Un quota uniquement par jeton autorise l’épuisement de ressources par création massive de comptes ou de jetons. Les deux dimensions sont nécessaires, avec des plafonds globaux par route coûteuse.

Exemple NGINX, reproductible sur une instance utilisant le module limit_req, pour borner une route d’authentification avant son transfert vers un service interne :

# Une zone par adresse source, mémoire partagée de 10 Mio.
limit_req_zone $binary_remote_addr zone=login_by_ip:10m rate=5r/m;

server {
    listen 443 ssl http2;
    server_name api.exemple.test;

    location = /v1/session {
        # Tolère deux requêtes brèves, puis répond 429 sans mise en attente.
        limit_req zone=login_by_ip burst=2 nodelay;
        limit_req_status 429;

        # Supprime une identité prétendument fournie par le client.
        proxy_set_header X-Authenticated-Subject "";
        proxy_pass http://identity-service;
    }
}

Ce contrôle ne protège pas contre une attaque distribuée ayant suffisamment d’adresses distinctes. Il protège le service aval contre les rafales locales et rend l’abus observable. Une protection volumétrique doit être fournie en amont, par le réseau, le fournisseur de transit ou un mécanisme de mitigation dédié.

Les politiques doivent vivre dans Git, être relues et testées. Une gateway configurée exclusivement par interface graphique finit par devenir une collection de clics sacrés. Les clics sacrés ne se comparent pas, ne se rejouent pas et ne se restaurent pas proprement. La gestion de version et les contrôles de livraison sont à relier aux pratiques de Git et CI.

Surface d’attaque de la passerelle et contre-mesures

La confusion de requêtes HTTP, souvent appelée request smuggling, apparaît lorsque deux équipements interprètent différemment Content-Length et Transfer-Encoding. Maintenir gateway, proxy et serveurs HTTP à jour, rejeter les requêtes ambiguës, désactiver les modes de compatibilité inutiles et tester les chaînes complètes. Corriger uniquement la gateway ne suffit pas si le serveur aval conserve une interprétation divergente.

La désynchronisation de cache survient lorsqu’un cache partage une réponse entre des appelants dont les identités ou les en-têtes de sélection diffèrent. Ne jamais mettre en cache une réponse authentifiée sans clé de cache incluant les dimensions d’autorisation nécessaires. Par défaut, désactiver le cache partagé sur les routes portant des données personnelles ou métier. Le cache adore servir la mauvaise réponse avec une latence impeccable.

Les attaques de contournement exploitent les chemins alternatifs : accès direct aux services amont, hôtes internes publiés par erreur, ports d’administration, IPv6 non filtré ou route de débogage. Les services aval ne doivent accepter du trafic que depuis les composants autorisés. Cette règle exige des groupes de sécurité, des règles réseau et une résolution de noms cohérentes. Ouvrir l’amont « temporairement » est une forme de dette dont les intérêts sont prélevés par Internet.

Une gateway peut aussi devenir un relais Server-Side Request Forgery (SSRF), requête forgée côté serveur, si elle expose un proxy générique ou des URL de destination pilotées par le client. Interdire les destinations arbitraires, résoudre les noms via un résolveur contrôlé, bloquer les plages internes et les adresses de métadonnées d’infrastructure, puis vérifier l’adresse obtenue après résolution. Une liste noire de noms ne résiste pas longtemps aux redirections et au DNS.

Exploitation : clés, supervision, sauvegarde et reprise

Les clés privées de terminaison TLS doivent être stockées dans un gestionnaire de secrets ou un HSM (Hardware Security Module), module matériel protégeant les opérations cryptographiques. Le choix d’un HSM se justifie quand la clé ne doit pas être exportable, quand une séparation de responsabilités est exigée ou quand l’audit cryptographique doit être renforcé. Il ne corrige ni une route publique mal protégée ni une autorisation absente. Un HSM ne lit pas les tickets d’incident, malgré une confiance assez touchante dans le silicium.

Prévoir la rotation des certificats, des clés de signature de jetons et des secrets d’accès aux services. Toute rotation doit accepter simultanément l’ancien et le nouveau matériau pendant une fenêtre bornée, sauf compromission. Publier les nouvelles clés publiques avant d’émettre des jetons signés avec elles. Révoquer ensuite l’ancienne clé après expiration des derniers jetons compatibles.

La supervision doit mesurer les codes HTTP, les latences par route, les refus d’authentification, les dépassements de quota, les erreurs de validation de jeton, les échecs TLS et les refus de politique. Les journaux doivent corréler une requête avec un identifiant généré à l’entrée, sans enregistrer de jeton, de mot de passe, de cookie de session ni de donnée personnelle non nécessaire. L’observabilité ne sert pas à collectionner des tableaux de bord : elle doit permettre d’expliquer un refus et de détecter une dérive.

Sauvegarder les configurations versionnées, les certificats publics, les références vers les secrets et les listes de routes. Ne pas sauvegarder des clés privées en clair sous prétexte de reprise rapide. Le plan de reprise doit reconstruire une gateway à partir de code, restaurer les secrets depuis leur coffre, rétablir les certificats et vérifier les dépendances d’identité avant réouverture. Une restauration qui réactive toutes les routes avant le fournisseur d’identité fabrique une fenêtre de sécurité très créative.

🐝 Ce qui arrive si on s’en passe

Sans passerelle d’API tenant son rôle de point de contrôle, l’authentification et les politiques d’accès se dispersent, chaque service improvisant son propre contrôle avec des règles incohérentes. Les interfaces se retrouvent exposées sans vérification centralisée : un appelant non authentifié atteint des fonctions qui présumaient un filtrage en amont, et une politique appliquée à un endroit mais pas à un autre ouvre des chemins d’accès oubliés. La dispersion des défenses rend aussi la traçabilité incomplète, car les accès ne convergent plus vers un point où les journaliser. À l’inverse, ce point de contrôle mal configuré devient une dépendance critique dont l’erreur se voit partout d’un coup. Dans les deux cas, l’absence de contrôle cohérent transforme un ensemble d’interfaces en surface où l’accès dépend de l’endroit par lequel on entre plutôt que de l’autorisation réelle.

🦫 Explication de la marmotte 🍫

Une passerelle d’API reçoit les demandes envoyées à une application avant les services qui réalisent le travail. Elle commence par vérifier que la connexion est chiffrée et que le nom demandé correspond au bon service. Ensuite, elle contrôle l’identité présentée par la personne, l’application ou un autre service. Cette identité est souvent portée par un jeton signé, dont la signature, la date de fin et le destinataire prévu doivent être vérifiés.

Après cette vérification, la passerelle décide si cette identité a le droit d’appeler une fonction précise. Elle limite aussi le nombre de demandes reçues afin qu’un appelant ne bloque pas le système. Si une règle échoue, elle refuse la demande avant qu’elle atteigne le service interne. Si la demande est acceptée, le service interne reçoit seulement les informations d’identité produites par la passerelle, jamais celles fournies librement par le demandeur.

Le service interne doit toutefois vérifier les droits sur la donnée demandée. La passerelle sait qu’une identité peut atteindre une fonction, mais elle ne connaît pas forcément le propriétaire d’un document ou les règles métier. Les clés servant au chiffrement et aux signatures doivent être protégées, renouvelées et surveillées. En cas de panne de la passerelle ou du système d’identité, les règles de disponibilité doivent être choisies à l’avance : refuser l’accès protège mieux, mais bloque aussi les utilisateurs légitimes.

À lire aussi

• Partage de données inter-organisations par APIPartager des données entre organisations exige des contrats exécutables, des API limitées et une confiance technique strictement bornée.
• Sécuriser un contrat API-first dès la conceptionConcevoir un contrat d’API comme une frontière de confiance, avec authentification, autorisation, validation et exploitation sécurisées.
• Comment sécuriser une API GraphQL en productionCette page décrit les risques propres aux API GraphQL, notamment la complexité des requêtes et l’introspection de schéma, avec les contrôles nécessaires en production.
• Monolithe ou microservices : choisir sans se mentirComparaison technique des architectures monolithique et microservices, avec le coût réel du découpage, ses effets sur la sécurité, l'observabilité et l'exploitation.

Pages voisines

La citent

• Backend Foundry Local expliqué et comparé à LM Studio
• Contourner un contrôle proxy par confusion de chemin
• Shadow AI, détecter les assistants IA publics non déclarés

Sécuriser une API gateway comme point de contrôle

Elle cite

• Observabilité en architecture cyber : logs, métriques, traces
• Auditer la couverture réelle du mTLS service mesh
• Chiffrer les flux est-ouest dans un data center
• Intégration continue avec Git : automatiser vos workflows
• Mettre en place un rate limiting anti-DDoS L7