CORS (Cross-Origin Resource Sharing)
CORS ist ein Browser-Mechanismus, der regelt, ob eine Website auf Ressourcen einer anderen Herkunft (Domain) zugreifen darf – standardmäßig ist solcher herkunfts-übergreifender Zugriff aus Sicherheitsgründen gesperrt.
CORS wird häufig mit der Content-Security-Policy verwechselt – beide steuern Sicherheits-Grenzen zwischen Herkünften, aber in entgegengesetzter Richtung.
In einfachen Worten
Browser folgen einer Grundregel namens Same-Origin-Policy: Eine Seite darf Daten nur von ihrer eigenen Herkunft – also derselben Kombination aus Protokoll, Domain und Port – ungehindert abrufen. CORS ist die kontrollierte Ausnahme davon. Soll eine API unter einer anderen Domain von einer Seite abgefragt werden, muss der antwortende Server per Header (Access-Control-Allow-Origin) ausdrücklich erlauben, welche fremden Herkünfte zugreifen dürfen. Bei bestimmten Anfragen schickt der Browser zuvor eine Vorab-Anfrage (Preflight), um die Erlaubnis zu klären. Wichtig ist die Abgrenzung zur Content-Security-Policy: CORS regelt, ob fremde Seiten auf die eigenen Ressourcen zugreifen dürfen; die Content-Security-Policy regelt umgekehrt, welche fremden Quellen die eigene Seite laden darf. Beide arbeiten an der Herkunfts-Grenze, aber aus entgegengesetzten Richtungen.
Wozu brauche ich das?
Überall relevant, wo eine Website Daten von einer anderen Domain abruft – eine ausgelagerte API, ein Dienst unter einer eigenen Unter-Domain, eine Schnittstelle eines Partners. Wer Schnittstellen bereitstellt, muss über CORS bewusst entscheiden, welche fremden Herkünfte zugreifen dürfen, statt pauschal alle zuzulassen.
Beispiel aus der Praxis
Eine Website unter der Haupt-Domain ruft Daten von einer API unter einer eigenen Unter-Domain ab. Ohne passende CORS-Freigabe blockiert der Browser die Antwort, obwohl beide zum selben Unternehmen gehören – sichtbar als Fehler in der Entwickler-Konsole. Erst wenn der Server die Haupt-Domain im Access-Control-Allow-Origin-Header ausdrücklich erlaubt, lässt der Browser den Zugriff zu. Ein pauschales Erlauben aller Herkünfte würde funktionieren, öffnet die Schnittstelle aber unnötig weit. Auch ein Webhook, der Daten an eine andere Domain sendet, berührt dieselbe Herkunfts-Grenze.
Wirtschaftlicher Nutzen
CORS richtig zu konfigurieren entscheidet darüber, ob verteilte Anwendungen – Website plus ausgelagerte Dienste – überhaupt zusammenarbeiten. Eine zu enge Einstellung legt Funktionen lahm, eine zu weite öffnet Schnittstellen für fremden Zugriff. Der wirtschaftliche Wert liegt in einer Konfiguration, die genau die benötigten Herkünfte erlaubt – funktionsfähig und sparsam zugleich. Fehlkonfigurationen sind ein häufiger, vermeidbarer Grund für scheinbar unerklärliche Fehler in der Entwicklung. Wie eine Auslieferung über HTTPS ist die richtige Konfiguration Voraussetzung für reibungslosen Betrieb.
Typische Fehler
- Pauschal alle Herkünfte erlauben, weil es „erstmal funktioniert" – die Schnittstelle steht damit jeder fremden Seite offen.
- CORS mit der Content-Security-Policy verwechseln und am falschen Ende nach dem Fehler suchen.
- Die Vorab-Anfrage (Preflight) übersehen und nur die eigentliche Anfrage konfigurieren.
- CORS für einen Mechanismus halten, der die Schnittstelle absichert – er regelt nur den Browser-Zugriff, nicht die Authentifizierung.
Worauf achten?
- Nur die tatsächlich benötigten Herkünfte freigeben, nicht pauschal alle.
- Daran denken, dass CORS und Content-Security-Policy entgegengesetzte Richtungen regeln.
- Die Vorab-Anfrage (Preflight) für die verwendeten Methoden und Header mit konfigurieren.
- CORS nicht als Ersatz für echte Zugriffs-Kontrolle der API verstehen – Authentifizierung bleibt nötig.
Häufig gestellte Fragen
Was ist CORS?
Ein Browser-Mechanismus, der den herkunfts-übergreifenden Zugriff auf Ressourcen regelt. Standardmäßig sperrt die Same-Origin-Policy solche Zugriffe; CORS ist die kontrollierte Ausnahme, bei der ein Server fremde Herkünfte ausdrücklich erlaubt.
Was ist der Unterschied zwischen CORS und CSP?
CORS regelt, ob fremde Seiten auf Ihre Ressourcen zugreifen dürfen. Die Content-Security-Policy regelt umgekehrt, welche fremden Quellen Ihre Seite laden darf. Beide arbeiten an der Herkunfts-Grenze, aber in entgegengesetzte Richtungen.
Was ist eine Preflight-Anfrage?
Bei bestimmten Anfragen schickt der Browser vorab eine separate Anfrage an den Server, um zu klären, ob der eigentliche Zugriff erlaubt ist. Erst nach positiver Antwort folgt die eigentliche Anfrage.
Ist CORS ein Schutz für meine API?
Nur eingeschränkt. CORS steuert den Zugriff aus dem Browser heraus, ersetzt aber keine Authentifizierung. Eine API braucht zusätzlich eine echte Zugriffs-Kontrolle, denn CORS lässt sich außerhalb des Browsers umgehen.