.env-Dateien — 6 Fehler, die Ihre Geheimnisse auf GitHub bringen

Der Bericht „State of Secrets Sprawl“ von GitGuardian aus dem Jahr 2023 hat über 12 Millionen Geheimnisse in öffentlichen GitHub-Repositories gefunden. Die meisten wurden nicht gestohlen – sie wurden von Entwicklern hochgeladen, die tatsächlich dachten, sie hätten sie richtig behandelt. Diese sind die Muster, die verantwortlich sind.

1. Hinzufügen von .gitignore nach dem ersten Commit

.gitignore verhindert nur unverfolgte Dateien aus der Staging-Phase. Sobald eine Datei verfolgt wird – selbst kurzzeitig – ist sie in der Git-Geschichte. Wenn Sie erstellt haben .env, ausgeführt haben git add . && git commit, dann wurde nachträglich .env Zu .gitignore hinzugefügt, bleibt die Datei in allen Commits, die vor diesem Änderungsverlauf existierten.

Prüfen, ob sie bereits in der Geschichte ist:

git log --all -- .env

Wenn das Ergebnis Commits liefert, sind die Geheimnisse in der Geschichte. Drehen Sie zuerst die Zugangsdaten. Danach entfernen Sie die Datei aus der Geschichte mit git-filter-repo (die empfohlene Ersatzlösung für git filter-branch):

pip install git-filter-repo
git filter-repo --path .env --invert-paths

Ein Kraftpush an alle Remotes und benachrichtigen Sie die Teammitglieder, um erneut zu klonen. Die Commits existieren in jeder Clone, die vor der Löschung erstellt wurde – einschließlich automatischer CI-Systeme, die das Repository auscheckten.

2. Kopieren von .env in .env.example ohne Werte zu löschen

Der Standardworkflow: Erstellen Sie .env mit echten Werten, kopieren Sie dann in .env.example um den Teammitgliedern zu zeigen, welche Schlüssel das Projekt benötigt. Der Kopiervorgang ist hier der Fehler.

cp .env .env.example kopiert alles – Schlüssel und Werte. Und .env.example ist vorgesehen, als Commit zu werden. Das ist der gesamte Sinn davon. Echte Werte in .env.example gehen absichtlich in das Repository ein.

❌ Was am Ende in Git landet:

DATABASE_URL=postgres://admin:supersecretpassword@prod-db.example.com/appdb
STRIPE_SECRET_KEY=sk_live_51AbcDefGhiJklMnopQrstUvwx...
JWT_SECRET=my-actual-production-jwt-secret

✅ Was .env.example soll aussehen:

DATABASE_URL=postgres://user:password@localhost:5432/appdb
STRIPE_SECRET_KEY=sk_live_YOUR_KEY_HERE
JWT_SECRET=generate-a-random-secret-min-32-chars

Erstellen .env.example mit Platzhalterwerten erst, commiten Sie es, und kopieren Sie dann in .env und füllen Sie die echten Zugangsdaten ein – nicht umgekehrt.

3. Protokollierung von process.env in Fehlerbehandlungsmodulen

Dieser Punkt beginnt als „Schnell-Debug“ bei einem Vorfall und wird nie entfernt. Oder es existiert in allgemeinen Fehler-Middleware, die harmlos erscheint.

// Classic debug line that makes it to production
console.log('Starting with config:', process.env);

// Generic error handler that dumps everything
app.use((err, req, res, next) => {
  logger.error({ config: process.env, error: err.message });
  res.status(500).json({ error: 'Internal server error' });
});

process.env Im Laufzeitmodus enthält

jede Variable, die von dotenv geladen wurde, sowie Systemvariablen. Wenn das vollständige Objekt an einen Logger übergeben wird, landet es in Ihrem Log-Aggregator, in Ihrem Fehlerverfolgungsservice (Sentry, Datadog, Rollbar) und möglicherweise in Fehlerbenachrichtigungen oder Webhooks. Viele dieser Dienste leiten die Daten an Dritte mit eigenen Zugriffskontrollen weiter.

logger.error({
  nodeEnv: process.env.NODE_ENV,
  appVersion: process.env.APP_VERSION,
  error: err.message,
  stack: err.stack
});

Protokolliere nur die Werte, die für die Diagnose benötigt werden:

4. Verwenden von Geheimnissen in Docker-Bildschichten

# Pattern 1: COPY bakes the entire .env into a layer
COPY .env .

# Pattern 2: ARG/ENV burns values into build metadata
ARG DATABASE_URL
ENV DATABASE_URL=$DATABASE_URL

Zwei Muster, die Geheimnisse dauerhaft in die Docker-Bildgeschichte einbauen:RUN rm .envAuch wenn Sie die Datei in einer späteren Schicht (

docker history --no-trunc your-image:tag

) löschen, ist der Wert weiterhin lesbar in der Bildgeschichte. Jeder mit Pull-Zugriff auf das Bild kann ausführen:

# syntax=docker/dockerfile:1
RUN --mount=type=secret,id=db_url     DATABASE_URL=$(cat /run/secrets/db_url) ./setup.sh

Und die ARG-Werte aus dem Buildzeitpunkt wiederherstellen. Docker BuildKit-Geheimnisse sind das richtige Werkzeug – sie mounten Geheimnisse während des Builds, ohne sie in eine Schicht zu schreiben: docker run -e oder environment: Für die Laufzeitkonfiguration werden Umgebungsvariablen beim Start des Containers über COPYin Docker Compose abgefragt, die auf Host-Umgebungsvariablen verweisen – niemals auf festgelegte Werte, niemals

„geheime Dateien.

JWT_SECRET=secret, SESSION_SECRET=keyboard cat, APP_KEY=changeme, ENCRYPTION_KEY=1234567890abcdef5. Verwenden schwacher Platzhalter-Geheimnisse, die in die Produktion gelangen

. Diese beginnen als Entwicklung-Platzhalter und werden manchmal nie ersetzt. Angriffspersonen, die JWT-Unterschriften durchbrüten, probieren diese Strings aktiv – sie sind in Wortlisten enthalten, weil sie in GitHub-Suchen auftauchen. HS256 Ein JWT, das mit und einem schwachen Geheimnis signiert wurde, kann offline mit Werkzeugen wiec-jwt-cracker

gebrochen werden. Ein abgefangener gültiger Token ist ausreichend, um das Geheimnis zu knacken und beliebige Tokens zu erstellen. Umgebungsgeheimnisgenerator Geheimnisse sollten kryptografisch zufällig sein und mindestens 32 Bytes lang sein. Erstellen Sie sie vor dem Einsatz – die

auf IO Tools erzeugt für gängige .env-Geheimnisse (JWT-Schlüssel, Sitzungsschlüssel, API-Schlüssel) korrekt zufällige Werte ohne jegliche Konfiguration. Legen Sie sie von Anfang an fest – verwenden Sie keine Platzhalter und planen Sie nicht, sie „vor der Produktion zu beheben“.

6. Framework-Umgebungsvariablenkonventionen, die Geheimnisse dem Client offenbaren

• Verschiedene beliebte Frameworks verwenden Variablenpräfixe, um den Unterschied zwischen Client- und Server-Verfügbarkeit zu bestimmen. Wenn dies falsch erfolgt, werden Geheimnisse im JavaScript-Bundle an jeden Browser übermittelt, der Ihre App lädt – im Klartext. Nur NEXT_PUBLIC_Next.js: getServerSideProps -präfixierte Variablen werden clientseitig eingebunden. Doch Server-Geheimnisse werden bei der Übertragung über props props – jedes zurückgegebene Wert in
• wird in die HTML-Seite serialisiert und ist in der Quelle lesbar. Vite: VITE_ Variablen mit Präfix VITE_DATABASE_URL werden in Client-JavaScript eingebunden. Die Verwendung von
• „für Komfort“ ist ein Fehler, den Entwickler tatsächlich machen. Alle REACT_APP_ Create React App:

Variablen landen in der Client-Bundle, ohne Ausnahme. Es gibt kein Server-Runtime-Modul von CRA – alles, was geladen wird, geht in den Browser.

grep -r "sk_live_" ./dist
grep -r "sk_live_" ./.next/static

Prüfen Sie nach dem Build, indem Sie das Ausgabeverzeichnis auf bekannte Geheimnisse suchen:

Wenn Ergebnisse zurückgegeben werden, sind diese Geheimnisse in jeder Browser-Tabelle vorhanden. Drehen Sie sie sofort und überprüfen Sie, was sonst noch eingebunden wurde.

Ein Verhalten, das von Anfang an aufgebaut werden sollte .gitignore Bevor jede Datei erstellt wird, die Geheimnisse enthält, erstellen Sie .gitignore und .env.example zuerst – nicht als Nachdenklichkeit. Der erste Commit in jedem neuen Repository sollte .gitignore Generator mit Platzhalterwerten sein. Die

erzeugt innerhalb einer Minute ein vollständiges, framework-spezifisches .gitignore-Datei.

Das könnte Ihnen auch gefallen