Die Meldung No 'Access-Control-Allow-Origin' header bedeutet, dass der Browser eine Antwort wegen der Same-Origin-Policy nicht für JavaScript freigibt. Die dauerhafte Lösung liegt fast immer auf dem Server, der die angefragte Ressource ausliefert – nicht im Frontend-Code.

Was ist CORS?

Cross-Origin Resource Sharing (CORS) ist ein HTTP-basierter Mechanismus. Er erlaubt einem Server festzulegen, welche anderen Ursprünge seine Antworten im Browser lesen dürfen. Ein Ursprung besteht aus Protokoll, Hostname und Port. Daher sind beispielsweise https://www.example.de und https://api.example.de unterschiedliche Origins.

Zuerst die tatsächliche Ursache prüfen

  1. In den Entwicklerwerkzeugen den fehlgeschlagenen Request öffnen.
  2. Request-URL, Origin-Header, Statuscode und Antwort-Header prüfen.
  3. Kontrollieren, ob eine Weiterleitung, ein 404/500-Fehler oder Mixed Content vorliegt.
  4. Bei einer Preflight-Anfrage die Antwort auf OPTIONS untersuchen.
  5. CDN- und Proxy-Caches nach einer Konfigurationsänderung leeren.

Ein Wechsel von HTTP auf HTTPS kann zwar ein verwandtes Mixed-Content-Problem lösen, ersetzt aber keine korrekte CORS-Konfiguration. Beide Fehler sollten getrennt diagnostiziert werden.

Öffentliche Ressource ohne Zugangsdaten

Nur wenn eine Ressource wirklich öffentlich von jeder Website gelesen werden darf und keine Cookies oder anderen Zugangsdaten benötigt, kann der Wildcard-Wert sinnvoll sein:

Access-Control-Allow-Origin: *

Verwenden Sie * nicht pauschal für private APIs, Benutzerkonten oder administrative Endpunkte.

Bestimmten Ursprung erlauben

Für einen klar definierten Client sollte der Server genau diesen Ursprung zurückgeben:

Access-Control-Allow-Origin: https://app.example.de
Vary: Origin

Apache-Konfiguration, beispielsweise in einem passenden VirtualHost oder – falls erlaubt – in .htaccess:

<IfModule mod_headers.c>
  Header always set Access-Control-Allow-Origin "https://app.example.de"
  Header always merge Vary "Origin"
</IfModule>

Nginx-Beispiel:

add_header Access-Control-Allow-Origin "https://app.example.de" always;
add_header Vary "Origin" always;

Mehrere erlaubte Origins

Der Header unterstützt nicht einfach eine durch Kommas getrennte Liste. Bei mehreren erlaubten Ursprüngen muss die Anwendung den eingehenden Origin-Wert mit einer festen Allowlist vergleichen und nur bei einem exakten Treffer zurückgeben. Den Origin-Header ungeprüft zu spiegeln wäre unsicher.

Requests mit Cookies oder Anmeldung

Werden Cookies oder andere Credentials übertragen, ist Access-Control-Allow-Origin: * nicht zulässig. Stattdessen muss ein konkreter Ursprung genannt und zusätzlich folgender Header gesendet werden:

Access-Control-Allow-Credentials: true

Auch der Client muss Credentials ausdrücklich mitsenden, etwa mit fetch(url, { credentials: "include" }). Beachten Sie zusätzlich Cookie-Einstellungen wie SameSite, sichere HTTPS-Verbindungen sowie CSRF-Schutz.

Preflight-Anfragen korrekt beantworten

Bei bestimmten Methoden oder Headern sendet der Browser zunächst eine OPTIONS-Anfrage. Der Server muss diese Route erreichbar machen und die tatsächlich benötigten Methoden und Header erlauben – möglichst eng begrenzt:

Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

Was nicht funktioniert

  • mode: "no-cors" macht die Antwort für JavaScript undurchsichtig und ist kein allgemeiner CORS-Fix.
  • Browser-Sicherheitsfunktionen lokal zu deaktivieren löst das Problem nicht für reale Besucher.
  • Ein fremder Server ohne passende Header kann nicht allein durch Code auf Ihrer Website freigeschaltet werden.
  • Ein offener CORS-Proxy sollte nicht als dauerhafte Lösung für sensible Daten dienen.

Nach der Änderung sollten normale Requests und Preflight-Anfragen erneut getestet werden. Prüfen Sie dabei sowohl erlaubte als auch ausdrücklich nicht erlaubte Origins.