OpenAI API key exposed in the browser: NEXT_PUBLIC_, VITE_ and dangerouslyAllowBrowser
The client said undefined , so the key got a prefix. Then the SDK refused to run in the browser, so it got a flag: " use client " ; const openai = new OpenAI ({ apiKey : process . env . NEXT_PUBLIC_OPENAI_API_KEY , dangerouslyAllowBrowser : true , }); It works. And the OpenAI API key is now in plai

Veröffentlicht am 28. Oktober • Ursprünglich veröffentlicht auf jaytank.hashnode.dev
Der Client meldete undefined, also bekam der Schlüssel ein Praefix. Dann weigerte sich das SDK, im Browser zu laufen, also bekam es ein Flag:
Die OpenAI- und Anthropic-JS-SDKs blockieren Browser standardmaessig, "um zu vermeiden, dass Ihre geheimen API-Zugangsdaten offengelegt werden". dangerouslyAllowBrowser: true schaltet diese Absicherung aus.
Hinzu kommt ein Schluessel, der "nur zum Testen" in eine Komponente eingefuegt wurde.
Loesung: Den Provider aus einer Server-Route mit einer server-only Variable aufrufen, die Seite diese Route aufrufen lassen und jeden Schluessel rotieren, der jemals ausgeliefert wurde. Das Loeschen aus dem Code reicht nicht: alte Builds und Caches enthalten ihn weiterhin. In einer Vite-App ohne Server uebernimmt eine kleine Serverless- oder Edge-Funktion dieselbe Aufgabe.
Ich habe BrowserKey gebaut, eine kostenlose VS Code Extension, die all diese Probleme fuer Next.js, Vite, CRA, Expo, Nuxt, Gatsby, SvelteKit und Astro sowie fuer OpenAI, Anthropic, Gemini, Groq, xAI, OpenRouter und mehr erkennt. Sechs Regeln, ein Quick Fix zum Umbenennen in eine server-only Variable und ein Panel in der Activity Bar:
NEXT_PUBLIC_OPENAI_API_KEY in.env.local wird in den Browser-Bundle aufgenommen, new OpenAI({ dangerouslyAllowBrowser: true }) legt den API-Schluessel offen, hartkodierter OpenAI-Schluessel sk-proj-**** im Browser-Code. Schluessel werden immer maskiert angezeigt. Kein Netzwerkzugriff, keine Telemetrie, keine Kindprozesse.
code --install-extension jaytankdev.browserkey. Quellcode (MIT): github.com/jay-tank/browserkey
Ausfuehrlicher Artikel (Framework-Dokumentation, die Server-Route-Loesung, alle sechs Regeln, FAQ): OpenAI API key exposed in the browser
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 28 • Originally published at jaytank.hashnode.dev
The client said undefined, so the key got a prefix. Then the SDK refused to run in the browser, so it got a flag:
The OpenAI and Anthropic JS SDKs block browsers by default "to avoid exposing your secret API credentials". dangerouslyAllowBrowser: true switches that guard off.
Plus a key pasted into a component "just to test".
Fix: call the provider from a server route with a server-only variable, have the page call that route, and rotate any key that was ever deployed. Deleting it from the code is not enough: old builds and caches still have it. In a Vite app with no server, a small serverless or edge function does the same job.
I built BrowserKey, a free VS Code extension that catches all of these for Next.js, Vite, CRA, Expo, Nuxt, Gatsby, SvelteKit and Astro, and for OpenAI, Anthropic, Gemini, Groq, xAI, OpenRouter and more. Six rules, a Quick Fix to rename to a server-only variable, and an activity bar panel:
NEXT_PUBLIC_OPENAI_API_KEY in.env.local is bundled into the browser new OpenAI({ dangerouslyAllowBrowser: true }) exposes the API key hardcoded OpenAI key sk-proj-**** in browser code Enter fullscreen mode Exit fullscreen mode Keys are always masked. No network, no telemetry, no child processes.
code --install-extension jaytankdev.browserkey Enter fullscreen mode Exit fullscreen mode Source (MIT): github.com/jay-tank/browserkey
Full write-up (framework docs, the server route fix, all six rules, FAQ): OpenAI API key exposed in the browser