API-Schlüssel im Frontend: was 30.998 Apps wirklich ausliefern

Jemand öffnet deine App, drückt F12 und sagt dir, dass ein API-Schlüssel in deinem Frontend offenliegt. Das Wort dafür ist meistens „geleakt". Welcher Schlüssel es ist, sagt kaum jemand dazu, und die Ratgeber, die du danach findest, behandeln alle als denselben Notfall.

Es ist nicht derselbe Notfall, und wir können den Abstand inzwischen beziffern. Zwischen dem 12. und 14. August 2026 haben wir neun externe Prüfungen über 30.998 live erreichbare Apps laufen lassen, gebaut mit Lovable, Bolt, v0, Replit und Base44, und das JavaScript gelesen, das jede davon an einen Browser ausliefert. Das war darin.

Ist ein API-Schlüssel im Frontend wirklich ein Problem?

Meistens nicht, und die Verteilung dieses „meistens" ist schiefer, als wir erwartet hatten.

Wir fanden einen nennenswerten Schlüssel in 1.332 der 30.998 Apps. In 1.080 davon war das Einzige, was wir fanden, ein Google-API-Schlüssel, also genau die Zugangsdaten, die in deiner Seite stehen sollen. Was diesen einen schützt, ist eine Einstellung auf Googles Seite, und Verstecken war nie Teil der Abmachung.

Die übrigen 29.666 Apps lieferten nichts aus, was unsere Geheimnis-Prüfung als Problem behandelt. Diese Zahl braucht eine Einschränkung, um ehrlich zu sein. Veröffentlichbare Schlüssel sind darin nicht enthalten: Ein Supabase-anon- oder ein Stripe-pk_-Schlüssel gehört in den Browser, wir markieren ihn also als etwas, das du richtig gemacht hast, und er geht in diese Zählung nie ein.

Was wir gezählt haben und was nicht

Wir haben jede App so geladen, wie ein Besucher es tut, in einem echten Browser, und das heruntergeladene JavaScript gelesen. Alles Folgende ist eine Form, die in diesem Code stand.

Wir erkennen Schlüsselformate, die wir kennen. Stripe, OpenAI, Anthropic, AWS, Google und Supabase haben erkennbare Präfixe, und ein Supabase-JWT nennt seine eigene Rolle im mittleren Abschnitt als lesbaren Text. Zugangsdaten in einem Format, das wir nicht kennen, stehen nicht in diesen Zahlen, lies sie also als Untergrenze.

Wir haben keinen gefundenen Schlüssel benutzt. Kein einziges Mal, bei keiner App. Wir haben den Typ und einen maskierten Hinweis der Form sk_live_…a1b2 notiert, und der echte Wert wurde nirgends aufgeschrieben.

Keine App wird genannt. Nicht hier, nicht im Datensatz, nirgends, wo wir veröffentlichen.

Fast alle davon sind Apps auf der Publish-Domain eines Builders. Die vollständige Methode, die Stichprobe und jede Zahl hinter diesem Artikel stehen in unserem Scan-Bericht, einschließlich dessen, was wir nicht messen konnten.

Was die 30.998 Apps tatsächlich auslieferten

Eine Tabelle, sortiert danach, wie oft wir das Jeweilige gesehen haben. Die Geheimnis-Prüfung wurde bei allen 30.998 Apps abgeschlossen, jede Zahl unten bezieht sich also auf alle.

Die Zeilen ergeben zusammen mehr als 1.332, weil eine App zwei davon tragen kann. Sortiert man dieselben 1.332 Apps in Gruppen, die sich nicht überschneiden, wird das Bild noch deutlicher: 1.080 hatten einen Google-Schlüssel und sonst nichts, 198 hatten einen Wert mit hoher Entropie, der echte Zugangsdaten sein kann oder auch nicht, und 54 hatten einen Schlüssel, der schon seiner Form nach ein echtes Geheimnis ist.

Die zweite Gruppe verdient eine genaue Beschreibung. Ein Wert mit hoher Entropie neben einem Wort wie secret oder password kann echte Zugangsdaten sein, er kann aber auch eine Sitzungskennung sein, ein Build-Hash oder ein öffentliches Token mit einem unglücklichen Namen. Wir melden das als nachsehenswert, und von außen kann niemand dir sagen, was davon es ist.

Die 54 in der dritten Gruppe sind die echte Sache. Alle bis auf zwei bekamen die Note D oder F, weil ein einziger kritischer Fund die Note bei D deckelt, egal was die App sonst richtig gemacht hat. Die größte einzelne Gruppe darin ist der OpenAI-Schlüssel mit 33, und für den gibt es keine Einstellung, die ihn im Browser unbedenklich machen würde.

Der Schlüssel, vor dem alle warnen, war der seltenste Fund

Drei Apps. So viele lieferten einen Supabase-service_role-Schlüssel aus, also den, der an jeder Tabellenregel vorbeigeht, die du geschrieben hast. Ein geheimer Stripe-Schlüssel tauchte ebenfalls dreimal auf.

Stell das neben die andere Hälfte desselben Durchlaufs. Von den gescannten Apps nannten 8.429 ein Supabase-Projekt, und beide Funde liegen innerhalb dieser einen Gruppe. Drei davon lieferten den service_role-Schlüssel aus. In 2.096 davon antwortete mindestens eine Tabelle auf eine Anfrage ganz ohne Login, und in 394 trug diese Tabelle einen Namen für Menschen: users, profiles, customers, orders.

Die 2.096 sind eine Untergrenze. 4.749 der 8.429 haben unsere Datenbankprüfung nie beantwortet, aus Gründen, die wir von außen nicht sehen, und die notieren wir als unbekannt statt als sauber. Die drei service_role-Schlüssel sind eine exakte Zahl, weil ein Schlüssel aus Code gelesen wird, den jede App herausgibt.

Warum die Warnungen auf den falschen Schlüssel zeigen

Wir sehen nur die Außenseite dieser Apps, wir können dir also nicht sagen, warum. Zeigen können wir, welcher Fehler überlebt.

Den falschen Supabase-Schlüssel zu kopieren ist wirklich leicht. In einem älteren Projekt stehen anon und service_role nebeneinander im selben Dashboard-Bereich, sie sind gleich lang und gleich geformt, und es geht nichts kaputt, wenn du den falschen nimmst. Trotzdem passierte es nur dreimal in 30.998 Apps, weil dich nichts dorthin drängt. Beide Schlüssel bringen die App zum Laufen.

Hinter der offenen Tabelle steht eine Kraft. Row Level Security wird angeschaltet, die App zeigt keine Daten mehr, eine Policy, die alle erlaubt, wird geschrieben, damit es wieder geht, und von diesem Moment an meldet das Dashboard die Tabelle als geschützt. Anschalten ist nicht dasselbe wie geschützt sein. Unser Scan bewertet diese Tabelle als kritischen Fund an einem Tag, an dem dein Dashboard dir den Schalter auf an und eine vorhandene Policy zeigt.

Wie du einen offenliegenden API-Schlüssel kostenlos findest

Fang von Hand an, das kostet fünf Minuten und braucht nichts Installiertes. Öffne deine Live-Seite, sieh dir den Seitenquelltext an und suche nach vier Zeichenfolgen: AIza für einen Google-Schlüssel, sk_ für ein Stripe- oder Modellanbieter-Geheimnis, service_role für den Supabase-Schlüssel, der deine Regeln ignoriert, und eyJ für jedes Supabase-Token. Alles, was zurückkommt, liegt bereits in den Händen jedes Besuchers, den du hast.

Damit hast du die Seite selbst. Was dabei fehlt, ist das JavaScript, das die Seite danach nachlädt, und genau deshalb öffnet unser eigener Scanner eine App in einem echten Browser und liest die Bundles statt des HTML. Die Suche von Hand kann dir außerdem nicht sagen, ob das gefundene eyJ-Token der anon-Schlüssel oder der geheime ist, denn die beiden sind gleich lang und gleich geformt.

Unser kostenloser Scan deckt beides ab. Er lädt deine App in einem echten Browser, liest den Code, der tatsächlich ankommt, dekodiert jedes Supabase-Token und meldet die darin geschriebene Rolle, sodass ein veröffentlichbarer Schlüssel als korrekt markiert zurückkommt und nicht in einer Wand aus Rot verschwindet. Note, Punktzahl und die Anzahlen stehen nach etwa 20 Sekunden ohne Konto auf dem Bildschirm. Gib eine E-Mail-Adresse an, und du bekommst zusätzlich die ausführliche Liste, mit einer Lösung für deinen Builder, die du direkt einfügen kannst.

Drei Dinge tut er nicht, und das sind die Gründe, warum er auf einer Live-App gefahrlos läuft: Er meldet sich nie an, er schreibt nie etwas, und er behält nie einen gefundenen Schlüssel. Ein offengelegtes Geheimnis wird als maskierter Hinweis wie sk_live_…a1b2 gespeichert, der echte Wert wird verworfen. Scanne deine App, oder lies zuerst, was jede der neun Prüfungen ansieht.

Was zu tun ist, in der Reihenfolge, die die Zahlen nahelegen

Arbeite die ganze Liste in einer Sitzung durch mit der 10-Minuten-Sicherheitscheckliste, die den Schlüssel und die Tabellenregeln neben den anderen Dingen abdeckt, die in einer frisch veröffentlichten App zu schließen sind. Und wenn dich die Datenbankhälfte dieses Artikels beunruhigt: Sie hat eine eigene Erhebung, kann jeder deine Supabase-Datenbank lesen.