Clé API exposée : 1 jour pour tout compromettre, 0 donnée perdue

Un audit d'une journée. Quelques minutes d'analyse du trafic réseau. Une clé API d'infrastructure visible dans les headers, offrant un contrôle total sur l'ensemble du contenu de la plateforme. Ce cas est fréquent chez les développeurs indépendants qui construisent vite. Il est aussi l'un des plus faciles à corriger.

Contexte

Un développeur indépendant a lancé une plateforme de streaming de vidéos générées par IA. Il m'a sollicité pour un audit d'une journée, suffisant pour couvrir les risques les plus critiques avant une mise en production plus large. La plateforme héberge des vidéos chez un fournisseur externe. L'interface permet de les lire, les rechercher, les organiser.

La découverte

En ouvrant les outils de développement du navigateur et en inspectant les requêtes réseau, une clé API apparaît dans les headers d'une requête vers l'API de l'hébergeur. Cette clé est envoyée directement depuis le frontend, ce qui signifie que n'importe quel visiteur du site peut la voir en quelques secondes.

Il n'y a pas eu besoin d'exploitation complexe, pas d'injection, pas de fuzzing. L'outil de développement de n'importe quel navigateur moderne suffit.

L'impact réel

Avec cette clé, j'accède à l'API de l'hébergeur. Les droits associés permettaient de :

• Lister toutes les vidéos hébergées et leurs métadonnées
• Supprimer n'importe quelle vidéo de la plateforme
• Ajouter du nouveau contenu au nom du compte
• Potentiellement modifier les permissions et révoquer l'accès légitime du développeur

Aucune donnée utilisateur n'était exposée ici. Mais la plateforme elle-même (son contenu, sa continuité, sa disponibilité) était entièrement sous le contrôle de quiconque aurait inspecté les requêtes réseau.

Une clé d'infrastructure exposée côté client, c'est comme laisser les clés de son serveur dans la vitrine.

La remédiation

J'ai documenté la vulnérabilité avec capture d'écran, preuve d'exploitation et évaluation d'impact. Le développeur a compris immédiatement. La correction est architecturale : toutes les interactions avec l'API de l'hébergeur doivent passer par son propre backend, jamais exposées directement au navigateur.

Une vérification courte après correction a confirmé que la clé n'apparaissait plus dans aucune requête réseau côté client. Mission terminée en une journée, problème résolu proprement.

Ce qu'on retient

Les clés API d'infrastructure ne sont jamais destinées au frontend. Même sur une application en développement. Même si « personne ne la connaît encore ». Les scanners automatiques et les robots indexent en permanence le trafic web, et les clés exposées dans les requêtes réseau sont collectées bien plus souvent qu'on ne le croit.

Ce cas illustre aussi la valeur d'un audit court et ciblé pour un indépendant : une journée bien utilisée a permis d'identifier et de corriger la vulnérabilité la plus critique avant tout incident. Le développeur est reparti avec un rapport clair, une correction vérifiée, et une architecture plus solide.