API-Keys, die in clientseitigem JavaScript offengelegt sind
Alles, was an den Browser ausgeliefert wird — Inline-Skripte, gebündeltes JS, Source Maps — kann jeder lesen. Secret Keys (OpenAI, Stripe Secret, AWS, Datenbank-URLs), die in Frontend-Code eingebettet sind, sind praktisch veröffentlicht.
Was es ist
Build-Tools fügen Umgebungsvariablen zur Compile-Zeit ein. Wenn du ein Secret in Client-Code referenzierst, landet es im JavaScript-Bundle, das jeder Besucher herunterlädt.
Es gibt eine entscheidende Unterscheidung: Publishable-/Anon-Keys (Stripe pk_live, Firebase-Web-Config) sind für die Öffentlichkeit gedacht, aber Secret Keys (sk_live, Service-Role-Keys, Provider-API-Keys) sind es nicht und dürfen niemals in den Browser gelangen.
Warum es wichtig ist
Ein geleakter Provider-Key erlaubt jedem, auf deine Kosten Nutzung zu verursachen — LLM-Rechnungen, SMS-Gebühren, Cloud-Ausgaben — oder auf Daten zuzugreifen, die der Key autorisiert.
Angreifer durchsuchen JavaScript-Bundles im großen Stil nach Key-Mustern. Ein committetes Secret wird meist innerhalb von Minuten nach dem Live-Gang missbraucht.
So behebst du es
Rufe Drittanbieter-APIs von einer Server-Route oder einem Backend auf, niemals aus dem Browser. Der Browser spricht mit deinem Endpoint; dein Endpoint hält den Key.
// app/api/summarize/route.ts (server-only)
export async function POST(req: Request) {
const { text } = await req.json();
const r = await fetch("https://api.openai.com/v1/responses", {
method: "POST",
headers: { Authorization: `Bearer ${process.env.OPENAI_API_KEY}` },
body: JSON.stringify({ model: "gpt-4o-mini", input: text }),
});
return Response.json(await r.json());
}In Next.js werden nur Variablen mit dem Präfix NEXT_PUBLIC_ an den Browser ausgeliefert. Stelle niemals ein Secret hinter dieses Präfix — verwende es nur für Werte, die gefahrlos öffentlich sein dürfen.
Ist ein Secret in den Browser gelangt, widerrufe es und stelle ein neues aus. Es aus dem nächsten Build zu entfernen, macht bereits abgegriffene Kopien nicht ungültig.
FAQ
Ist mein Stripe Publishable Key (pk_live) im Frontend ein Problem?
Nein — Publishable Keys sind für die Öffentlichkeit gedacht. Das Risiko ist der Secret Key (sk_live), der serverseitig bleiben muss.
Kann ich den Key nicht einfach verschleiern?
Nein. Verschleierung lässt sich trivial rückgängig machen. Die einzige Lösung ist, das Secret vollständig aus dem Client herauszuhalten.
Ist deine App betroffen?
AppSafe prüft dies und Dutzende weitere Probleme in einem kostenlosen Scan.
Meine App gratis scannenAus dem Blog
Falsche KI-Crawler jagen deine .env-Dateien. So prüfst du deine
Credential-Scanner leihen sich die Namen von KI-Crawlern, um an Allowlists vorbeizukommen, und sie fragen nach einer ganz bestimmten Datei: deiner .env. So prüfst du, ob deine erreichbar ist, und wie du sie absicherst.
Das Railway-Datenleck: So rotierst du die Secrets deiner App ohne Ausfallzeit
Railway hat alle Nutzer aufgefordert, ihre Umgebungsvariablen zu rotieren, nachdem Angreifer gezielt nach KI- und Plattform-API-Keys gesucht hatten. So prüfst du, ob du betroffen bist, rotierst alles, ohne deine App lahmzulegen — und sorgst dafür, dass das nächste Datenleck weniger wehtut.
Launchst du eine mit KI gebaute App? Prüfe diese 7 Dinge vorher
KI-Coding-Tools optimieren auf „es funktioniert“, nicht auf „es ist sicher zum Launchen“. Das sind die sieben Probleme, die wir bei jeder frisch gelaunchten App zuerst prüfen — mit der Lösung für jedes.
Verwandte Guides
Offengelegte .env-Dateien: wie Angreifer deine Secrets finden
Eine einzige erreichbare .env kann deinen gesamten Stack preisgeben.
Supabase Row Level Security (RLS): sichere deine Tabellen ab
Dein anon key ist öffentlich. RLS ist das Einzige, was zwischen ihm und deinen Daten steht.
Firebase Security Rules: lass deine Datenbank nicht offen
Deine Firebase-Config ist absichtlich öffentlich. Deine Rules entscheiden, wer die Daten sieht.
Source Maps in der Produktion leaken deinen Quellcode
Ausgelieferte .map-Dateien geben deinen originalen Quellcode preis.