Was ist CORS?

Was passiert, wenn man Daten auf einer Website von unterschiedlichen Servern lädt?

Genau, der Besucher der Seite bekommt im Browser ein durchgestrichenes Schloss angezeigt.
 

Das steht nämlich für sogenannten „Mixed Content“, also zum Beispiel einer Mischung aus Inhalten mit Verschlüsselung und ohne, aber auch wenn Inhalte von einem ganz anderen Webserver geladen werden.
 

Ihr erhaltet dann, je nach Browser, zusätzlich eine Fehlermeldung, denn es ist untersagt, Inhalte von einem fremden Webserver zu laden. Alle Inhalte einer Seite sollten grundsätzlich nur von einem Webserver stammen. Das nennt man Same-Origin-Policy (SOP), frei übersetzt: Das Gesetz der gleichen Herkunft.

Im Endeffekt möchte man dadurch verhindern, dass ohne Wissen des Seitenbesuchers fremde Inhalte nachgeladen werden. Denn: JavaScript und CSS können selbst Inhalte von externen Servern nachladen, welche durchaus schädlich sein können.

Die SOP besagt, dass Host, Port und Protokoll einem einzigen Server entsprechen müssen. Wenn man also auf seiner Seite „https://example.com“ einen Inhalt von „http://example.edu“ nachladen will, verbietet die SOP dies.
Aus genau diesem Grund bekommt der Besucher beim Aufrufen einer Seite, die externe Inhalte ohne CORS nachlädt, das durchgestrichene Schloss und eine Sicherheitswarnung angezeigt.

Doch es gibt auch Sonderfälle, die der Ausnahme bedürfen, Inhalte von einem anderen Webserver zu holen. Genau hierfür gibt es CORS. Ein häufiger Anwendungsfall ist das Nachladen von Webschriftarten von einem externen Server. Das ist weder Schadcode, noch sonst für den Besucher der Seite ein Risiko.

Zwei Server können eine Art Abkommen treffen, sich gegenseitig zu vertrauen und so diese Inhalte eben doch zuzulassen. Wichtig für das Verständnis des Verfahrens ist hier, dass man hiermit nicht einfach alles freigeben kann.
Der abgefragte Server muss die angeforderten Inhalte dem anfragenden Server explizit freigeben. Im Header der HTTP-Antwort ist genau beschrieben, welche Server Daten nachladen und zur Verfügung stellen dürfen.

Bestimmte Server vergeben auch Wildcards (*), also eine generelle Erlaubnis zum Abruf. Sinnvoll ist dies nur für die Bereitstellung von Schriftarten, zum Beispiel, um festzulegen, welche Fonts der Allgemeinheit zur Verfügung stehen sollen.

Im Sinne der Same-Origin-Policy bestehen bei einer Serververbindung die Angaben zur Herkunft aus drei Elementen: Host, Port und Protokoll und verbieten demnach, wie oben geschildert, das externe Inhalte nachgeladen werden.

Bei einem „Cross-Origin-Request“ handelt es sich grundlegend um einen HTTP-Request. Bestimmte HTTP-Requests stellen prinzipiell kein Problem dar, zum Beispiel solche, durch welche Daten nicht verändern werden können, wie GET und HEAD.

Es gibt aber auch Abfragen, welche Daten übergeben und ändern können, so bei PATCH, PUT oder DELETE: Genau aus diesem Grund muss hier „Cross-Origin Resource Sharing“ aktiviert werden. CORS kann also auch Angaben darüber enthalten, welche HTTP-Requests durch die Quelle erlaubt sind.

Bei sicherheitsrelevanten HTTP-Methoden sendet der Client zunächst eine „Preflight-Anfrage“.
In dieser gibt man lediglich an, welche HTTP-Methode man als nächstes an den Server richten will und erfragt, ob die Anfrage als sicher gewertet wird. Dafür verwendet man den „OPTIONS-Header“. Erst wenn der Server eine positive Rückantwort gibt, kann dann die eigentliche Anfrage gestellt werden.

Es gibt viele verschiedene CORS-Header, der wichtigste ist wohl „Access-Control-Allow-Origin“, um festzulegen welcher andere Host auf diesen zugreifen darf. Es kann eine konkrete Adresse angegeben oder, wie bereits erwähnt, eine Wildcard vergeben werden. Achtung: Mit einer Wildcard wird der Zugriff aus jedweder Quelle gestattet!

In der .htaccess kann ein CORS-Header so aussehen:

Dies sind die weiteren CORS-Header:

• Access-Control-Allow-Credentials: Sind Anfragen auch dann erlaubt, wenn der Credentials-Flag auf „true“ gesetzt ist?
• Access-Control-Allow-Headers: Welche Header dürfen verwendet werden?
• Access-Control-Allow-Methods: Welche HTTP-Request-Methoden sind erlaubt?
• Access-Control-Expose-Headers: Welche Header dürfen angezeigt werden?
• Access-Control-Max-Age: Wie alt darf die Preflight-Anfrage sein, bevor sie ihre Gültigkeit verliert?
• Access-Control-Request-Headers: Welcher HTTP-Header ist in der Preflight-Anfrage angegeben?
• Access-Control-Request-Method: Welche HTTP-Methode ist in der Preflight-Anfrage angegeben?
• Origin: Was ist die Quelle der Anfrage?

CORS bietet eine Lösung, um die Same-Origin-Policy zu umgehen. Dies kann in einigen Fällen sinnvoll sein und findet im Internet auch regen Anklang.
Es besteht allerdings das hohe Risiko, dass Webseitenbetreiber aus Gründen der Bequemlichkeit nur Wildcards verwenden, was nicht zu empfehlen ist.

Wenn deine Website auf externe Inhalte zugreifen muss, und dies über einen CORS-Header ohne Wildcard realisiert wird, ist dies eine praktikable Lösung.