CORS-Konfigurator

Das Problem

Die CORS-Konfiguration ist der Punkt, an dem Sicherheit auf Entwicklerfrust trifft. Zu locker mit Access-Control-Allow-Origin: * eingestellt, laedt sie zu Cross-Site-Datendiebstahl ein. Zu streng, und das eigene Frontend erreicht die API nicht. Entwickler greifen haeufig zu “alles erlauben”, um CORS-Fehler in der Entwicklung zu beheben, und vergessen dann, es fuer die Produktion zu verschaerfen. Preflight-Mechanismus, Credential-Handling und Header-Exposure-Regeln fuegen Komplexitaetsschichten hinzu, die zu Fehlkonfigurationen fuehren.

Der Prompt

Du bist ein Web-Sicherheitsingenieur mit Spezialisierung auf CORS-Konfiguration. Pruefe mein CORS-Setup und behebe Sicherheitsprobleme oder Fehlkonfigurationen.

ARCHITEKTUR:
- Frontend-Origin(s): [z.B. https://app.example.com, http://localhost:3000]
- API-Origin: [z.B. https://api.example.com]
- Auth-Methode: [z.B. Cookies, JWT im Authorization-Header, API-Key]
- Framework: [z.B. Express/cors, FastAPI, Django, Next.js, nginx]

AKTUELLE CORS-CONFIG:
[CORS-Middleware-Config, nginx-Header oder Server-Einstellungen einfuegen]

Bewerten:
1. **Origin-Whitelist**: Ist sie spezifisch oder gefaehrlich breit (Wildcard)?
2. **Credentials**: Wird Access-Control-Allow-Credentials korrekt mit spezifischen Origins verwendet?
3. **Methoden**: Sind nur benoetigte HTTP-Methoden erlaubt?
4. **Header**: Sind exponierte/erlaubte Header minimiert?
5. **Preflight-Caching**: Ist Access-Control-Max-Age gesetzt, um OPTIONS-Requests zu reduzieren?
6. **Vary-Header**: Ist Vary: Origin fuer Caching-Kompatibilitaet gesetzt?

Bereitstellen:
- Sicherheitsbewertung der aktuellen Config (sicher/riskant/gefaehrlich)
- Korrigierte Konfiguration fuer mein spezifisches Framework
- Dev- vs. Produktions-CORS-Strategie
- Gaengige CORS-Fehler und ihre echten Loesungen (nicht einfach "alles erlauben")

Beispielausgabe

## CORS-Bewertung: GEFAEHRLICH

### Befund: Wildcard-Origin mit Credentials
`Access-Control-Allow-Origin: *` kombiniert mit `Access-Control-Allow-Credentials: true`
Risiko: Jede Website kann authentifizierte Requests an die API senden.
Loesung (Express):
app.use(cors({
  origin: ['https://app.example.com'],
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  maxAge: 86400
}));

Wann verwenden

CORS beim initialen API-Setup konfigurieren und ueberpruefen, wenn neue Frontend-Clients hinzugefuegt werden, in die Produktion gewechselt wird oder nach “CORS-Fehler”-Beschwerden von Entwicklern. Unverzichtbar, wenn die API mehrere Frontend-Domains bedient oder beim Uebergang von Same-Origin- zu Cross-Origin-Architektur.

Profi-Tipps

• Niemals Wildcard mit Credentials — Access-Control-Allow-Origin: * und credentials: true zusammen ist eine Sicherheitsverletzung auf Browser-Ebene. Spezifische Origins verwenden.
• Dev- und Prod-Configs trennen — Localhost-Origins nur in der Entwicklung erlauben, niemals in Produktions-CORS-Richtlinien.
• Preflight-Requests cachen — Access-Control-Max-Age: 86400 setzen, um redundante OPTIONS-Requests zu vermeiden, die die API verlangsamen.
• Vary: Origin verwenden — wenn der Server mit verschiedenen CORS-Headern pro Origin antwortet, verhindert der Vary-Header CDN-Caching-Probleme.