Was ist ein CORS-Fehler und wen schützt er wirklich? (Same-Origin Policy & Preflight OPTIONS)

Fast jeder Entwickler kennt diese rote Fehlermeldung in der Browser-Konsole:

Access to fetch at 'https://api.example.com/v1/transfer' from origin 'http://localhost:3000' has been blocked by CORS policy

Doch warum funktioniert derselbe API-Aufruf in Postman oder cURL ohne Probleme, wird aber im Browser blockiert? Weil CORS (Cross-Origin Resource Sharing) keine Server-Firewall ist, sondern ein Sicherheitsmechanismus des Browsers zum Schutz des Nutzers.

1. Warum gibt es die Same-Origin Policy (SOP)?

Ohne die Same-Origin Policy könnte eine bösartige Webseite (https://evil.com), die Sie in einem zweiten Tab öffnen, im Hintergrund Anfragen an Ihre Bank (https://bank.com) senden und dank Ihrer gespeicherten Sitzungscookies Ihre privaten Kontodaten auslesen. Die SOP verhindert, dass fremde Domains Antworten anderer Ursprünge (Origins) lesen dürfen.

2. Gezielte Freigabe über CORS-Header

Wenn Ihr Frontend (https://app.firma.de) auf Ihre API (https://api.firma.de) zugreifen muss, teilt der Server dem Browser über eine explizite Whitelist mit, dass dieser Ursprung vertrauenswürdig ist:

Access-Control-Allow-Origin: https://app.firma.de
Access-Control-Allow-Credentials: true

3. Versteckte Preflight-OPTIONS-Anfragen mit Access-Control-Max-Age optimieren

Bei JSON-Payloads oder Methoden wie PUT und DELETE sendet der Browser vorab eine OPTIONS-Anfrage (Preflight), um die Berechtigung zu prüfen. Damit nicht vor jedem einzelnen API-Aufruf ein zusätzlicher Netzwerk-Roundtrip stattfindet, sollten Sie die Antwort im Browser-Cache speichern lassen:

Access-Control-Max-Age: 86400

Dadurch merkt sich der Browser die CORS-Freigabe für bis zu 24 Stunden und spart unnötige OPTIONS-Anfragen komplett ein.