Clé API exposée dans le navigateur ? Vérifiez votre clé OpenAI, Claude ou Gemini en 2 minutes

Si votre application web appelle OpenAI, Claude ou Gemini directement depuis le navigateur, votre clé API est exposée dans le navigateur, et quiconque ouvre les DevTools peut la copier. Vous pouvez le vérifier en 2 minutes : ouvrez l'onglet Réseau, envoyez une requête IA, et cherchez un en-tête Authorization, x-api-key ou x-goog-api-key envoyé au fournisseur. Si vous y voyez votre clé, renouvelez-la aujourd'hui et déplacez l'appel derrière une route serveur.

Ci-dessous : la vérification, l'ordre des corrections, et comment votre agent de codage peut tester la route corrigée.

Pourquoi une clé API exposée dans le navigateur est un problème

Une clé API exposée dans le navigateur est un secret qui est livré dans votre code frontend ou votre trafic réseau, où chaque visiteur peut le lire. Si le navigateur envoie la clé, l'utilisateur peut la copier et appeler le fournisseur sur votre facture.

Le guide de la clé API Gemini de Google indique « Ne codez pas en dur les clés API directement dans les applications web ou mobiles » car « Les clés compilées dans du code côté client peuvent être extraites par les utilisateurs », et il vous recommande d'« exécuter un serveur proxy backend pour effectuer les appels API réels ». Le guide de sécurité des clés API d'OpenAI donne la même règle : acheminez les requêtes via votre propre backend au lieu de déployer la clé sur le client.

Le README d'openai-node indique que le support du navigateur est désactivé par défaut « pour éviter d'exposer vos identifiants API secrets », et vous devez définir dangerouslyAllowBrowser: true pour l'activer. Le SDK TypeScript d'Anthropic utilise le même nom d'option, et son API n'accepte les appels navigateur (CORS) que lorsque la requête porte l'en-tête anthropic-dangerous-direct-browser-access: true, comme l'a documenté Simon Willison lors de sa sortie.

Ce schéma est courant dans les applications construites rapidement avec des générateurs d'applications IA et des agents de codage : le chemin fonctionnel le plus court est un fetch depuis un composant React avec la clé dans une variable VITE_ ou NEXT_PUBLIC_. Les clés volées sont ensuite revendues pour de l'inférence en masse, comme expliqué dans notre article sur les clés API IA volées et le LLMjacking, et c'est sur votre facture que vous vous en apercevez.

Comment vérifier si votre clé API est exposée (2 minutes)

Effectuez ces vérifications sur la production, pas sur localhost.

1. Surveillez l'onglet Réseau (45 secondes). Ouvrez votre site, appuyez sur F12 (Cmd+Option+I sur un Mac), choisissez l'onglet Réseau et déclenchez une fonctionnalité IA, comme l'envoi d'un message de chat. Filtrez par openai, anthropic ou googleapis. Si une requête va directement vers api.openai.com, api.anthropic.com ou generativelanguage.googleapis.com, cliquez dessus et ouvrez Headers. Une clé dans Authorization: Bearer, x-api-key, x-goog-api-key ou un paramètre de requête ?key= signifie qu'elle est exposée.
2. Cherchez dans le bundle (45 secondes). Dans les DevTools, appuyez sur Cmd+Option+F (Ctrl+Shift+F sous Windows) pour rechercher dans tous les scripts chargés. Cherchez sk-, sk-ant-, AIza et dangerouslyAllowBrowser. Toute occurrence dans un fichier .js servi au navigateur est une fuite, même si aucune requête n'a encore été déclenchée.
3. Vérifiez les préfixes de vos variables d'environnement (30 secondes). Ouvrez votre fichier .env et votre tableau de bord d'hébergement. Les outils de build copient certaines variables dans le bundle client par conception : VITE_* dans Vite (voir la doc env de Vite),NEXT_PUBLIC_* dans Next.js, REACT_APP_* dans Create React App et EXPO_PUBLIC_* dans Expo. Une clé de fournisseur derrière l'un de ces préfixes est publique, peu importe son nom.

Pour une analyse en terminal de la sortie de votre build :

# from your project root after a production build
grep -rnoE "sk-(proj-|ant-)?[A-Za-z0-9_-]{20,}|AIza[0-9A-Za-z_-]{35}" dist/ build/ .next/static/ 2>/dev/null
grep -rn "dangerouslyAllowBrowser" dist/ build/ .next/static/ 2>/dev/null

Une sortie vide est un succès. Google précise que les nouvelles clés AI Studio créées depuis le 28 mai 2026 sont des « clés d'authentification », dont le format peut différer de AIza, donc cherchez aussi generativelanguage.googleapis.com dans le bundle. Vous réussissez uniquement lorsque le navigateur communique avec votre propre domaine (par exemple /api/chat) et qu'aucun nom d'hôte de fournisseur ni aucune clé n'apparaît nulle part.

Que faire lorsque votre clé est exposée : ordre des corrections

Renouveler d'abord ferme la brèche du jour ; le changement d'architecture la ferme définitivement.

Déployez la nouvelle clé côté serveur avant de révoquer l'ancienne, sinon votre fonctionnalité IA tombera en panne. Notre guide sur les bonnes pratiques de rotation des clés API couvre la rotation sans interruption. À l'étape 4, les recommandations de sécurité des clés d'OpenAI préconisent des limites de dépenses avec application stricte, car les alertes seules n'arrêtent pas le trafic ; un budget de facturation Google Cloud vous alerte mais n'arrête pas l'utilisation à lui seul.

Comment déplacer les appels OpenAI, Claude et Gemini derrière une route serveur

Une route de proxy backend est un petit point d'accès serveur qui reçoit le prompt de l'utilisateur, ajoute la clé API côté serveur, appelle le fournisseur et renvoie uniquement la réponse. Le navigateur ne voit jamais la clé. Voici une route Next.js minimale pour OpenAI ; Claude et Gemini suivent la même forme :

// app/api/chat/route.ts (runs on the server only)
import OpenAI from "openai";
import { getSession } from "@/lib/auth";        // your auth helper
import { checkRateLimit } from "@/lib/limits";  // your per-user limiter

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY }); // no NEXT_PUBLIC_ prefix

export async function POST(req: Request) {
  const session = await getSession(req);
  if (!session) return new Response("Unauthorized", { status: 401 });

  if (!(await checkRateLimit(session.userId, 20))) {   // 20 requests per minute
    return new Response("Too many requests", { status: 429 });
  }

  const { message } = await req.json();
  if (typeof message !== "string" || message.length > 4000) {
    return new Response("Bad request", { status: 400 });
  }

  const response = await client.responses.create({
    model: process.env.OPENAI_MODEL!,   // pin the model server-side
    input: message,
  });

  return Response.json({ reply: response.output_text }); // return the answer, nothing else
}

Ce qui la rend sûre, et pas seulement cachée :

• Le modèle vit sur le serveur. Si c'est le navigateur qui choisit le modèle, un attaquant choisit le plus cher.
• L'entrée est plafonnée. Pas de prompts énormes via votre compte.
• Seule la réponse revient. Ne renvoyez jamais la réponse brute du fournisseur ni l'objet d'erreur.
• Aucun préfixe public. OPENAI_API_KEY reste côté serveur ; NEXT_PUBLIC_OPENAI_API_KEY est livré à chaque visiteur.

Pour Claude et Gemini, utilisez leurs SDK avec ANTHROPIC_API_KEY ou GEMINI_API_KEY. Les restrictions de site web et d'IP de Google aident, mais n'importe qui avec curl peut envoyer n'importe quel en-tête Referer, alors considérez-les comme une seconde couche. Le seul cas légitime d'appel navigateur est un outil apportez-votre-propre-clé où chaque utilisateur colle sa propre clé.

Laissez votre agent de codage tester la route proxy avec Apidog CLI

Déplacer la clé, c'est la moitié du travail ; l'autre moitié consiste à prouver qu'elle reste déplacée après la prochaine fonctionnalité écrite par votre agent. Laissez l'agent qui a construit la route la tester avec Apidog CLI. Configurez-le une fois :

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Ensuite, donnez à Claude Code, Codex, Cursor ou à l'agent que vous utilisez un seul prompt :

Create Apidog test cases in project <id> for POST /api/chat on our staging
environment that assert:
1. a request without a session cookie returns 401,
2. a valid request returns 200 and the body does not contain "sk-", "sk-ant-",
   "AIza" or "api_key",
3. the 21st request inside 60 seconds from the same user returns 429.
Run them and summarize any failures.

L'agent lit le schéma, valide sa charge utile, écrit les cas de test et les exécute :

apidog test-case category --project <id>
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> -r cli,json

La deuxième assertion est la plus importante : elle échoue dès qu'un objet d'erreur de fournisseur ou un champ de débogage commence à renvoyer votre clé au client. Placez la même étape apidog run ... -r junit dans votre pipeline pour que chaque déploiement la revérifie ; notre guide Apidog CLI CI/CD montre la configuration, et Apidog CLI dans Claude Code couvre le côté agent. Le plan gratuit d'Apidog couvre jusqu'à 4 utilisateurs, donc une petite équipe peut faire tourner cela sans siège payant.

Pour le volet dépôt du même problème, les clés commitées dans Git plutôt que livrées au navigateur, voir notre vérification de fuite de clé API avec un scanner de secrets. Si vos agents appellent des outils qui manipulent des données clients, tester les agents IA pour les fuites de données couvre la couche suivante.

Erreurs courantes qui maintiennent la clé exposée

• Encoder la clé en base64 ou la découper. Le navigateur doit la reconstituer pour l'envoyer, donc les DevTools affichent la vraie valeur.
• La déplacer vers localStorage ou un cookie. Elle est toujours sur le client.
• Faire un proxy sans authentification. Un /api/chat public est un point d'accès IA ouvert sur votre facture.
• Garder l'ancienne clé « au cas où ». Une clé qui a été publique pendant un jour est copiée.
• Oublier l'application mobile. Le guide de Google mentionne « applications web ou mobiles » ensemble, ce n'est pas un hasard.

FAQ

Comment savoir si ma clé API OpenAI est exposée dans le navigateur ? Déclenchez une fonctionnalité IA avec l'onglet Réseau des DevTools ouvert. Une requête vers api.openai.com avec un en-tête Authorization: Bearer sk-... signifie qu'elle est exposée. Cherchez aussi sk- et dangerouslyAllowBrowser dans les scripts chargés.

Est-il sûr de mettre une clé API dans une variable d'environnement NEXT_PUBLIC_ ou VITE_ ? Non. Ces préfixes existent pour copier des valeurs dans le bundle client. Toute clé de fournisseur stockée sous ces préfixes est livrée à chaque visiteur. Utilisez une variable sans préfixe, réservée au serveur, et lisez-la à l'intérieur d'une route serveur.

Restreindre une clé API Gemini à mon site web la rend-elle sûre dans le navigateur ? Cela aide, mais un script en dehors du navigateur peut envoyer n'importe quel en-tête Referer. Le guide de Google lui-même recommande un proxy backend pour les applications clientes.

J'ai découvert que ma clé est exposée. Que dois-je faire en premier ? Créez une nouvelle clé, déployez-la côté serveur, puis révoquez l'ancienne. Ensuite, déplacez l'appel derrière une route authentifiée avec des limites de débit par utilisateur, et définissez des limites de dépenses chez le fournisseur.

Mon agent de codage peut-il corriger et tester cela pour moi ? Oui. Demandez-lui de déplacer l'appel au fournisseur dans une route serveur, puis utilisez Apidog CLI pour créer et exécuter des tests qui vérifient un 401 sans session, l'absence de motifs de clé dans les réponses et un 429 au-delà de votre limite de débit.