Reeve Sicherheitsgrundlagen
Ist ein Google-API-Schlüssel im Frontend ein Problem?
Ein Google-API-Schlüssel im Frontend ist der Fund unseres Scanners Nummer eins, und meistens unbedenklich. Eine kostenlose Einstellung entscheidet darüber.
Kurz gesagt
- Ein Google-API-Schlüssel im Frontend ist meistens unbedenklich, denn ein Google-Schlüssel ist eine Abrechnungskennung und kein Passwort.
- Unbedenklich macht ihn eine HTTP-Referrer-Einschränkung: eine Einstellung, die Google sagt, dass der Schlüssel nur von deiner eigenen Website aus funktioniert.
- Sie ist kostenlos, dauert etwa fünf Minuten und ist die eine Sache, die sich heute lohnt.
- Eine Google-Dienstkonto-Datei in deiner App ist der andere, dringende Fall. Das sind echte Zugangsdaten.
Öffne deine App im Browser, sieh dir den Seitenquelltext an und suche nach
AIza. Wenn eine vierzig Zeichen lange Zeichenfolge auftaucht, hat dir
vermutlich schon jemand gesagt, sie sei „offengelegt", und vermutlich nicht
dazugesagt, was nun zu tun ist.
Hier ist der Punkt, den die meisten Ratgeber falsch darstellen: Ein Google-API-Schlüssel im Frontend ist nicht dieselbe Art von Problem wie ein geheimer Stripe-Schlüssel im Frontend, und die Lösung besteht nicht darin, ihn zu verstecken. Beide gleich zu behandeln führt entweder zu Panik wegen deiner Karte oder, schlimmer, dazu, dass du das Wort „offengelegt" achselzuckend übergehst, kurz bevor es wirklich zählt.
Zwischen dem 12. und 14. August 2026 haben wir dieselben neun externen Prüfungen über 30.998 live erreichbare Apps laufen lassen, gebaut mit Lovable, Bolt, v0, Replit und Base44. In 1.142 davon steckte ein Google-API-Schlüssel. In dreien steckte ein geheimer Stripe-Schlüssel. Die vollständigen Zahlen stehen in unserem Scan-Bericht.
Ist es schlimm, wenn mein Google-API-Schlüssel im Frontend sichtbar ist?
Meistens nicht. Es hängt ganz davon ab, ob der Schlüssel eingeschränkt ist.
Ein Google-API-Schlüssel ist kein Passwort. Er ähnelt eher einer Kundennummer: Er sagt Google, welches Projekt abgerechnet und welches Kontingent belastet wird. Für sich genommen sagt er nichts darüber aus, wer die Anfrage stellt.
Deshalb darf er auf deiner Seite stehen. Die Karte wird vom Browser deines Besuchers gezeichnet, also muss der Browser die Kundennummer an Google schicken. Es gibt keine Variante davon, in der die Karte lädt und die Nummer verborgen bleibt.
Der Schutz kommt aus einer zweiten Einstellung auf Googles Seite, die festlegt, von welchen Websites die Nummer benutzt werden darf. Google nennt das eine HTTP-Referrer-Einschränkung. Ist sie gesetzt, funktioniert der in deiner Seite abgedruckte Schlüssel auf deiner Website und gibt überall sonst einen Fehler zurück.
Warum deine App den Schlüssel überhaupt ausliefert
Weil die Anfrage vom Browser deines Besuchers ausgeht und nicht von deinem Server.
Wenn jemand eine Seite mit einer Karte lädt, spricht dieser Browser direkt mit
maps.googleapis.com. Er muss angeben, zu welchem Google-Projekt die Anfrage
gehört, und diese Kennung muss in der Seite stehen, weil die Anfrage von der
Seite ausgeht.
Google weiß das. Genau deshalb existiert die Einschränkung als eigenes Steuerelement: Die Kennung würde ohnehin öffentlich werden, also liegt die Entscheidung darüber, wer sie benutzen darf, an einem Ort, den die Öffentlichkeit nicht erreicht.
So schränkst du einen Google-API-Schlüssel ein
Es ist kostenlos, dauert etwa fünf Minuten, und du musst den Code deiner App nicht anfassen. In der Google Cloud Console:
- Gehe zu APIs & Dienste → Anmeldedaten und klicke auf den gefundenen Schlüssel.
- Wähle unter Anwendungseinschränkungen die Option Websites.
- Trage deine Domain ein. Für eine Website unter
yourapp.comalsohttps://yourapp.com/*. Trage auch deine Vorschau- oder Staging-Domain ein, falls du eine hast, und denk an die.lovable.app- oder.vercel.app-Adresse, unter der deine App veröffentlicht war, bevor du eine eigene Domain angebunden hast. - Wähle unter API-Einschränkungen die Option Schlüssel einschränken und hake nur die APIs an, die deine App wirklich aufruft. Eine Karte mit Ortssuche braucht die Maps JavaScript API und die Places API, sonst nichts.
- Speichern, ein paar Minuten warten, dann deine eigene Website laden und prüfen, ob die Karte noch gezeichnet wird.
Ist Schritt 3 falsch, merkst du es sofort und sichtbar: Die Karte scheitert mit
RefererNotAllowedMapError in der Browser-Konsole, was das Problem genau
benennt. Trage die fehlende Domain nach, und es funktioniert wieder. Diese
Änderung ist umkehrbar, und deshalb lohnt es sich, sie zu machen, bevor du diesen
Artikel zu Ende gelesen hast.
Eines solltest du nicht tun: Googles eigene Hinweise zur Fehlersuche sagen, dass IP-Einschränkungen für serverseitige Schlüssel gedacht und für einen im Browser benutzten Schlüssel ungeeignet sind. Schränkst du einen Frontend-Schlüssel per IP ein, bricht deine App für jeden Besucher.
Wenn du lieber erst siehst, welche Schlüssel deine App tatsächlich ausliefert, statt sie einzeln durchzugehen: Unser kostenloser Scan liest deine Live-Website von außen und zeigt dir, was er findet. Er dauert etwa 20 Sekunden und braucht kein Konto: App scannen.
Welche Google-Zugangsdaten in einen Browser gehören
| Zugangsdaten | Wie es aussieht | Im Frontend? | Was tatsächlich schützt |
|---|---|---|---|
| Maps- oder Places-Browser-Schlüssel | AIza… | Gehört hierher | Die Referrer-Einschränkung plus ein Kontingentlimit |
| Firebase-Web-Konfigurationsschlüssel | AIza… | Gehört hierher | Firebase Security Rules und App Check |
| Ein Schlüssel für deinen Server | AIza… | Niemals | Nichts, sobald er öffentlich ist. Serverseitig halten |
| Dienstkonto | eine JSON-Datei mit "private_key" darin | Niemals | Nichts. Das sind echte Zugangsdaten |
Die ersten drei Zeilen sind dieselbe Zeichenfolge. Einem Google-API-Schlüssel sieht man vorne nicht an, wofür er da ist. Die Frage lautet also nie „wie sieht dieser Schlüssel aus", sondern „was darf dieser Schlüssel", und diese Antwort steht in der Console und nicht in deinem Code.
Der Firebase-Schlüssel soll öffentlich sein
Das ist die Zeile, nach der am häufigsten gefragt wird, und Firebases eigene Dokumentation beantwortet sie unmissverständlich: API-Schlüssel für Firebase-Dienste dürfen in Code oder Konfigurationsdateien stehen, weil sie den Zugriff auf gar nichts steuern. Das entscheiden die Firebase Security Rules und App Check.
Falls dir das bekannt vorkommt: Es ist dieselbe Anordnung wie bei Supabase. Der öffentliche Schlüssel benennt das Projekt, und die Regeln dahinter entscheiden Zeile für Zeile, wer was lesen darf. In beiden Fällen ist der Schlüssel nur wegen dieser Regeln sicher, also sind die Regeln das, was du dir ansehen solltest: sie einzuschalten bedeutet nicht, geschützt zu sein.
Was passiert, wenn ein uneingeschränkter Schlüssel abfließt
Eine Rechnung, ein Ausfall oder beides. Kein Datenleck.
Automatische Scraper durchsuchen öffentliche Seiten nach AIza-Zeichenfolgen,
und ein uneingeschränkter Schlüssel funktioniert von überall. Deiner liefert dann
Kartenkacheln und Ortsabfragen für das Projekt von jemand anderem. Google benennt
das direkt in seiner eigenen Einstiegsdokumentation: Der Grund für
Einschränkungen ist, Kontingentdiebstahl zu verhindern.
Du bemerkst es normalerweise auf eine von zwei Arten. Die Rechnung ist höher als im Vormonat, ohne dass du sagen könntest warum, oder die Karten deiner App hören mitten im Monat auf zu laden, weil das Projekt sein Kontingent aufgebraucht hat und jeder Besucher nun ein graues Rechteck sieht.
Beides lässt sich beheben. Beides legt keine Daten deiner Nutzer offen, denn ein Maps-Schlüssel kann deine Datenbank nicht lesen. Das ist der ehrliche Unterschied zwischen diesem Fund und einem abgeflossenen Datenbankschlüssel, und deshalb meldet unser Scanner einen Google-API-Schlüssel als etwas zum Nachsehen und nicht als Notfall.
Die eine Google-Zugangsdatei, die sich tatsächlich wie ein Notfall verhält, ist
ein Dienstkonto. Liefert deine App eine JSON-Datei mit
"type": "service_account" und einem "private_key"-Block aus, dann sind das
echte Zugangsdaten mit echten Berechtigungen für dein Cloud-Projekt. Lösche den
Schlüssel in der Console und sieh dann nach, worauf er Zugriff hatte.
Was du jetzt tun solltest
Was zu tun ist
- Durchsuche den Seitenquelltext deiner Live-Website nach
AIza. Für jeden Treffer musst du geradestehen. - Schränke jeden davon in der Google Cloud Console ein: Websites unter den Anwendungseinschränkungen, deine Domain, und nur die APIs, die du nutzt. Kostenlos, etwa fünf Minuten, keine Codeänderung.
- Setz gleich noch ein Tageslimit für das Kontingent. Die Einschränkung senkt den Verkehr; ein Limit deckelt, was davon überhaupt kosten kann.
- Lass deinen Firebase-Konfigurationsschlüssel, wo er ist. Prüfe stattdessen, ob deine Security Rules ihre Arbeit tun, und halte die Gemini API aus der Zulassungsliste dieses Schlüssels heraus.
- Findest du eine
service_account-JSON-Datei in deinem Frontend, behandle das als dringend. Lösche den Schlüssel in der Console, statt nur die Datei zu entfernen, denn deine Versionsgeschichte enthält den alten Wert weiterhin.
Wenn du das lieber als Liste abarbeitest: Die 10-Minuten-Sicherheitscheckliste deckt das zusammen mit den anderen Dingen ab, die man in einer frisch veröffentlichten App abschalten sollte. Und für die größere Frage, welche Schlüssel überhaupt in einen Browser gehören, haben wir eine Anleitung, wie du öffentliche von geheimen Schlüsseln unterscheidest.
FAQ
Jemand hat meinen Google-Maps-Schlüssel im Seitenquelltext gefunden. Soll ich ihn austauschen?
Schränke ihn zuerst ein, das dauert etwa fünf Minuten und macht nichts kaputt. Öffne den Schlüssel in der Google Cloud Console, setze die Anwendungseinschränkungen auf Websites und trage deine Domain ein, und beschränke ihn dann unter API-Einschränkungen auf die APIs, die deine App nutzt. Austauschen kommt danach, und nur wenn der Schlüssel eine Weile uneingeschränkt war und du Nutzung siehst, die nicht von dir stammt.
Kann ich den Schlüssel nicht einfach verstecken?
Nein. Der Browser deines Besuchers muss den Schlüssel an Google schicken, um die Karte zu laden. Alles, was der Browser benutzen kann, kann ein Besucher lesen. Minifizieren oder Umbenennen hält jemanden nur ein paar Sekunden auf. Den Schlüssel einzuschränken ist die Lösung, die tatsächlich wirkt, und sie wirkt unabhängig davon, ob jemand den Schlüssel findet.
Mein Schlüssel ist auf meine Domain beschränkt. Kann ihn trotzdem jemand benutzen?
Ein Referrer-Header lässt sich fälschen, also kann jemand mit genug Entschlossenheit Anfragen schicken, die vorgeben, von deiner Website zu kommen. Was die Einschränkung beseitigt, ist der einfache Fall: ein automatischer Scraper, der Schlüssel auf öffentlichen Seiten einsammelt und sie direkt von seinem eigenen Server aus benutzt. Genau dieser Verkehr erzeugt überraschende Rechnungen, also lohnt sich die Einschränkung, auch wenn sie keine Mauer ist. Setz zusätzlich ein Tageslimit für das Kontingent, dann hast du eine Obergrenze für alles, was das kosten kann.
Firebase hat einen API-Schlüssel in meine Konfigurationsdatei geschrieben. Ist das ein Fehler?
Nein, und Firebase dokumentiert das. Ein Firebase-Web-API-Schlüssel benennt dein Projekt, statt Zugriff zu gewähren, und über den Zugriff entscheiden stattdessen die Firebase Security Rules und App Check. Er gehört in deinen Code. Vermeiden solltest du nur eines: die Gemini Developer API in die Zulassungsliste dieses Schlüssels aufzunehmen, denn das macht aus einem absichtlich veröffentlichten Schlüssel einen, der Geld ausgeben kann.
Was, wenn ich in meiner App eine Datei mit "type": "service_account" finde?
Das ist eine andere Lage, und sie ist dringend. Ein Dienstkonto-Schlüssel enthält echte Zugangsdaten mit einem privaten Schlüssel darin und gehört auf einen Server. Lösche den Schlüssel in der Google Cloud Console unter IAM und Verwaltung, dann Dienstkonten, nimm die Datei aus deinem Frontend, und prüfe deine Abrechnung und deine Audit-Logs. Ihn nur aus dem Code zu löschen schließt die Tür nicht, weil der alte Wert weiterhin in deiner Versionsgeschichte steht.