Clés API oubliées : comment les révoquer sans interrompre le service

Un audit interne d’OpenRouter a relevé plus de 1 000 clés API actives pour 85 employés ; 168 clés, selon l’entreprise, n’avaient pas été utilisées depuis des mois. Il s’agit de chiffres issus de l’auto-audit d’OpenRouter, et non d’une étude indépendante du secteur. Mais, même à titre d’exemple particulier, ils illustrent un piège bien connu des équipes d’ingénierie : on peut oublier une clé, mais pas l’application qui en dépend. L’entreprise a daté son annonce du Security Center du 28 septembre 2026.

Le problème ne consiste pas simplement à repérer l’identifiant le plus ancien et à le supprimer. L’équipe doit en déterminer le propriétaire, savoir où la clé est utilisée et comprendre comment la remplacer sans interrompre une tâche rarement exécutée ou un service oublié. Sans ces informations, la révocation des accès devient une expérience risquée plutôt qu’une opération de nettoyage.

Ce que montre le Security Center — et ce que cela ne prouve pas

D’après la description d’OpenRouter, le Security Center regroupe les clés du compte et affiche leur propriétaire, la dernière utilisation, le plafond de dépenses et la date d’expiration ; les administrateurs de l’organisation voient toutes les clés, tandis que les membres voient celles qu’ils ont créées. Pour les opérations groupées, il est possible de sélectionner jusqu’à 500 clés afin de les désactiver, de les archiver ou de leur fixer un plafond de dépenses. La désactivation est réversible, contrairement à l’archivage. Il s’agit des caractéristiques de l’outil telles que les décrit son fournisseur, et non d’une évaluation indépendante de son efficacité.

Il est particulièrement important de considérer le statut « supprimable » comme une invitation à vérifier, et non comme la preuve qu’il n’existe aucune dépendance. La mesure d’utilisation indique les requêtes passées, mais n’explique pas nécessairement à quelle tâche cron, à quel scénario de reprise ou à quel processus saisonnier la clé est associée. OpenRouter recommande lui-même de confirmer la suppression auprès du propriétaire ; la documentation sur les paramètres de sécurité recommande également de vérifier les dépendances avant toute désactivation ou archivage.

Les restrictions réseau font l’objet d’une réserve distincte : la liste d’autorisations IP est réservée aux administrateurs des offres Enterprise et s’applique à toutes les clés de l’organisation. Les requêtes provenant d’adresses qui ne figurent pas sur la liste sont rejetées avec une erreur 403, et les modifications prennent effet immédiatement. Il faut donc tenir compte des adresses des serveurs de production, du réseau du bureau et des runners CI avant d’activer cette restriction ; sinon, la mesure de sécurité elle-même risque d’interrompre des appels légitimes.

Procédure de nettoyage : d’abord le propriétaire, ensuite la révocation

1. Établissez un inventaire. Pour chaque clé, consignez le propriétaire, l’usage, l’environnement, les consommateurs, le plafond de dépenses et la date d’expiration. Si le système n’indique qu’une personne comme propriétaire, désignez également l’équipe ou le service qui en assumera la responsabilité si cette personne quitte l’entreprise.
2. Vérifiez l’utilisation et les dépendances. Comparez la date de la dernière requête aux calendriers des tâches en arrière-plan, aux scénarios de secours, aux pipelines de mise en production et aux intégrations externes. L’absence d’activité récente est une raison de consulter le propriétaire, pas une justification suffisante pour supprimer immédiatement la clé.
3. Réduisez les risques avant la migration. Lorsque c’est possible, définissez un plafond de dépenses raisonnable et une date d’expiration. Vérifiez le respect du principe du moindre privilège et des règles de stockage des secrets : le guide OWASP sur la gestion des secrets traite l’inventaire, les accès et le cycle de vie des identifiants comme des volets distincts du processus.
4. Créez une clé de remplacement et migrez les consommateurs. Mettez à jour le secret dans le coffre-fort ou la configuration de déploiement, puis migrez les applications progressivement. N’insérez pas la valeur de la clé dans des tickets, des journaux ou le code source.
5. Vérifiez la production avant la révocation. Assurez-vous que la nouvelle clé fonctionne pour tous les consommateurs connus, y compris CI et les tâches rarement exécutées. Désactivez ensuite l’ancienne clé en premier, si une opération réversible est disponible ; archivez-la ou supprimez-la après confirmation de la migration et une période d’observation définie.

La séquence « créer une nouvelle clé → migrer les applications → vérifier leur fonctionnement → supprimer l’ancienne » correspond aux instructions de rotation d’OpenRouter. Il s’agit d’une procédure recommandée, et non d’une garantie d’absence d’interruption : le résultat dépend du fait que vous ayez repéré ou non tous les systèmes qui utilisent l’identifiant.

Les clés d’un service ne sont pas tous les secrets de l’organisation

Le tableau de bord d’un fournisseur donné facilite la gestion des clés de ce service, mais ne centralise pas à lui seul les secrets du cloud, des bases de données, de CI/CD et d’autres API. Les recommandations générales de l’OWASP sur le cycle de vie des secrets couvrent le stockage centralisé, le contrôle d’accès, l’audit, la rotation et la révocation. Les recommandations de Google Cloud conseillent également de limiter la portée des clés, de supprimer les identifiants inutiles et d’en suivre l’utilisation.

OpenRouter affirme aussi que le Security Center utilise les métadonnées des clés, les dépenses et les dates d’expiration, sans lire les prompts ni les réponses. Il s’agit d’une déclaration du fournisseur lui-même ; aucune vérification technique indépendante ne figure dans les sources examinées. Plus généralement, l’existence d’un tableau de bord ne prouve pas que l’équipe a déjà réduit le nombre d’incidents ou les dépenses : les documents consultés ne font état d’aucun résultat public après le lancement.