Darf ich meinen API-Schlüssel in den Code meiner Website schreiben?
Einen geheimen Schlüssel nicht. Alles, was ein Browser ausführt — HTML, JavaScript, CSS — wird an jeden Besucher ausgeliefert, also ist ein in die Seite kopierter geheimer Schlüssel in dem Moment öffentlich, in dem du veröffentlichst; ihn zu minifizieren oder auf drei Zeichenketten zu verteilen ändert daran nichts. Manche Schlüssel gehören dorthin: Anbieter kennzeichnen sie als veröffentlichbare oder Client-Schlüssel und begrenzen sie so, dass Öffentlichkeit unproblematisch ist. Liegt ein geheimer Schlüssel schon auf einer aktiven Seite, tausche ihn beim Anbieter aus, bevor du die Seite anfasst — denn eine Seite offline zu nehmen macht nicht ungeschehen, was bereits ausgeliefert wurde.
Warum eine Seite kein Geheimnis behalten kann
Ein Browser muss alles bekommen, was er ausführt. Das ist keine Schwäche eines bestimmten Hosters oder Frameworks, sondern die Bedeutung von "eine Seite ausliefern": Das Gerät des Besuchers kann deinen Code nicht ausführen, ohne deinen Code zu erhalten. Deshalb genügen die Entwicklerwerkzeuge des Browsers selbst, um zu lesen, was dort steht — ohne Fachwissen und ohne Installation. Minifizieren, Base64-Kodieren oder den Schlüssel aus aneinandergehängten Fragmenten zusammensetzen halten genau so lange, wie jemand braucht, um den zusammengesetzten Wert anzusehen, den der Netzwerk-Tab ohnehin zeigt, mitten in der ausgehenden Anfrage.
Die Unterscheidung, auf die es ankommt, ist also nicht versteckt gegen sichtbar. Es sind zwei Arten von Zugangsdaten, und der Anbieter benennt sie für dich. Ein veröffentlichbarer oder Client-Schlüssel ist dafür gemacht, in einer Seite zu leben: der veröffentlichbare Schlüssel eines Zahlungsanbieters, eine Analytics-Mess-ID, ein auf deine Domain beschränkter Karten-Schlüssel. Sie sind bewusst öffentlich und auf Anbieterseite eingehegt, und genau darum ist es richtig und nicht riskant, sie in den Frontend-Code zu legen. Ein geheimer Schlüssel ist etwas völlig anderes: Er trägt meist die vollen Rechte deines Kontos, kann also Karten belasten, Kundendaten lesen, E-Mails in deinem Namen senden oder dein API-Budget verbrauchen. Das jedem zu überlassen, der die Seite lädt, ist der eigentliche Fehler, und "diese Adresse kennt noch niemand" ist keine Verteidigung, weil Scanner neu veröffentlichte Seiten und öffentliche Repositories fortlaufend genau danach durchsuchen.
Wenn er schon live ist: austauschen, bevor du aufräumst
Der Reflex ist, die Zeile zu löschen und neu zu veröffentlichen. Mach zuerst das Andere. Offline nehmen holt nicht zurück, was schon ausgeliefert wurde: Die alte Fassung kann im Edge-Cache eines CDN liegen, im Cache einer Suchmaschine, in einem Archivdienst oder im Browser eines Besuchers — und wenn die Seite in einem Repository liegt, bleibt der Schlüssel in der Commit-Historie, wo das Entfernen der Zeile in einem späteren Commit den früheren vollkommen lesbar zurücklässt. Der einzige Schritt, der die Offenlegung wirklich beendet, ist das Entwerten der Zugangsdaten beim Anbieter, denn der Anbieter ist die einzige Stelle, an der der Schlüssel geprüft werden muss.
- Den alten Schlüssel widerrufen oder erneuern, damit er nicht mehr funktioniert — einen zweiten daneben anzulegen ändert nichts.
- Einen Ersatz ausstellen und dort ablegen, wo die Seite ihn nicht lesen kann, praktisch also in serverseitiger Konfiguration.
- Das Nutzungs- oder Prüfprotokoll des Anbieters über den gesamten Zeitraum der Offenlegung lesen und nach Aufrufen suchen, die nicht von dir stammen.
- Konnte der Schlüssel Geld bewegen oder Kundendaten erreichen, unbekannte Abbuchungen prüfen und den Pflichten des Anbieters sowie den eigenen gegenüber Betroffenen nachkommen.
- Erst dann die Seite korrigieren — und die Korrektur prüfen, indem du die veröffentlichte Seite abrufst und die Antwort nach dem alten Wert durchsuchst, statt dem Editor zu trauen.
Wohin der Schlüssel stattdessen gehört, und was wir auf aktiven Seiten fanden
Das Muster, das funktioniert: Die Seite hält das Geheimnis nie. Die Seite ruft etwas auf, das du kontrollierst, dieses Etwas hält den Schlüssel und führt den ausgehenden Aufruf durch, und der Browser des Besuchers spricht nur mit dir. Oft musst du das nicht selbst betreiben: Das gehostete Widget eines Anbieters oder ein verwalteter Backend-Dienst ist für diesen Zweck der Server. Ob du mehr brauchst, ist eine eigene Frage, und braucht meine Website ein Backend behandelt, wo die Grenze wirklich verläuft.
Den eigenen Hosting-Betrieb zu führen hat uns dazu etwas Widersinniges beigebracht. AgentCeres — der AI Growth Officer auf agentceres.com — hostet die Seiten, die seine Agents für Kunden bauen, und jede dieser Seiten wird mit einer Content-Security-Policy ausgeliefert, die der Seite jede Netzwerkanfrage verbietet. Ein in so einer Seite eingebetteter Schlüssel kann von ihr nicht einmal benutzt werden: Der Code läuft, rechnet und navigiert, und er hat nirgendwohin, wohin er etwas senden könnte. Diese Eindämmung schützt den Besucher vor der Seite. Und sie trägt überhaupt nichts dazu bei, den Schlüssel vor dem Besucher zu verbergen — das ist die Hälfte, die Leute als Zugabe annehmen.
Am 2026-09-17 haben wir die von Kunden veröffentlichten Seiten durchgesehen und eine gefunden, deren JavaScript den aktiven geheimen Schlüssel eines Zahlungsanbieters einer Variablen zuwies, mit der Ausweisnummer eines Kunden fest eingetragen in einer Abfragefunktion weiter unten in derselben Datei. Beides wurde durch Abrufen der aktiven Seite bestätigt, nicht erschlossen. Es war nichts Exotisches passiert: Der Inhaber hatte den Schlüssel in einen Chat kopiert, während er um eine Funktion bat, die ihn brauchte, und er wurde in die Seite geschrieben. Die Regel, die daraus folgt, ist die Mitnahme wert — kopiere niemals ein aktives Geheimnis in einen Chat mit etwas, das deine Seite schreibt, Coding-Assistenten eingeschlossen, denn das Natürlichste für ein solches Werkzeug ist, den Schlüssel dort zu verwenden, wo der Code ist.
Dieselbe Durchsicht fand das Leck in der anderen Richtung, was zu wissen lohnt, weil fast niemand danach sucht. Generierte Seiten enthalten Anmelde- und Registrierungsformulare, wenn jemand einen Mitgliederbereich verlangt, auch dort, wo kein Server dahintersteht, der jemanden anmelden könnte; und jedes Formular auf so einer Seite wird an einen Formularempfänger angeschlossen. Ein Besucher, der dort ein Passwort eintippte, bekam es im Klartext gespeichert und weitergeleitet. In zwei Fällen im September 2026 waren darunter die echte E-Mail-Adresse und das echte Passwort einer dritten Person, angekommen im Postfach des Inhabers mit dem Aussehen einer gewöhnlichen Anfrage. Inzwischen erkennen wir Feldnamen, die wie Zugangsdaten aussehen, und entfernen diese Werte, bevor irgendetwas gespeichert, versendet oder angezeigt wird; neu veröffentlichte Seiten machen ein solches Feld von vornherein nicht absendbar. Die allgemeine Lehre gilt unabhängig davon, wer die Seite gebaut hat: Sie kann in beide Richtungen lecken, deine Schlüssel nach außen und die Passwörter deiner Besucher nach innen.
FAQ
- Ist es sicher, einen veröffentlichbaren oder öffentlichen API-Schlüssel in meine Website zu legen?
- Ja — dafür sind sie da, und eine Frontend-Funktion, die einen braucht, hat keine andere Möglichkeit. Zwei Dinge machen das sicher und nicht bloß erlaubt: Der Anbieter begrenzt, was diese Schlüsselklasse tun darf, und du wendest die Beschränkung an, die der Anbieter anbietet, meist eine Liste von Domains, für die der Schlüssel antwortet. Ohne diese Beschränkung ist ein öffentlicher Schlüssel für dein Konto weiterhin nicht gefährlich, kann aber von der Seite eines Fremden aus genutzt und dir in Rechnung gestellt werden.
- Bleibt der Schlüssel privat, wenn ich ihn in eine Umgebungsvariable lege?
- Nur wenn der Code, der sie liest, auf einem Server läuft. Das ist das häufigste Missverständnis, denn Frontend-Build-Werkzeuge binden Umgebungsvariablen mit dem öffentlichen Präfix — NEXT_PUBLIC_, VITE_, REACT_APP_ und Entsprechungen — absichtlich zur Bauzeit ins Bundle ein. Die Variable ist in deinen Projekteinstellungen privat und der Wert ist in das ausgelieferte JavaScript eingebacken, landet also genauso in der Seite, als hättest du ihn dort hingeschrieben.
- Mein Schlüssel war offen, aber der Anbieter zeigt keine unerwartete Nutzung. Muss ich ihn trotzdem tauschen?
- Ja. Ein ruhiges Protokoll sagt dir, dass ihn noch niemand benutzt hat, nicht dass ihn niemand hat; automatische Scanner sammeln Schlüssel routinemäßig lange, bevor etwas damit geschieht. Der Tausch kostet jetzt Minuten, die Alternative ist ein offenes Risiko, das du durch Zusehen nicht schließen kannst. Behandle ein sauberes Protokoll als gute Nachricht über die Vergangenheit, nicht als Entscheidung über die Zukunft.
Soll das jemand für dich erledigen?
AgentCeres ist ein gemanagtes KI-Marketingteam: Spezialisten erstellen die Entwürfe, du gibst frei, was rausgeht. 14 Tage kostenlos testen, ab $39/Monat.