CORS

CORS (Cross-Origin Resource Sharing) ist der Browsermechanismus, der steuert, wann JavaScript einer Herkunft Antworten einer anderen lesen darf. Standardmäßig blockieren Browser herkunftsübergreifende XHR-/fetch-Antworten – CORS-Header vom Server schalten den kontrollierten Zugriff frei.

Die zwei wichtigsten Antwort-Header:

• Access-Control-Allow-Origin: welche Herkünfte die Antwort lesen dürfen. Entweder eine bestimmte Herkunft oder * (beliebig).
• Access-Control-Allow-Credentials: ob Cookies bei herkunftsübergreifenden Anfragen mitgesendet werden dürfen. true erfordert eine konkrete Herkunft, nicht *.

Bei Anfragen, die nicht „einfach“ sind (eigene Header, andere Methoden als GET/POST, JSON-Bodies), sendet der Browser zunächst eine Preflight-OPTIONS-Anfrage, um zu prüfen, was erlaubt ist. Der Server antwortet mit Access-Control-Allow-Methods und Access-Control-Allow-Headers; die eigentliche Anfrage wird nur ausgelöst, wenn der Preflight erfolgreich war.

Häufige Missverständnisse: CORS ist kein serverseitiger Sicherheitsmechanismus – es ist eine vom Browser durchgesetzte Einschränkung, die Nutzer davor schützt, dass eine Website in ihrem Namen Daten einer anderen Website liest. Server können herkunftsübergreifende Anfragen weiterhin empfangen und verarbeiten; CORS steuert lediglich, ob der Browser die Antwort an das aufrufende JavaScript zurückgibt.

Was „Herkunft“ genau bedeutet: das Tupel (Schema, Host, Port). http://example.com und https://example.com sind verschiedene Herkünfte (anderes Schema). https://api.example.com und https://example.com sind verschiedene Herkünfte (andere Subdomain). https://example.com:8080 und https://example.com sind verschiedene Herkünfte (anderer Port). Dies ist die Same-Origin-Policy, auf die CORS Ausnahmen aufsetzt. Der Internet Explorer ignorierte den Port-Teil – eine Eigenheit, die jahrelang browserübergreifende Fehler verursachte, bis die Abschaltung des IE die Frage erübrigte.

Häufige Stolperfallen in der Produktion: Das Wildcard Access-Control-Allow-Origin: * blockiert laut Spezifikation Anmeldedaten; wenn Sie Cookies bei einer herkunftsübergreifenden Anfrage benötigen, müssen Sie den Origin der Anfrage konkret zurückspiegeln. Das Hinzufügen eines Authorization-Headers stuft die Anfrage von „einfach“ auf „preflight-pflichtig“ hoch und verdoppelt die Roundtrips – das Zwischenspeichern des Preflights über Access-Control-Max-Age (bis zu 7200 Sekunden in Chrome, 600 in Firefox) ist die übliche Gegenmaßnahme. Schließlich ist der CORS-Fehler in der DevTools-Konsole tatsächlich eine Entscheidung des Browsers – die Server-Logs zeigen, dass die Anfrage das Backend erreicht und normal verarbeitet wurde; die Antwort wurde lediglich clientseitig verworfen. Quelle: WHATWG Fetch — HTTP-CORS Protocol.

Durchgerechnetes Beispiel: ein preflight-pflichtiger JSON-POST

Eine SPA unter https://app.example.com sendet per POST JSON mit einem Bearer-Token an https://api.example.com/v1/orders. Da die Anfrage Content-Type: application/json und einen Authorization-Header verwendet, ist sie nicht einfach. Der Browser sendet zunächst OPTIONS /v1/orders mit Origin: https://app.example.com, Access-Control-Request-Method: POST und Access-Control-Request-Headers: authorization,content-type. Der Server antwortet mit 204 sowie Access-Control-Allow-Origin: https://app.example.com, Access-Control-Allow-Methods: POST, Access-Control-Allow-Headers: authorization,content-type und Access-Control-Max-Age: 600. Erst dann wird der eigentliche POST ausgelöst. Das Setzen von Max-Age: 600 erspart den Preflight für die nächsten 10 Minuten und eliminiert bei jedem weiteren Aufruf einen Roundtrip – messbar als Einsparung von 50–100 ms auf transatlantischen Verbindungen.

Wenn CORS nicht ausreicht

CORS schützt Nutzer vor herkunftsübergreifenden Lesezugriffen; es schützt Server nicht vor unerwünschten Anfragen. Zustandsändernde Endpunkte brauchen weiterhin CSRF-Token oder SameSite-Cookies, und die Authentifizierung erfordert nach wie vor eine ordentliche serverseitige Token-Validierung. Eine öffentliche API hinter Access-Control-Allow-Origin: * ist von jedem öffentlich aufrufbar – CORS hat dem Browser nur ermöglicht, diese Tatsache sichtbar zu machen. Für tiefere architektonische Hintergründe siehe MDNs CORS-Referenz, die die WHATWG-Spezifikation mit praktischen Beispielen widerspiegelt.