Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Ce que la limitation de débit par réseau résout et que les limites par clé ne résolvent pas
Une limite de débit liée uniquement à une clé d'API repose sur une hypothèse implicite : une clé correspond à un utilisateur légitime, qui l'utilise d'une manière raisonnablement prévisible. Cette hypothèse est mise en défaut plus souvent que la conception ne le suppose. Une clé peut être partagée au sein d'une équipe, intégrée dans une application côté client où de nombreux visiteurs différents déclenchent des requêtes avec le même identifiant, ou générée de nombreuses fois par quelqu'un qui cherche précisément à cumuler plusieurs clés pour contourner la limite d'une seule clé.
Nous appliquons une limite de débit au niveau du réseau en plus de celle au niveau de la clé, précisément pour cette raison. Chaque réseau, un bloc /24 pour IPv4 ou un bloc /48 pour IPv6, dispose d'un quota gratuit de 2 500 requêtes par jour, partagé entre l'usage sans clé et toutes les clés enregistrées depuis des adresses de ce réseau. Une personne ne peut pas générer dix clés depuis le même réseau et multiplier son quota gratuit par dix, car le plafond au niveau du réseau détecte ce schéma quel que soit le nombre de clés distinctes qui se trouvent en dessous.
Il ne s'agit pas avant tout d'empêcher les abus malveillants, même si cela y contribue aussi. Il s'agit de garder le quota gratuit utile pour tous ceux qui l'utilisent honnêtement. Une ressource partagée comme une offre gratuite ne reste généreuse que si cette générosité n'est pas discrètement détournée en masse par un petit nombre de comptes qui contournent la limite par clé. Les quotas au niveau du réseau maintiennent le calcul de l'offre gratuite au plus près de ce qu'elle était réellement censée distribuer : un vrai quota quotidien par source, et non par identifiant que cette source se trouve détenir.
Il existe un cas d'usage légitime que ce mécanisme doit veiller à ne pas pénaliser : plusieurs utilisateurs ou services réels opérant légitimement depuis le même réseau, comme un bureau, un environnement d'hébergement mutualisé ou une grande organisation derrière un petit nombre d'adresses IP publiques. C'est exactement pour cela que nous publions des emplacements IP glissants et offrons une visibilité sur l'usage du réseau grâce aux en-têtes de quota, dont un en-tête spécifique indiquant combien des emplacements IP de votre clé sont utilisés par rapport à la limite. Une équipe légitime qui partage un réseau peut voir sa situation réelle au lieu de ne découvrir un plafond partagé qu'au moment où elle l'atteint à l'improviste.
Une limite de débit appliquée uniquement au niveau de la clé est plus simple à construire et à expliquer, et pour beaucoup d'API, elle suffit probablement. Pour un service doté d'une offre gratuite significative en particulier, une limite uniquement par clé laisse une lacune évidente : le quota gratuit n'a jamais été conçu comme une ressource que l'on pourrait multiplier en générant davantage d'identifiants, et une limite qui n'en tient pas compte ne protège pas vraiment ce qu'elle prétend protéger. Superposer un plafond au niveau du réseau à celui au niveau de la clé comble cette lacune sans obliger chaque utilisateur légitime à prouver qu'il n'est pas l'exception.