.env-Datei & exponierte Secrets
Eine .env-Datei speichert Geheimnisse einer App — API-Schlüssel, Datenbank-Passwörter, Tokens — getrennt vom Code. Sie darf niemals im Browser landen und niemals ins Git-Repository committet werden. Exponierte Secrets sind eine der häufigsten und teuersten Schwachstellen in KI- und No-Code-Apps: Ein einziger geleakter Schlüssel reicht, um Datenbanken auszulesen, fremde Rechnungen zu verursachen oder Nutzerdaten abzugreifen.
Der Sinn einer .env-Datei ist Trennung: Geheimnisse liegen außerhalb des Codes, damit sie nicht versehentlich veröffentlicht werden. Diese Trennung bricht auf zwei Wegen. Erstens serverseitig: Die .env wird ins Git-Repo committet — dann steht jeder Schlüssel dauerhaft in der Historie, auch nach dem Löschen. Zweitens clientseitig: Ein Secret wird über ein NEXT_PUBLIC_- oder VITE_-Präfix ins Browser-Bundle gezogen und ist für jeden lesbar.
Warum das so teuer ist: Ein Schlüssel ist kein Passwort, das nur eine Person kennt — er ist eine Vollmacht. Ein geleakter Stripe-Key kann echte Zahlungen auslösen, ein Cloud-Key echte Server starten (die ihr bezahlt), ein Datenbank-Passwort öffnet den gesamten Datenbestand. Anders als ein Bug fällt ein Leck oft monatelang nicht auf — bis die Rechnung oder der Datenabfluss kommt.
So prüft ihr es: .env-Dateien gehören in .gitignore und dürfen nie im Repo auftauchen; produktive Server (etwa .env am Webserver oder /.git) dürfen von außen nicht erreichbar sein; und im Browser-Bundle darf kein echtes Geheimnis stehen. Unser Rescue-Scan prüft von außen auf offen erreichbare .env- und .git-Pfade und im Deep-Scan das Repository auf committete Secrets — Stripe-, AWS-, GitHub-, OpenAI- und Datenbank-Schlüssel.