Umgebungsvariablen-Audit

Das Problem

Probleme mit Umgebungsvariablen sind die stillen Killer von Deployments. Eine fehlende Variable laesst die App zur Laufzeit abstuerzen, eine ungenutzte blaеht die Konfiguration auf, und eine exponierte in einer committeten .env-Datei ist ein Sicherheitsvorfall. Die meisten Entwickler entdecken diese Probleme erst nach dem Deployment — wenn es bereits zu spaet ist.

Der Prompt

Pruefe die Umgebungsvariablen in meinem Projekt. Ich liefere meine Konfigurationsdateien und Code-Referenzen. Identifiziere jedes Problem.

.ENV.EXAMPLE (oder .env.local):
[.env.example oder .env-Template hier einfuegen]

CODE, DER UMGEBUNGSVARIABLEN REFERENZIERT:
[relevante Code-Dateien einfuegen — oder beschreiben: "Next.js-App mit Prisma und Stripe"]

DEPLOYMENT-PLATTFORM: [z.B. Vercel, AWS, Docker, Netlify]

Pruefe auf folgende Probleme:

1. **Fehlende Variablen** — Im Code referenziert, aber nicht in .env.example
2. **Ungenutzte Variablen** — In .env definiert, aber nie im Code referenziert
3. **Exponierte Secrets** — Sensible Werte, die committet oder clientseitig sichtbar sein koennten
4. **Client-Side-Leaks** — Server-only Secrets im Browser zugaenglich (z.B. fehlendes NEXT_PUBLIC_-Prefix-Handling)
5. **Riskante Standardwerte** — Fallback-Werte, die in Produktion zu stillen Fehlern fuehren
6. **Namensinkonsistenzen** — Gemischte Konventionen (camelCase vs SCREAMING_SNAKE)
7. **Fehlende Validierung** — Kein Startup-Check, ob erforderliche Variablen gesetzt sind

Fuer jedes Problem Schweregrad (Kritisch/Warnung/Info) und Loesung angeben.

Beispielausgabe

## Audit-Ergebnis: 4 Probleme gefunden

### KRITISCH: Secret clientseitig exponiert
`STRIPE_SECRET_KEY` wird in `src/lib/stripe.ts` verwendet, das von einer Client-Komponente importiert wird.
Loesung: Stripe-Initialisierung in ein Server-only Modul verschieben (z.B. `src/lib/stripe.server.ts`).

### KRITISCH: In Produktion fehlend
`REDIS_URL` wird in `src/lib/cache.ts` referenziert, aber nicht in .env.example gelistet.
Loesung: `REDIS_URL=` zur .env.example hinzufuegen und in der Deployment-Plattform setzen.

### WARNUNG: Ungenutzte Variable
`OLD_API_KEY` ist in .env definiert, wird aber nirgends im Code referenziert.
Loesung: Aus .env.example und allen Deployment-Konfigurationen entfernen.

### INFO: Keine Startup-Validierung
Loesung: Validierungscheck beim App-Start mit zod oder einer einfachen Assertion-Funktion hinzufuegen.

Wann verwenden

Dieses Audit vor jedem Deployment in eine neue Umgebung ausfuehren, nach dem Onboarding neuer Teammitglieder, die Variablen falsch konfigurieren koennten, oder als periodischer Sicherheitscheck. Besonders wertvoll beim Wechsel zwischen Hosting-Plattformen, wo Namenskonventionen fuer Umgebungsvariablen unterschiedlich sind.

Profi-Tipps

• Deployment-Konfiguration einbeziehen — vercel.json, docker-compose.yml oder CI-Konfiguration einfuegen, damit die KI abgleichen kann, welche Variablen tatsaechlich in jeder Umgebung gesetzt sind.
• Validierungsskript generieren lassen — nachfragen: “Generiere ein TypeScript-Umgebungsvalidierungsmodul mit zod, das alle erforderlichen Variablen beim Start prueft.”
• Automatisieren — die KI bitten, ein Skript zu generieren, das .env.example-Keys mit process.env-Referenzen im Code vergleicht.