Protection des API à la périphérie : guide pratique de configuration

Les API relient les navigateurs, les applications mobiles, les partenaires, les services internes et l'automatisation. Elles exposent aussi des opérations précises que les attaquants peuvent répéter à grande vitesse. Si une API est accessible depuis l'internet public, une conception sûre doit supposer que les requêtes seront malformées, rejouées, non autorisées, automatisées et volontairement coûteuses.

La protection en périphérie aide à rejeter le trafic manifestement invalide ou abusif avant qu'il ne consomme les ressources de l'origine. Elle ne remplace pas un code applicatif sûr. La configuration la plus fiable répartit les responsabilités : la périphérie gère le transport, le filtrage grossier, les signaux d'authentification, les contrôles de schéma et de taille, les quotas et la visibilité ; l'application reste l'autorité pour l'accès aux objets, la logique métier et les décisions concernant les données.

Ce guide constitue un point de départ indépendant du fournisseur pour les API HTTP REST, JSON, GraphQL et similaires.

Définir le modèle de menace de l'API

Commencez par un inventaire, pas par un modèle de règle. Enregistrez chaque nom d'hôte public, version, méthode, route, méthode d'authentification, propriétaire, classification des données, dépendance et client attendu. Incluez les routes non documentées, les endpoints de débogage, les anciennes versions, les webhooks, l'introspection GraphQL et les API de gestion. OWASP identifie la mauvaise gestion des inventaires comme un risque majeur pour les API, car des hôtes et versions oubliés restent accessibles après que les équipes ont cessé de les surveiller.

Cartographiez les principales menaces :

• Une autorisation défaillante au niveau des objets ou des fonctions, qui expose les données d'un autre utilisateur ou une action administrative.
• Une authentification défaillante, le rejeu de jetons, une mauvaise gestion des clés et le credential stuffing.
• Une consommation illimitée de ressources via de gros payloads, des requêtes coûteuses ou un volume élevé de requêtes.
• L'injection, la désérialisation non sûre et le contenu malformé qui atteint les analyseurs ou les services en aval.
• La falsification de requêtes côté serveur et la consommation non sûre de réponses d'API tierces.
• Les fuites de données par des erreurs détaillées, des champs excessifs ou des réponses de débogage.

Configurer la périphérie par couches

1. Établir un transport de confiance

Servez l'API sur HTTPS et définissez les versions TLS, noms d'hôte, méthodes et types de contenu acceptés. Rediriger une requête d'API vers une page HTML peut casser les clients et masquer les échecs ; utilisez donc un contrat d'erreur d'API explicite. Rejetez tôt les hôtes et méthodes inattendus. Appliquez des limites aux en-têtes de requête, à l'URI, au corps et à la chaîne de requête avant toute analyse coûteuse.

Pour les API de service à service ou de partenaires, envisagez le TLS mutuel, les requêtes signées ou une autre preuve de possession par le client. Pour les API destinées aux utilisateurs, utilisez un protocole de jeton fondé sur des standards et vérifiez la signature, l'émetteur, l'audience, l'expiration, la date de début de validité et l'état de rotation des clés à la couche appropriée. Ne considérez jamais une clé d'API, une IP source ou un en-tête d'identité fourni par le client comme preuve d'autorisation de l'utilisateur final.

2. Valider la structure de la requête

Utilisez le schéma versionné de l'API comme liste d'autorisation. Validez la méthode, le chemin, les paramètres de requête, les en-têtes, le type de contenu, l'encodage, les types de champs, les longueurs de chaîne, les plages numériques, la profondeur d'imbrication et la taille maximale du corps. Rejetez les champs inattendus lorsque l'affectation de masse serait dangereuse. Pour GraphQL, limitez la profondeur des requêtes, les alias, la complexité et la taille des lots selon les besoins réels du service.

Validez aussi les réponses lorsque c'est possible, particulièrement pour les données sensibles et les contrats partenaires. Un contrôle de schéma ne rend pas une entrée sûre à lui seul : l'application a toujours besoin d'encodage de sortie adapté au contexte, de requêtes paramétrées, d'une gestion sûre des fichiers et d'une validation en aval.

3. Ajouter des quotas et contrôles contre les abus

Appliquez la limitation de débit sur davantage de critères que l'IP. Combinez la source, le principal authentifié, la clé d'API, la route, la ressource et le coût de l'opération lorsque ces identifiants sont fiables. Accordez aux endpoints coûteux des budgets plus faibles qu'aux lectures peu coûteuses. Protégez la connexion et la réinitialisation de mot de passe avec des limites d'échec distinctes. Pour les appels payants en aval, définissez aussi un budget à l'échelle du service en plus des quotas par client.

Renvoyez 429 Too Many Requests lorsqu'un budget de requêtes est épuisé et que le client peut réessayer. Utilisez Retry-After lorsque le délai de nouvelle tentative est pertinent et documentez les comportements de temporisation exponentielle et d'idempotence. Ne révélez pas quel compteur interne a déclenché la décision. Un quota ne remplace ni l'autorisation, ni la protection CSRF lorsqu'elle s'applique, ni les limites transactionnelles.

4. Ajouter une détection ciblée des menaces

Utilisez un WAF pour une couverture large des protocoles et des schémas d'attaque, et la gestion des bots pour les schémas d'automatisation. Ajustez les règles à l'API plutôt que de copier des règles de navigateur sur des clients machine. Autorisez les partenaires documentés par une identité et une portée explicites, et non par un contournement IP permanent. Envisagez des signaux d'anomalie tels que des changements de compte rapides, de nombreuses identités depuis un même client, des jetons invalides répétés, des géographies inhabituelles et une hausse soudaine des opérations coûteuses.

5. Préserver la confiance de l'origine

L'origine ne doit accepter le trafic que depuis la passerelle prévue ou un chemin privé, avec un contrôle cryptographique ou réseau qu'un attaquant ne peut pas simplement copier dans une requête directe. Validez les en-têtes transférés à la frontière de confiance et empêchez les appelants d'usurper l'IP, le schéma ou l'hôte du client d'origine. Le guide compagnon comment masquer et protéger votre serveur d'origine couvre en détail cette frontière.

Journaliser les décisions, pas les secrets

Pour chaque requête, capturez un identifiant de requête, l'horodatage, la route, la méthode, le statut, la latence, le principal authentifié ou l'identifiant client pseudonymisé, la décision de politique, la version de la règle et le résultat en amont. Enregistrez la catégorie de raison, telle que jeton invalide, échec de schéma, quota ou correspondance WAF. Ne journalisez pas les jetons d'accès, clés d'API, mots de passe, données de paiement complètes ni payloads sensibles. Hachez ou masquez les identifiants selon le besoin d'enquête et la politique de conservation.

Créez des alertes pour les échecs d'authentification, les refus d'autorisation, les rejets de schéma, les taux de 429, les variations d'erreurs par version d'API, les volumes de données inhabituels et la latence de l'origine. Corrélez les journaux de périphérie avec ceux de l'application et des dépendances afin de distinguer une requête bloquée d'une défaillance de l'origine. Testez que les journaux restent disponibles pendant une attaque et que la synchronisation horaire est fiable.

Séquence de déploiement sûre

1. Inventoriez les hôtes, routes, clients, versions et responsabilités.
2. Exécutez les règles de schéma, d'authentification et de WAF en mode rapport uniquement lorsque cette option est disponible.
3. Rejouez des tests représentatifs provenant de navigateurs, d'applications mobiles, de partenaires, de jobs et de cas d'échec.
4. Appliquez d'abord les contrôles de transport et de taille, puis les contrôles d'authentification et de schéma, puis les quotas et règles comportementales.
5. Déployez en canari une version ou une route et comparez les métriques de succès, latence, 4xx, 5xx, 429, support et dépendances.
6. Supprimez les routes obsolètes et les exceptions temporaires uniquement après avoir confirmé la migration du trafic.

Éviter ces pièges de configuration

• Supposer qu'un JWT valide prouve l'accès à chaque objet nommé dans l'URL.
• Accepter n'importe quelle Origin, un CORS générique avec identifiants ou une valeur CORS réfléchie.
• Autoriser des versions d'API non documentées parce qu'elles apparaissent encore dans un ancien code client.
• Analyser de très gros corps ou des requêtes profondément imbriquées avant d'appliquer des limites de taille et de complexité.
• Placer des secrets dans les URL, les journaux, les messages d'erreur ou les réponses pouvant être mises en cache.
• Laisser la périphérie et l'application diverger sur l'identité du client ou le schéma de la requête.
• Déployer une politique stricte sans retour arrière, canari ni matrice de clients de test.

Lisez la limitation de débit expliquée, le trafic des bots face au trafic humain et la checklist des en-têtes de sécurité pour compléter les contrôles environnants.

Références faisant autorité

• OWASP API Security Top 10
• OWASP REST Security Cheat Sheet
• NIST SP 800-207: Zero Trust Architecture

Il n'existe que deux problèmes difficiles en informatique : l'invalidation du cache et le nommage des choses.