Das Support-Ticket kommt mit einem Screenshot: „CORS blockiert unsere API“. Der Frontend-Entwickler besteht darauf, dass das Backend „CORS als * öffnet“. Gleichzeitig funktioniert Curl ohne Origin-Header einwandfrei. Die Verwirrung kostet Tage, weil wir CORS als Serversperre behandeln – obwohl es sich um eine Browserrichtlinie handelt, die steuert, wer die JavaScript-Antwort lesen kann.
CORS schützt Ihre API nicht vor direkten Angriffen: Curl, Postman, Serverskripte und native mobile Anwendungen ignorieren CORS. Die Authentifizierung (JWT, Sitzung, mTLS) bleibt unerlässlich. CORS beantwortet eine bestimmte Frage: Hat „https://app.example.com“ das Recht, die JSON-Antwort seinem JavaScript zur Verfügung zu stellen?
Wiederkehrende Vorfälle sind darauf zurückzuführen, dass der OPTIONS-Preflight 401 zurückgibt, das mit Cookies inkompatible „*“ oder doppelte CORS-Header zwischen Nginx und dem Framework. So strukturieren Sie eine klare Richtlinie, ohne die Tür zum gesamten Web zu öffnen.
Preflight-OPTIONEN und -Methoden
„Nicht einfache“ Anfragen (JSON POST, benutzerdefinierte Header, PUT/DELETE) lösen einen Preflight OPTIONS aus. Der Browser sendet „Origin“, „Access-Control-Request-Method“, manchmal „Access-Control-Request-Header“. Der Server muss 204/200 mit CORS-Headern vor der eigentlichen Anfrage antworten.
Klassischer Fehler: Authentifizierungs-Middleware behandelt OPTIONEN als POST und gibt 401 zurück. Browser zeigt undurchsichtigen CORS-Fehler an – Entwickler gibt CORS die Schuld, Ursache ist Authentifizierung.
Schließen Sie OPTIONS von der Authentifizierungskontrolle auf öffentlichen API-Routen aus. Testen Sie mit:
„Bash curl -X OPTIONS -H "Ursprung: https://app.example.com" \ -H „Access-Control-Request-Method: POST“ \ -i https://api.example.com/v1/resource
## Herkunft, Referenzen und variieren
| Szenario | Zugriffskontrolle-Zulassen-Ursprung | Anmeldeinformationen |
| --- | --- | --- |
| Öffentliche, cookielose API | genaue Herkunft oder Liste | falsch |
| SPA mit Cookie-Sitzung | genaue Herkunft auf der Whitelist | true + Allow-Credentials |
| „*“ mit Keksen | **verboten** durch Spezifikation | Browserfehler |
Geben Sie mit „Access-Control-Allow-Credentials: true“ den **genauen Ursprung** der Anfrage zurück, wenn diese in Ihrer Whitelist steht – niemals „*“.
Fügen Sie „Vary: Origin“ zu dynamischen CORS-Antworten hinzu, um zu verhindern, dass ein CDN den falschen Ursprung im Cache bereitstellt.
## Nur eine Ebene gibt die Header aus
nginx **und** Express (oder Laravel, Django), die beide „Access-Control-Allow-Origin“ hinzufügen, erzeugen doppelte Header – einige Browser scheitern zeitweise, die schlimmste Art von Produktionsfehler.
Wählen Sie: CORS am Edge (Nginx/API-Gateway) **oder** in der Anwendung – nicht beides. Dokument in der ADR-Architektur.
Jährliches Audit: grep config nginx + Middleware-Code – eine einzige Quelle der Wahrheit.
## CORS ≠ API-Sicherheit
Ein Angreifer fälscht eine Anfrage von seinem Server ohne Origin-Browser – CORS gilt nicht. Ratenbegrenzung, Authentifizierung, Validierungseingabe und WAF bleiben weiterhin erforderlich.
Kurzes internes Dokument: „Native mobile Apps brauchen kein CORS“ – reduziert falsch positive Tickets im Backend.
OpenAPI: Autorisierte Ursprünge nach Umgebung auflisten und Beispiel für Curl-Preflight-Kopieren und Einfügen für Partner.
## Testen und Beobachtbarkeit
Partner-Postman-Sammlung in CI verwaltet – CORS-Regression vor der Zusammenführung erkannt.
Metriken: OPTIONS-Verhältnis 204 vs. 401, unbekannte Herkunft abgelehnt (aggregiertes Protokoll ohne PII).
Im Falle eines Vorfalls: Zuerst im Curl-Preflight reproduzieren, dann Browser mit deaktiviertem Cache – vermeidet falsche Hinweise Chrome-Erweiterung.
## Gateway-Überprüfung
Einschichtige CORS-Header für die jährliche Prüfung – doppelte Nginx- und App-Fehler bei Browsern.
OPTIONS sollte schnell reagieren – Timeout sieht aus wie CORS, ist aber serverlangsam.
Native mobile Apps benötigen kein CORS – internes Dokument.
## Betriebsüberwachung
Die dokumentierte CORS OpenAPI reduziert Support-Tickets für Partner – eine rentable Investition. Beispiel für Curl-Preflight-Kopieren und Einfügen pro Umgebung. Die Partner-Postman-Sammlung hat CI beibehalten – CORS-Regression wurde vor der Zusammenführung abgefangen. Dokumentieren Sie die Lücken zwischen dem Versprechen des Hosting-Anbieters und der Messung vor Ort in der vierteljährlichen Überprüfung.
## Vierteljährliche Fortsetzung
Die dokumentierte CORS OpenAPI reduziert Support-Tickets für Partner – eine rentable Investition. Beispiel für Curl-Preflight-Kopieren und Einfügen pro Umgebung. Die Partner-Postman-Sammlung hat CI beibehalten – CORS-Regression wurde vor der Zusammenführung abgefangen. Dokumentieren Sie die Lücken zwischen dem Versprechen des Hosting-Anbieters und der Messung vor Ort in der vierteljährlichen Überprüfung.
:::Hinweis
**Denken Sie daran.** CORS informiert den Browser; Auth schützt die API; OPTIONEN außerhalb der Authentifizierung; eine einzelne Header-Schicht; genaue Herkunft mit Referenzen.
:::
:::Höhepunkt
**Das Öffnen von CORS in * mit Cookies „schaltet“ nichts frei – die Spezifikation verbietet es und Curl hat CORS bereits umgangen.**
:::
## Entscheide dich und gehe ohne blinden Fleck voran
1. **Preflight-Curl reproduzieren** – OPTIONEN mit Origin und Access-Control-Request-Method, bevor Sie Nginx aufrufen.
2. **Explizite Ursprünge auf die Whitelist setzen** – niemals willkürlich widerspiegeln; „Vary: Origin“ bei CDN.
3. **Authentifizierung bei OPTIONEN überspringen** – dedizierte Middleware; 401 vor dem Flug = klassisches Ticket.
4. **Partner-Integrationskit** – Origin genau, Anmeldeinformationen, Abrufbeispiel, 401 vs. CORS-Browser.
5. **Unabhängige API-Authentifizierung** – JWT, Ratenbegrenzung, CSRF bei Cookies; CORS ist nicht die Serversperre.
Domainübergreifende API: [Vergleich](/de/vergleich/), [Verzeichnis](/de/verzeichnis/), [blog](/de/blog/) Backend.
## Häufig gestellte Fragen
### Schützt CORS die API vor Angriffen?
Nein: Es informiert den Browser darüber, welche Ursprünge die Antwort lesen können. Curl-, native Mobil- und Serverskripte ignorieren CORS – die API-Authentifizierung bleibt unerlässlich.
### Warum schlägt „*“ mit Cookies fehl?
Die Spezifikation verbietet „Access-Control-Allow-Origin: *“, wenn „Access-Control-Allow-Credentials: true“ lautet. Sie müssen den genauen Ursprung aus einer Whitelist zurückgeben.
### Was tun, wenn OPTIONS 401 zurückgibt?
Authentifizierungs-Middleware blockiert Preflight. Schließen Sie OPTIONS von der Authentifizierungskontrolle aus – eine häufige Ursache für „Broken CORS“-Tickets.
### Wie teste ich ohne Browser?
Reproduzieren Sie mit curl -X OPTIONS -H Origin:https://app.example.com -H 'Access-Control-Request-Method: POST' auf der API-URL.
---
Dokumentieren Sie autorisierte Ursprünge beim Partner-Onboarding – weniger Notfalleinsätze am Freitagabend.