Was jeder in Ihrem Code lesen kann
Zugangsschlüssel für Datenbank, KI-Dienste und Zahlungen, Fehlermeldungen und andere Spuren im HTML und in den JavaScript-Dateien Ihrer App.
Jeder Besucher kann den Quelltext Ihrer Startseite und die JavaScript-Dateien Ihrer App öffnen, im Browser reichen zwei Klicks. Steht darin ein Zugangsschlüssel, kann ihn jeder kopieren und benutzen. Wir lesen das HTML der Startseite und die JavaScript-Dateien, die sie selbst von Ihrer Domain einbindet. Dazu kommen bis zu 40 Teile, die diese Dateien beim Wechsel auf eine Unterseite nachladen, etwa für den Admin-Bereich, bei Next.js die Code-Teile der anderen Seiten und Konfigurationsdateien wie /config.json, die der Code selbst beim Start abruft. Der Browser lädt sie ebenso. Schlüssel, die mit atob() Base64-kodiert im Code stehen, lesen wir dekodiert mit. Was die Befunde an Punkten kosten, steht in Was abgezogen wird.
Schlüssel im Quelltext und in den JavaScript-Dateien
Ein Zugangsschlüssel im Code ist wie ein Haustürschlüssel unter der Fußmatte. Wer ihn findet, kommt damit an Ihre Datenbank, Ihr Zahlungskonto oder Ihre KI-Dienste, mit Ihren Rechten und auf Ihre Kosten. Liegen dahinter personenbezogene Daten, kann daraus eine meldepflichtige Datenpanne werden.
Bei Apps aus Lovable, Bolt, v0, Cursor oder Claude Code stehen Schlüssel selten im HTML. Sie landen beim Bauen in den JavaScript-Dateien, etwa unter /assets/index-….js bei Vite oder /_next/static/ bei Next.js. Deshalb laden wir diese Dateien wie ein Browser und durchsuchen sie nach diesen Mustern:
| Was wir suchen | Was jemand damit tun kann |
|---|---|
| Supabase-Generalschlüssel (service_role) und geheimer Supabase-Schlüssel (sb_secret) | Ganze Datenbank lesen, ändern und löschen, an allen Zugriffsregeln vorbei |
| Schlüssel für OpenAI, Anthropic, OpenRouter, Groq, xAI, Hugging Face, Replicate, Perplexity oder ElevenLabs | KI-Anfragen auf Ihre Rechnung |
| Geheime Stripe-Schlüssel (sk_live, rk_live) | Je nach Rechten Zahlungen erstatten und Kundendaten abrufen |
| AWS-Zugangsschlüssel | Je nach Rechten Speicher, Server und Rechnung Ihres AWS-Kontos |
| GitHub- und Slack-Token | Je nach Rechten Quellcode oder Nachrichten lesen und ändern |
| Schlüssel für SendGrid, Resend, Brevo, Mailchimp und Twilio | Mails und SMS in Ihrem Namen und auf Ihre Kosten, auch Phishing mit Ihrer Absenderadresse |
| Zugangstoken mit eindeutigem Präfix: Supabase-Konto (sbp_), Shopify-Admin, Google OAuth (GOCSPX-), Webhook-Signaturen (whsec_), Notion, Airtable, Telegram-Bot, GitLab, npm, DigitalOcean, Netlify, Linear, Mapbox (sk.), PostHog (phx_), Sentry, Pinecone, LangSmith, Cloudinary | Je nach Dienst Daten lesen und ändern, Bestellungen oder Nachrichten auslösen, gefälschte Webhook-Ereignisse einspielen |
| Webhook-Adressen für Slack, Discord, Teams oder Zapier | Nachrichten in Ihre Kanäle schicken, auch gefälschte Anweisungen |
| Datenbank-Adressen mit Passwort und private Schlüssel | Direkt an der Datenbank anmelden oder sich als Ihr Dienst ausgeben |
Dieselben Muster suchen wir im HTML der Startseite, also auch in Inline-Skripten und eingebetteten Daten wie __NEXT_DATA__ oder window.__ENV. Jede gefundene Schlüsselart kostet 40 Punkte, egal ob im HTML oder in einer JavaScript-Datei. Im HTML suchen wir zusätzlich nach Werten unter Namen wie client_secret, api_secret oder access_token. Dort kostet jede Art 25 Punkte, weil der Name allein noch kein Beweis ist. Wir nennen Art und Fundstelle, also die Datei oder den Seitenquelltext, bei Werten unter Namen wie api_key auch den Namen. Den Wert zeigen wir nur gekürzt, etwa sk_live_…9f2A oder AKIA…MPLE, damit Sie den Schlüssel beim Anbieter zuordnen können. Bei Datenbank-Adressen sehen Sie Benutzer und Host, das Passwort ist geschwärzt. Den vollständigen Wert zeigen, speichern und benutzen wir nie.
Drei weitere Befunde gehören dazu:
- Geheim benannte Variablen. Alles mit VITE_, NEXT_PUBLIC_, REACT_APP_ oder EXPO_PUBLIC_ im Namen baut das Werkzeug in den Code ein, den jeder Browser bekommt. Steht dahinter SECRET, PRIVATE oder PASSWORD, liegt dort vermutlich ein Wert, der nie öffentlich sein sollte.
- Supabase direkt aus dem Browser. Den öffentlichen Supabase-Schlüssel (anon) erkennen wir an der Rolle, die in ihm steht. Er darf im Browser stehen, schützt die Daten aber nur mit Zugriffsregeln auf jeder Tabelle. Das melden wir als Hinweis. Wie Sie die Regeln prüfen, steht in Zugriffsregeln in Supabase.
- KI-Aufruf aus dem Browser. Siehe KI-Schlüssel weiter unten.
So gehen Sie bei einem gefundenen Schlüssel vor:
- Schlüssel sperren und neu erzeugen. Widerrufen Sie den alten beim Anbieter und legen Sie einen neuen an. Ihn nur aus dem Code zu löschen reicht nicht, denn er kann längst in Kopien, Zwischenspeichern und im Git-Verlauf liegen.
- Den neuen Schlüssel auf dem Server lassen. Er gehört in eine Server-Funktion und in die geschützten Einstellungen Ihres Hosters, nie in Code, den der Browser bekommt. In Lovable oder Bolt können Sie den Assistenten bitten, den Schlüssel in eine Server-Funktion zu verschieben.
- Nachsehen. Prüfen Sie in den Logs und der Abrechnung des Anbieters, ob jemand den alten Schlüssel benutzt hat.
- Meldepflicht klären. Waren personenbezogene Daten erreichbar, prüfen Sie mit Ihrem Datenschutzbeauftragten, ob eine Meldung nach DSGVO nötig ist. Die Einzelheiten stehen in Ein Schlüssel ist offen.
Google-Schlüssel im HTML oder in den JavaScript-Dateien melden wir nur als Hinweis, weil sie oft absichtlich im Browser stehen, etwa für Google Maps. Unbeschränkt kann ihn jeder für andere Google-Dienste auf Ihre Kosten nutzen. Beschränken Sie so einen Schlüssel in der Google Cloud Console auf Ihre Domain und die Dienste, die Sie brauchen. Steht er in einer Firebase-Konfiguration, melden wir stattdessen Firebase direkt aus dem Browser.
KI-Schlüssel und KI-Aufrufe aus dem Browser
Viele generierte Apps rufen OpenAI oder Anthropic direkt aus dem Browser auf. Dafür muss der Schlüssel im Frontend stehen. Jeder Besucher kann ihn dort auslesen. Wer ihn hat, stellt Anfragen auf Ihre Rechnung, bis Kontingent oder Budget aufgebraucht sind. GitGuardian hat 2025 1.275.105 geleakte Schlüssel für KI-Dienste gezählt, 81 % mehr als im Vorjahr (State of Secrets Sprawl 2026).
Wir erkennen diese Aufrufe an Einstellungen, mit denen die Bibliotheken von OpenAI und Anthropic den Browser ausdrücklich erlauben müssen (dangerouslyAllowBrowser). Dazu kommen die Schlüssel selbst, wenn sie in den JavaScript-Dateien stehen.
So beheben Sie es: Sperren Sie den Schlüssel und erzeugen Sie einen neuen. Leiten Sie jeden KI-Aufruf über eine eigene Server-Funktion, etwa eine Supabase Edge Function oder einen API-Endpunkt bei Vercel. Der Browser spricht dann nur mit Ihrem Server. Setzen Sie beim Anbieter ein Ausgabenlimit.
Unverschlüsselte Teile auf einer HTTPS-Seite
Lädt eine verschlüsselte Seite Bilder, Skripte oder Stylesheets über http, ist dieser Teil unverschlüsselt. Jemand im selben Netz kann ihn mitlesen oder austauschen, bei einem Skript also eigenen Code in Ihre Seite bringen. Fachleute sagen Mixed Content dazu. Wir zählen Angaben mit http:// in src sowie Stylesheets, Icons und Manifeste, die per link eingebunden sind. Normale Links auf andere Seiten zählen nicht, sie laden nichts nach.
So beheben Sie es: Stellen Sie die Adressen auf https:// um. Zusätzlich hilft upgrade-insecure-requests in der Content-Security-Policy.
Sichtbare Fehlermeldungen
Steht auf der Seite Text wie „Fatal error“, „Stack trace“ oder eine PHP-Warnung, zeigt Ihr Server technische Fehler öffentlich an. Darin stehen oft Dateipfade, Dateinamen und Versionen, die Angreifern die Suche nach Lücken erleichtern.
So beheben Sie es: Lassen Sie Fehler nur noch in eine Logdatei schreiben, nicht auf die Seite. Bei WordPress geht das in der wp-config.php:
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);Fremde Skripte ohne Fingerabdruck
Skripte von fremden Servern laufen mit allen Rechten auf Ihrer Seite. Wird so ein Server manipuliert, läuft der veränderte Code bei Ihnen mit und kann etwa Formulareingaben abgreifen. Ein Fingerabdruck der erwarteten Datei im Attribut integrity verhindert das: Weicht die Datei ab, lädt der Browser sie nicht. Das Verfahren heißt Subresource Integrity, kurz SRI.
<script src="https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js"
integrity="sha384-…" crossorigin="anonymous"></script>Den Wert für integrity zeigen die meisten CDNs neben der Datei an. SRI klappt nur bei Dateien mit fester Version. Deshalb zählen wir nur Skripte, deren Adresse eine vollständige Versionsnummer trägt, etwa jquery-3.7.1.min.js, @1.2.3 oder /1.2.3/. Skripte von Diensten, die sich laufend ändern, etwa Tag Manager, Einwilligungsbanner, Chat, Zahlungs- oder Login-Widgets, zählen nicht mit. Auskommentierte Einbindungen wie <!--[if IE]> lädt kein heutiger Browser, sie zählen ebenfalls nicht.
Source Maps
Eine Source Map macht zusammengepressten Code wieder lesbar. Beim Entwickeln hilft das. Auf der Live-Seite kann damit jeder Ihren ursprünglichen Quellcode samt Kommentaren und internen Pfaden lesen und gezielt nach Schwachstellen oder vergessenen Schlüsseln suchen. Wir melden, wenn das HTML oder eine der JavaScript-Dateien auf eine solche Datei verweist und sie wirklich ausgeliefert wird. Dafür rufen wir höchstens drei verlinkte .map-Dateien an und lesen nur den Anfang. Ihren Inhalt speichern wir nicht.
So beheben Sie es: Schalten Sie Source Maps im Build-Werkzeug für die Live-Seite ab, bei Vite etwa mit build.sourcemap: false. Bei den meisten Werkzeugen ist das schon voreingestellt.
Verweise auf heikle Dateien
Verweist das HTML in einem Link, einer Quelle oder einem Formular auf Dateien wie .env, .git oder wp-config.php oder auf Endungen wie .bak, .old, .sql oder .swp, melden wir das als Hinweis. In solchen Dateien stehen oft Passwörter und Schlüssel. Wir rufen sie nicht ab und wissen deshalb nicht, ob sie erreichbar sind.
So prüfen Sie es selbst: Öffnen Sie die Adresse im Browser. Sehen Sie Inhalt statt einer Fehlerseite, entfernen oder sperren Sie die Datei sofort und ändern Sie alle Zugangsdaten, die darin stehen.
Noch Fragen? Schreiben Sie uns.