Loading content
Cross-Origin Resource Sharing (CORS) ist ein browserseitiges Sicherheits- und Integrationsmodell, das regelt, welche fremden Ursprünge auf Ressourcen einer Webanwendung zugreifen dürfen. Es basiert auf standardisierten HTTP-Headern und definiert, wie Browser Anfragen erlauben oder blockieren. Die korrekte Konfiguration von Allow-Origin- und Credentials-Heade…
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Theoretisches Gebilde: erklärt einen Begriff, ein Prinzip oder ein Denkmodell.
Was Zusammenhänge ordnet, verbindet oder entscheidbar macht.
Cross-Origin Resource Sharing (CORS) ist ein browserseitiges Regelwerk für Anfragen zwischen unterschiedlichen Ursprüngen. Es legt über HTTP-Header fest, welche fremden Origins Antworten lesen dürfen und wann der Browser eine Anfrage vor der Ausführung prüft oder blockiert.
CORS entstand aus dem Spannungsfeld zwischen der Same-Origin-Policy und dem realen Web, in dem Seiten Ressourcen aus anderen Origins einbinden und abrufen müssen. Um kontrollierte Ausnahmen zu ermöglichen, wurde CORS als HTTP-Header-basiertes Verfahren standardisiert. Die W3C-Spezifikation beschreibt das Modell; der spätere Fetch-Standard ordnet es in das einheitliche Browser-Fetching ein.
Denk an CORS als Grenzkontrolle im Browser. Jede cross-origin Anfrage trägt ihren `Origin`-Absender mit. Der Server entscheidet mit Antwort-Headern, ob dieser Ursprung lesen darf. Bei einfachen Anfragen genügt diese Freigabe oft direkt; bei riskanteren Methoden fragt der Browser zuerst per `OPTIONS` nach. Nur wenn Herkunft, Methode, Header und gegebenenfalls `Credentials` zusammenpassen, sendet der Browser die eigentliche Anfrage.
Die Browser-Grundregel beschränkt das Lesen von Antworten auf denselben Ursprung, solange kein anderes Verfahren eine Ausnahme erlaubt.
Ein Origin ist die Kombination aus Schema, Host und Port und bildet die maßgebliche Vertrauensgrenze.
Bestimmte Anfragen dürfen ohne Vorprüfung gesendet werden, wenn Methode und Header in den erlaubten Standardrahmen fallen.
Vor manchen cross-origin Anfragen prüft der Browser mit einer `OPTIONS`-Anfrage, welche Methode und welche Header zulässig sind.
Dieser Antwort-Header nennt die erlaubten Origins oder `*` und entscheidet damit, wer die Antwort lesen darf.
Cookies, HTTP-Authentifizierung und Client-Zertifikate brauchen ausdrückliche Freigabe; mit `*` sind sie nicht kombinierbar.
CORS ist wichtig, wenn Web-Frontends Daten von einer getrennten API, aus einem anderen Subdomain-Setup oder von einem externen Dienst laden müssen. Es hilft bei kontrollierter Freigabe, behebt aber keine Authentifizierung, Autorisierung oder serverseitige Sicherheitsfehler. Fehlerhafte Header führen oft zu Blockaden, zu offener Freigabe oder zu Problemen mit Cookies und anderen Credentials.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.