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.
Pourquoi il faut à la fois des quotas par compte et des quotas par réseau
Un quota par compte répond à une question simple : combien cette clé précise a-t-elle consommé. C'est naturellement la première chose à suivre, et cela ne suffit pas à soi seul, car une clé n'est qu'un identifiant, et les identifiants peuvent être multipliés. Une personne déterminée à dépasser une limite par compte peut souvent se contenter de créer un autre compte, de générer une autre clé et de repartir avec un quota neuf, à moins que quelque chose d'autre ne suive une dimension qui ne se réinitialise pas simplement parce qu'un nouvel identifiant a été émis.
C'est à cela que servent les quotas par réseau. Chaque réseau, un bloc /24 pour les adresses IPv4 ou un bloc /48 pour IPv6, reçoit une franchise gratuite partagée de 2 500 requêtes par jour, comptée sur le trafic sans clé comme sur toutes les clés enregistrées depuis ce réseau. Une limite par compte seule permettrait à quelqu'un de générer indéfiniment de nouvelles clés pour réinitialiser sans cesse sa franchise gratuite. Une limite par réseau comble précisément cette faille, car elle suit l'origine réelle du trafic, et pas seulement l'identifiant qui s'y trouvait attaché.
Aucune des deux mesures ne suffit seule, et il vaut la peine de préciser contre quoi chacune protège, puisqu'elles résolvent des problèmes différents. Le suivi par compte protège contre l'utilisation d'un identifiant unique bien au-delà de ce qu'il devrait être, ce qui compte pour l'exactitude de la facturation et pour repérer une clé divulguée utilisée là où elle ne devrait pas l'être. Le suivi par réseau protège contre la multiplication de la franchise gratuite par des inscriptions répétées, un autre mode de défaillance que le suivi par compte seul ne peut pas voir, puisque chaque nouveau compte paraît parfaitement normal pris isolément.
Faire fonctionner les deux ensemble crée une complication légitime : plusieurs utilisateurs réels partageant un réseau, comme une entreprise derrière un petit nombre d'adresses IP publiques, pourraient en théorie se heurter à un plafond par réseau sans rapport avec l'utilisation réelle de chacun. Nous gérons cela avec des emplacements IP glissants, un nombre fixe d'adresses distinctes depuis lesquelles une clé peut être utilisée, et des en-têtes de quota qui indiquent exactement combien de ces emplacements sont occupés par rapport à la limite, afin qu'un réseau partagé légitime puisse voir sa situation réelle au lieu de se heurter à un mur opaque sans explication.
Nous pensons que c'est un cas où la conception la plus simple, ne suivre qu'une seule dimension, serait en réalité pire pour les utilisateurs honnêtes, et pas seulement moins protectrice contre les abus. Une limite uniquement par réseau pénaliserait un compte pour une autre activité sans rapport sur le même réseau. Une limite uniquement par compte laisserait la franchise gratuite multipliable à l'infini par quiconque est prêt à créer assez de comptes. Faire fonctionner les deux, avec une visibilité sur chacune grâce aux en-têtes de réponse, implique plus de pièces mobiles, mais c'est la version qui protège réellement ce qu'une franchise gratuite est censée protéger, sans punir discrètement ceux qui l'utilisent comme prévu.