Sind Ihre Umgebungsvariablen wirklich geheim?
Warum eine .env-Datei kein Tresor ist und wie Secrets über Builds, Container, Logs und Frontend-Bundles auslaufen.
„Die Zugangsdaten stehen nur in der .env“ klingt sicherer, als es ist.
Eine Umgebungsvariable ist kein Tresor. Sie ist lediglich ein Transportweg für Konfiguration. Secrets können in Build-Logs, Container-Layern, Debug-Ausgaben, CI-Artefakten, Support-Screenshots oder versehentlich ausgeliefertem Frontend-Code landen.
Besonders gefährlich ist die Annahme, dass ein Secret geschützt sei, solange es nicht im Git-Repository steht. Ein API-Key kann das Repository nie berührt haben und trotzdem öffentlich im JavaScript-Bundle erscheinen.
Wo Secrets typischerweise auslaufen
- Build-Argumente werden in Container-Images oder deren Historie sichtbar.
- Variablen mit öffentlichen Frontend-Präfixen werden in Browser-Code eingebettet.
- Debug-Endpunkte geben Konfiguration oder Prozessumgebungen aus.
- CI-Jobs schreiben Werte trotz Maskierung in transformierter Form ins Log.
- Backups und Support-Exporte enthalten
.env-Dateien. - Alte Schlüssel bleiben nach Agentur- oder Mitarbeiterwechsel aktiv.
- Ein gemeinsam genutztes „Master-Secret“ öffnet mehrere Systeme gleichzeitig.
Docker empfiehlt für Build-Zugangsdaten spezielle Secret- oder SSH-Mounts statt Build-Argumenten oder normalen Umgebungsvariablen. Der OWASP Secrets Management Cheat Sheet empfiehlt zentralisierte Verwaltung, kurze Gültigkeit, Rotation, eingeschränkte Berechtigungen und nachvollziehbare Zugriffe.
Schnelltest für Ihr Projekt
- Durchsuchen Sie das gebaute Frontend nach bekannten Schlüsselpräfixen und Domainnamen interner Dienste.
- Prüfen Sie Container-Historie und Image-Layer auf Build-Argumente und Dateien.
- Kontrollieren Sie, welche Rollen Produktions-Secrets lesen können.
- Listen Sie alte, ungenutzte und nie rotierte Schlüssel auf.
- Prüfen Sie Logs, Error Tracking und CI-Ausgaben auf sensible Werte.
- Klären Sie, wie ein kompromittierter Schlüssel widerrufen wird.
- Testen Sie, ob die Anwendung nach einer Rotation ohne längeren Ausfall weiterläuft.
Gute Secret-Hygiene ist langweilig – und genau das ist gut
Ein belastbarer Prozess trennt Entwicklungs-, Test- und Produktionszugänge. Jeder Dienst erhält nur die minimal nötigen Rechte. Secrets werden nicht in Images eingebaut, sondern zur Laufzeit sicher bereitgestellt. Rotation ist dokumentiert und möglichst automatisiert.
Wichtig ist außerdem die Klassifizierung: Nicht jede Umgebungsvariable ist geheim. Öffentliche Basis-URLs oder Feature-Flags dürfen sichtbar sein. Datenbankpasswörter, private API-Schlüssel, Signaturschlüssel und Tokens gehören dagegen in ein geeignetes Secret-Management-System.
Was Website-Pflichtencheck prüfen würde
Bei einem technischen Check betrachten wir die gesamte Kette: Quellcode, Build-Konfiguration, CI/CD, Container, Frontend-Bundles, Logs, Hosting-Einstellungen, Berechtigungen und Rotation.
Der Check ist besonders sinnvoll nach einem Agenturwechsel, einem Repository-Leak, einer Migration, einem neuen CI-System oder wenn Zugangsdaten über Jahre gewachsen sind.
„Nicht in Git“ ist nur der Anfang. Wenn Sie nicht genau wissen, wo ein Secret erzeugt, verwendet, protokolliert, rotiert und widerrufen wird, ist die eigentliche Sicherheitslücke der fehlende Prozess.