Guide · Sécurité
Protéger une API
Une API est une porte ouverte sur vos données. Voici les réflexes qui la gardent solide.
Une API expose des fonctions et des données à des programmes. Mal protégée, elle laisse fuiter des informations, accepter des actions non autorisées, ou tomber sous une avalanche de requêtes.
Ces réflexes valent quel que soit le langage. Pour une approche contextuelle et continue, voir ZAIA.
01 — Vérifier qui appelle, et ce qu'il a le droit de faire
Authentification ET autorisation
À chaque requête : identifier l'appelant (jeton), puis vérifier ses droits sur la ressource visée. Ne jamais supposer qu'un utilisateur authentifié a le droit de tout faire ni de voir les données d'un autre.
02 — Ne rien croire de ce qui entre
Validation stricte
Contrôler type, format, taille et bornes de chaque paramètre. Rejeter par défaut. Se méfier des identifiants passés par le client (accès direct à un objet d'autrui).
03 — Encaisser la charge
Limitation de débit et quotas
Limiter le nombre de requêtes par client, par clé et par route. Prévoir des quotas et un comportement propre en cas de dépassement, pour résister aux abus et aux pics.
04 — Protéger le transport et les secrets
TLS partout, secrets côté serveur
- HTTPS obligatoire, versions de TLS à jour.
- Clés et secrets hors du code et du dépôt, dans un coffre ou des variables d'environnement.
- Rotation des secrets et révocation possible.
05 — Voir, versionner, réduire
Journaux, versions, surface
- Journaliser les accès et les erreurs, surveiller les anomalies, exporter vers un SIEM.
- Versionner l'API pour faire évoluer sans casser, retirer les anciennes versions.
- N'exposer que les endpoints nécessaires ; tenir les dépendances à jour ; tester régulièrement (revue, scan).
06 — Questions fréquentes
Questions fréquentes
Une clé d'API suffit-elle à sécuriser ?
Non. Une clé identifie, elle n'autorise pas finement et se fait voler. Il faut authentification, autorisation par ressource et limitation de débit.
Faut-il exposer les messages d'erreur détaillés ?
Non en production : ils renseignent un attaquant. Message générique côté client, détail dans les journaux côté serveur.
Comment gérer l'accès direct à un objet d'autrui ?
Vérifier systématiquement que l'appelant a le droit sur l'identifiant demandé, ne jamais se fier à un identifiant fourni sans contrôle.
07 — Ressources & liens
Où aller, concrètement
Références
- OWASP API Security Top 10
- Les risques majeurs des API et comment les traiter.
- owasp.org/API-Security/
- NEWTIV — ZAIA : authentification sans clé
- Une couche de confiance contextuelle devant l'API.
- newtiv.com/article/zaia-authentification-zero-key.html