Une clé API est une chaîne de caractères alphanumérique qui identifie un projet ou une application auprès d’un service distant. Elle accompagne chaque requête envoyée à une interface de programmation pour que le serveur sache qui appelle, quel quota appliquer et quelles permissions accorder.
Trouver la clé API d’un site web peut désigner deux opérations distinctes : récupérer sa propre clé dans le tableau de bord d’un fournisseur, ou observer les clés qu’un site expose dans ses requêtes réseau côté client.
A lire en complément : Comment puis-je créer un site Web avec mon téléphone ?
Clé API publique et clé secrète : une distinction technique à connaître
Tous les fournisseurs d’API ne délivrent pas un seul type de clé. La plupart distinguent une clé publique (utilisable côté navigateur) et une clé secrète (réservée au serveur). Confondre les deux mène soit à un blocage, soit à une fuite de données.
Une clé publique intégrée au JavaScript d’un site peut être lue par n’importe quel visiteur via l’inspecteur du navigateur. Sa sécurité ne repose pas sur le secret, mais sur des restrictions configurées côté fournisseur : domaine d’origine autorisé, liste d’API activées, plafond de requêtes. Google Maps fonctionne sur ce principe : la clé apparaît dans le code source, mais seule l’origine déclarée dans la console Google Cloud peut l’exploiter.
A découvrir également : Comment améliorer le site web ?
La clé secrète, elle, ne transite jamais par le navigateur. Elle reste sur le serveur applicatif, stockée dans une variable d’environnement ou un gestionnaire de secrets. Si elle apparaît dans une requête réseau côté client, c’est une erreur de configuration, pas un fonctionnement normal.
Trouver sa clé API dans le tableau de bord d’un fournisseur
La méthode la plus directe pour obtenir une clé API consiste à se connecter au panneau d’administration du service concerné. Chaque fournisseur organise cette page différemment, mais le parcours suit un schéma commun.
Parcours type sur une console cloud ou un service SaaS
- Connectez-vous au tableau de bord du fournisseur (Google Cloud Console, OpenAI Platform, Stripe Dashboard, etc.), puis accédez à la section intitulée « Identifiants », « API Keys » ou « Clés API » dans les paramètres du projet.
- Créez une nouvelle clé si aucune n’existe. La plupart des fournisseurs n’affichent la clé secrète complète qu’une seule fois, au moment de la création. Copiez-la immédiatement et stockez-la dans un endroit sûr.
- Appliquez des restrictions dès la création : limitez la clé à certaines API, certains domaines ou certaines adresses IP. Sur Google Cloud, la page « Identifiants » permet de restreindre par type d’application (navigateur, serveur, Android, iOS).
- Si la clé est perdue, la procédure standard consiste à en générer une nouvelle et à mettre à jour l’application concernée. Les clés supprimées cessent de fonctionner immédiatement, ce qui peut interrompre un service en production.
OpenAI, par exemple, centralise la gestion sur sa page dédiée aux clés API. Le centre d’aide précise qu’une clé perdue ne peut pas être récupérée : il faut en créer une nouvelle puis la déployer dans l’application.
Observer les clés API exposées dans les requêtes réseau d’un site
Lorsqu’un site web appelle une API depuis le navigateur, la clé transite dans la requête HTTP. L’onglet « Network » des DevTools de Chrome ou Firefox permet de l’observer.
Procédure dans Chrome DevTools
Ouvrez les outils de développement (F12 ou Ctrl+Maj+I), sélectionnez l’onglet « Network », puis rechargez la page. Filtrez par « Fetch/XHR » pour isoler les appels API. Cliquez sur une requête, puis examinez l’URL (paramètre key= ou api_key=), les en-têtes (Authorization, X-Api-Key) et éventuellement le corps de la requête.
La clé que vous trouvez dans ce contexte est presque toujours une clé publique restreinte. Elle ne donne pas un accès complet au compte du propriétaire du site. Tenter de l’utiliser hors du domaine autorisé déclenche un rejet côté serveur.
Limites et précautions de l’inspection réseau
Un fichier HAR (archive complète d’une session réseau) peut contenir bien plus qu’une clé publique. Cookies de session, jetons Bearer, mots de passe transmis en clair : une capture réseau brute ne doit jamais être partagée sans nettoyage. Supprimer les en-têtes sensibles avant tout envoi à un tiers est une précaution non négociable.
Clés API dans le code source : le piège de l’historique Git
Beaucoup de développeurs commettent l’erreur de placer une clé API directement dans un fichier de configuration versionné. Même après suppression du fichier, la clé reste accessible dans l’historique des commits. Quiconque clone le dépôt ou consulte un ancien commit peut la retrouver.
Les outils de détection de secrets (secret scanners) analysent non seulement le code actuel, mais aussi l’historique Git, les pull requests, les wikis et les discussions associés à un dépôt. GitHub propose une protection à l’envoi qui bloque certaines signatures connues avant qu’un commit ne soit publié. Cette protection ne couvre pas toutes les catégories de secrets : les chaînes de connexion personnalisées ou les clés privées au format non standard peuvent passer entre les mailles.
La bonne pratique consiste à stocker toute clé dans une variable d’environnement ou un service de gestion de secrets (vault), puis à ajouter le fichier de configuration local au .gitignore. Si une clé a déjà été poussée, la supprimer du fichier ne suffit pas : il faut la révoquer côté fournisseur et en générer une nouvelle.
Restrictions et sécurité des clés API
Obtenir une clé n’est que la première étape. La configurer correctement détermine le niveau réel de protection du projet.
Sur Google Cloud, les restrictions se répartissent en deux catégories : restriction d’application (quel type de client peut utiliser la clé) et restriction d’API (quels services la clé peut appeler). Une clé sans restriction d’application accepte les requêtes de n’importe quelle origine, ce qui expose le quota de facturation à un usage abusif.
Côté OpenAI, la recommandation est plus directe : ne communiquez votre clé à personne. Le modèle de sécurité repose sur le secret de la clé, pas sur une restriction d’origine comme pour les API web publiques.
Vérifier régulièrement les clés actives dans la console du fournisseur, supprimer celles qui ne servent plus et surveiller les alertes de secret scanning sur les dépôts de code constituent trois gestes qui réduisent la surface d’exposition sans complexité technique supplémentaire.
