Ein geheimer Stripe-Schlüssel im Frontend kann Geld bewegen

Öffne deine laufende App in einem Browser, sieh dir den Seitenquelltext an und such darin nach sk_live_. Kommt eine lange Zeichenkette zurück, liegt ein geheimer Stripe-Schlüssel offen in deinem Frontend, und jeder Besucher, den du je hattest, hätte ihn kopieren können.

Hier ist der Punkt, an dem der allgemeine Rat zu API-Schlüsseln danebenliegt: Stripe gibt dir zwei aktive Schlüssel, sie sehen fast gleich aus, und einer davon soll in deiner App liegen. Der Schlüssel, der mit pk_live_ beginnt, gehört dorthin. Der Schlüssel, der mit sk_live_ beginnt, hat in Stripes eigenen Worten uneingeschränkte Rechte für alle APIs. Sie unterscheiden sich um ein Zeichen mitten in einer langen Zeichenkette, und das ist der größte Teil des Grundes, warum das immer wieder passiert.

Zwischen dem 12. und 14. August 2026 haben wir neun externe Prüfungen über 30.998 laufende Apps laufen lassen, gebaut mit Lovable, Bolt, v0, Replit und Base44. Drei davon lieferten einen aktiven geheimen Stripe-Schlüssel aus, zwei weitere einen eingeschränkten, womit das zu den seltensten Funden des Durchlaufs gehört; dieselben neun Prüfungen fanden in 1.142 Apps einen Google-API-Schlüssel. Alle drei geheimen Schlüssel kamen mit Note D heraus, weil ein einziger kritischer Befund die Note dort deckelt, egal was die App sonst richtig gemacht hat. Die vollständigen Zahlen stehen in unserem Scan-Bericht.

Ist ein geheimer Stripe-Schlüssel im Frontend ein Problem?

Ja, wenn die Zeichenkette mit sk_live_ beginnt. Nein, wenn sie mit pk_live_ beginnt.

Stripe gibt zwei aktive Schlüssel aus, weil die beiden Hälften einer Zahlung an zwei verschiedenen Orten stattfinden. Stell dir einen Ladentresen vor. Das Kartenlesegerät zeigt zur Kundschaft und ist gut sichtbar festgeschraubt, und das Schlimmste, was eine Fremde damit anstellen kann, ist dich zu bezahlen. Die Kasse hinter dem Tresen ist ein ganz anderes Ding. Sie geht auf, sie enthält die Tageseinnahmen, und in der Schublade darunter liegt für jeden Kunden eine Karte mit seiner Anschrift darauf.

pk_live_ ist das Kartenlesegerät. Seine Aufgabe ist es, im Browser von jemand anderem ein Bezahlformular aufzubauen, und Stripes Dokumentation sagt, dass öffentliche Schlüssel im Frontend-Code offenliegen dürfen.

sk_live_ ist der Kassenschlüssel. Stripe beschreibt geheime Schlüssel als Schlüssel mit uneingeschränkten Rechten für alle APIs, was derselbe Satz von der anderen Seite gelesen ist: es gibt nichts in deinem Konto, was er nicht erreicht.

Deine App braucht das Kartenlesegerät im Browser, um überhaupt eine Zahlung annehmen zu können. Den Kassenschlüssel sollte sie nie brauchen.

pk_live_ und sk_live_: wie du sie auseinanderhältst

Lies das zweite Zeichen des Präfixes. Das ist die ganze Prüfung.

Die Mitte des Präfixes ist das Zweite, was du liest. _test_ erreicht nichts außer deiner Sandbox, ein geleakter Testschlüssel kostet dich also kein Geld; er veröffentlicht trotzdem, wie deine Integration gebaut ist, und Stripes Leitlinie lautet, jeden geheimen oder eingeschränkten Schlüssel an der falschen Stelle als kompromittiert zu behandeln. Neuere Konten können außerdem einen Organisationsschlüssel tragen, der mit sk_org_ beginnt und über mehr als ein Stripe-Konto hinweg arbeitet. Für ihn gilt dieselbe Regel, und ein Leck reicht dort weiter als über ein einzelnes Konto.

Was jemand mit einem geleakten geheimen Stripe-Schlüssel anstellen kann

Alles, was du in deinem eigenen Dashboard tun kannst und wofür kein Passwort nötig ist.

Nicht „unbefugten Zugriff erlangen". Konkret, mit nichts als der Zeichenkette und einem Terminal: deine vollständige Kundenliste lesen, mit Namen, E-Mail-Adressen, Rechnungsanschriften und den letzten vier Ziffern jeder Karte. Jede Zahlung nachlesen, die du je erhalten hast, und wofür jeder Kunde bezahlt hat. Erstattungen auslösen. Abbuchungen und Bezahllinks in deinem Namen anlegen. Abos kündigen.

Dann gibt es noch den Gebrauch, der mit dir gar nichts zu tun hat. Dein Konto wird zum Ort für Card Testing, Stripes eigener Begriff dafür, dass eine Betrügerin gestohlene Kartennummern durch die Integration von irgendwem schickt, um die noch gültigen zu finden. Die Karten gehören anderen Leuten. Die Ablehnungen, die Rückbuchungen und das Erklären gehören dir.

Was sie meistens nicht können, ist sich selbst bezahlen. Eine Erstattung geht zurück auf die Karte, mit der ursprünglich bezahlt wurde, und eine Auszahlung geht auf das hinterlegte Bankkonto, und das ist deins. Das klingt nach einer guten Nachricht und ist keine: es bedeutet, dass der Schaden als abfließendes Geld, als kopierte Kundendaten und als ein für fremden Betrug benutztes Konto ankommt, statt als Überweisung, auf die du zeigen und der du nachgehen könntest.

Nichts davon braucht raffinierte Angreifer. Stripes eigene Dokumentation sagt, dass betrügerische Akteure fortlaufend öffentliche Codebestände nach offenliegenden Schlüsseln durchsuchen, und diese Scanner müssen nicht wissen, wer du bist, um deinen zu finden.

Wie du einen geheimen Stripe-Schlüssel ohne Zahlungsausfall austauschst

Erzeuge zuerst den Ersatz, nimm ihn in Betrieb, lass dann den alten ablaufen. In dieser Reihenfolge.

1. Lege im Stripe-Dashboard einen neuen geheimen Schlüssel an. Lass den alten vorerst in Ruhe; beide funktionieren gleichzeitig, und genau diese Überlappung hält deine Kasse am Laufen.
2. Leg den neuen Schlüssel dorthin, wo der alte lag, und das sollte ein Server sein, eine Edge Function oder eine Serverless-Route. Niemals die App, die der Browser herunterlädt.
3. Deploye, dann nimm eine echte Zahlung an. Eine gelungene Zahlung ist der einzige Beweis, dass der neue Schlüssel richtig verdrahtet ist.
4. Lass den alten Schlüssel ablaufen. Stripe beschreibt das genau so: einen geheimen oder eingeschränkten Schlüssel ablaufen zu lassen hindert ihn an jedem weiteren API-Aufruf.
5. Lies deine Zahlungshistorie für den Zeitraum, in dem der Schlüssel offenlag, und deine Stripe-Mails auf alles, was nicht von dir kam.

Ist der Schlüssel schon draußen und verlierst du lieber ein paar Zahlungen, als ihn noch eine Stunde aktiv zu lassen, dann mach es andersherum. Einen Schlüssel auszutauschen sperrt ihn unmittelbar und erzeugt einen neuen, und Stripe weist darauf hin, dass mit dem alten Schlüssel angelegte Webhook-Endpunkte aktiv bleiben, deine Ereignisverarbeitung überlebt den Notfall also.

Es gibt noch einen Schritt, und es ist der, den die meisten zuerst machen: den Schlüssel aus dem Code löschen. Mach es, und sei dir im Klaren darüber, was es bewirkt. Deine Besucher haben die Datei, die ihn trug, längst heruntergeladen, diese Datei liegt in Browser-Caches, über die du keine Kontrolle hast, und der alte Wert steht weiterhin in deiner Versionsgeschichte. Den Schlüssel bei Stripe ablaufen zu lassen ist das, was die Tür schließt. Die Zeile zu entfernen hält dich davon ab, ihn erneut auszuliefern.

Öffentliche Schlüssel lassen sich übrigens gar nicht ablaufen. Stripe hat die Funktion nie gebaut, weil dieser Schlüssel nie geheim sein sollte.

Was ein eingeschränkter Stripe-Schlüssel ist und wann er die Antwort ist

Ein Schlüssel, der für eine Aufgabe zugeschnitten ist statt für jede.

Ein eingeschränkter Schlüssel beginnt mit rk_live_ und trägt nur die Rechte, die du beim Anlegen ankreuzt. Ein Schlüssel, der Rechnungen lesen darf, kann keine Erstattung auslösen. Ein Schlüssel, der Abbuchungen anlegen darf, kann deine Kundenliste nicht lesen. Stripe empfiehlt aus genau diesem Grund den Umstieg von geheimen auf eingeschränkte Schlüssel, und das ist guter Rat für den Code, der auf deinem Server läuft.

Es ist kein Weg, einen Schlüssel im Browser vertretbar zu machen. Zwei der 30.998 Apps in unserem Durchlauf lieferten einen eingeschränkten Schlüssel im Frontend aus, und beide kamen mit Note C heraus. Unser Scan bewertet einen eingeschränkten Schlüssel als hohen Befund, wo ein geheimer ein kritischer ist, und ein einziger hoher Befund deckelt die Note bei C. Wer diesen Schlüssel findet, bekommt weiterhin jedes Recht, das du angekreuzt hast, von überall.

Wo ein eingeschränkter Schlüssel seinen Platz verdient, ist der unbequeme Fall dazwischen, und vibe-codierte Apps produzieren eine Menge davon. Ein Automatisierungswerkzeug, das deine Auszahlungen lesen muss. Ein Auswertungsskript, das jemand auf Fiverr für dich geschrieben hat. Eine Edge Function, die immer nur eine einzige Art von Abbuchung anlegt. Jedes davon läuft auf einem Server und jedes davon braucht einen Bruchteil deines Kontos, also bekommt jedes seinen eigenen Schlüssel mit genau diesem Bruchteil angekreuzt, und an dem Tag, an dem eines leckt, ziehst du einen Schlüssel zurück, statt deine ganze Integration neu zu verdrahten.

Wie du prüfst, was deine App tatsächlich ausliefert

Fang von Hand an, es kostet nichts und braucht nichts Installiertes. Öffne deine laufende Website, sieh dir den Seitenquelltext an und such darin nach sk_live_, dann nach rk_live_, dann nach pk_live_. Den dritten zu finden und die ersten beiden nicht, ist das Ergebnis, das du willst.

Was eine Suche im Seitenquelltext verpasst, ist das JavaScript, das die Seite danach lädt, und bei einer App von Lovable, Bolt oder Replit ist das so gut wie alles. Unser kostenloser Scanner öffnet deine App in einem echten Browser, wartet, bis die Bundles eintreffen, und liest die. Er ordnet ein, was er findet, statt nur nach schlüsselförmigen Zeichenketten zu suchen, also kommt pk_live_ als richtig markiert zurück und sk_live_ als kritischer Befund, und die beiden landen nie auf demselben Stapel.

Note, Punktzahl und die Anzahlen stehen in etwa 20 Sekunden auf dem Bildschirm, ohne Konto. Gibst du eine E-Mail-Adresse an, kommt die ausführliche Liste dazu, zusammen mit einer Lösung, die für den von dir benutzten Builder geschrieben ist und die du direkt einfügen kannst.

Drei Dinge, die der Scan nicht tut, und das sind die Gründe, warum du ihn ohne Sorge auf eine laufende App mit echten Zahlungen richten kannst: er meldet sich nie an, er schreibt nie etwas, und er behält nie einen gefundenen Schlüssel. Ein offenliegendes Geheimnis wird als maskierter Hinweis der Form sk_live_…a1b2 gespeichert, und der echte Wert wird weggeworfen. Scanne deine App, oder lies vorher, worauf jede der neun Prüfungen schaut.

Was du jetzt tun solltest

Ein Stripe-Schlüssel kommt meistens spät. Die App geht live, sie läuft eine Weile, und dann fügst du eines Tages die Kasse hinzu, und genau dieses Deploy legt zum ersten Mal einen Zahlungszugang ins Bundle. Der Scan, den du beim Start laufen ließest, war eine Momentaufnahme einer App, die noch kein Geld annehmen konnte.

Reeve Monitor ist für diese Lücke gebaut. Es lässt alle neun Prüfungen jede Stunde über bis zu drei Apps laufen, prüft die Erreichbarkeit alle 60 Sekunden, sagt dir an dem Tag Bescheid, an dem sich ein Ergebnis ändert, statt darauf zu warten, dass du nachsiehst, und schickt einen monatlichen Bericht in verständlicher Sprache. Ein Schlüssel, der mit einem Deploy am Donnerstag ins Bundle gerät, ist in dem Scan dieser Stunde. Es kostet €12 im Monat laut Liste, mit sieben kostenlosen Tagen, bevor es abbucht, und die Preisseite liegt manchmal unter der Zahl hier und nie darüber.

Wenn du das lieber als Liste durchgehst: die 10-Minuten-Sicherheitscheckliste deckt das hier zusammen mit den anderen Dingen ab, die es in einer frisch gestarteten App zu schließen lohnt. Für die größere Frage, welche Schlüssel überhaupt in einen Browser gehören, haben wir eine Anleitung zum Unterscheiden öffentlicher und geheimer Schlüssel, dieselbe Frage für einen OpenAI-Schlüssel, und eine Bestandsaufnahme dessen, was 30.998 Apps tatsächlich ausgeliefert haben.