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.

Lecture ~12 minAPI · Sécurité · Check-list

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