Sécurité d'API et données

Sécurité d'API et données

1. Authentification, autorisation et le défaut qui vient

   L'API a une surface d'attaque que le site n'a pas : elle est interrogeable par quiconque connaît son URL. Les contrôles du navigateur ne la protègent pas.

   Le contrôle d'accès par objet : l'erreur numéro un

   Le défaut le plus répandu des API n'est pas l'absence d'authentification, c'est l'absence de vérification de propriété. Un utilisateur authentifié demande /factures/1042 : le serveur vérifie qu'il est connecté, et lui renvoie la facture. Elle appartient à quelqu'un d'autre.

   Ce défaut figure en tête du Top 10 de la sécurité des API de l'OWASP, et il n'est détectable ni par un test de charge ni par une revue superficielle : il faut le chercher explicitement, en tentant d'accéder aux objets d'un autre utilisateur. La parade est une règle unique : toute requête qui porte un identifiant d'objet vérifie que l'appelant a le droit sur cet objet. Une vérification faite sur l'identifiant de la requête ne suffit pas.

   Les deux autres défauts du Top 10 des API

   • l'authentification des masseurs : identifiants par défaut, clés de test, mots de passe faibles, absence de limitation des tentatives. Sur une API, ce défaut est exploitable à distance par un robot ;
   • l'excès de données : renvoyer systématiquement l'objet complet au lieu du champ demandé expose des informations que le client n'a pas besoin de voir — et que l'appelant legitime n'aurait pas dû obtenir. Le principe du moindre privilège s'applique aussi à la forme de la réponse.

   Le troisième défaut est la validation des entrées : une API reçoit des données d'une source externe, et les valide côté serveur. La validation du côté client n'est pas une validation, c'est un confort d'affichage.

2. Limites, pagination et gestion de la charge

   Une API publique sans limite est une API qui tombera, et son indisponibilité sera attribuée à la conception du service, pas à l'appelant.

   Les quatre limites à mettre en place

   1. le débit : nombre de requêtes par utilisateur et par période, avec une réponse explicite — pas un échec silencieux, mais un 429 et un en-tête indiquant quand réessayer ;
   2. la taille des requêtes : un corps posté doit avoir une taille maximale, appliquée avant tout traitement ;
   3. la profondeur des filtres : une recherche qui accepte un nombre libre de critères permet de générer des requêtes coûteuses par construction ;
   4. la pagination : une liste sans pagination est un appel qui ramène la table entière en mémoire. Deux modes : par numéro de page, simple mais instable quand la liste change ; par curseur, plus stable et le bon choix par défaut sur une liste qui bouge.

   La pagination par curseur, et sa vraie raison

   Sur une liste qui reçoit des écritures pendant que l'utilisateur parcourt les pages, la pagination par numéro produit un défaut silencieux : un élément inséré entre deux lectures décale toutes les pages suivantes, et l'utilisateur voit un enregistrement deux fois, ou n'en voit aucun. Le curseur n'a pas ce problème, parce qu'il décrit une position stable dans le flux et non un décalage.

   Les seuils : un coût, pas qu'un réglage

   Chaque limite doit être choisie, pas laissée par défaut. Le critère n'est pas « quelle valeur semble raisonnable » mais « quelle valeur l'infrastructure supporte-t-elle, et que se passe-t-il quand on la dépasse ? ». Une limite trop basse rend l'API inutilisable ; une limite trop haute la rend indisponible pour tous. Un seuil doit être un compromis assumé et documenté, pas une valeur posée au hasard pour faire taire une alerte.

3. Idempotence, reprises et cohérence

   Réseaux non fiables signifie qu'une requête peut arriver au serveur et que la réponse peut se perdre. L'API doit alors pouvoir être rejouée sans créer d'effet de bord.

   Ce que garantit le protocole

   La méthode GET doit être idempotente : la répéter ne doit pas changer l'état du serveur. C'est aussi ce qui autorise le cache et la pré-chargement. En revanche, PUT et DELETE sont eux aussi idempotents par convention : répéter une suppression, c'est supprimer quelque chose qui n'existe déjà pas, ce qui doit réussir sans effet supplémentaire. POST n'est pas idempotent : c'est la seule méthode où répéter pose problème.

   La clé d'idempotence

   La parade pour POST est un identifiant fourni par l'appelant, que le serveur mémorise. Si la même clé arrive deux fois, la seconde requête renvoie le résultat de la première au lieu d'en créer un second. C'est ce qui rend une reprise après coup de perte de connexion possible sans créer de doublon — le défaut le plus signalé sur les systèmes de paiement et de commande.

   Le timeout est un choix de conception

   Un appel qui expire chez l'appelant a peut-être été exécuté côté serveur. Toute opération non idempotente crée donc une incertitude réelle. La conception doit la traiter explicitement : soit l'opération est idempotente par construction, soit elle est réversible, soit elle fournit un moyen de savoir si elle a abouti. Une conception qui ignore ce cas produit des doublons, pas des erreurs visibles.