Ei­gent­lich strengs­tens verboten: Wer eine Website aufruft, der soll keine zu­sätz­li­chen Daten von fremden Servern laden! Doch es kann Ausnahmen geben. Wenn beide Website-Betreiber sich über die Zu­sam­men­ar­beit einig sind, spricht nichts gegen ein Abkommen. Das Cross-Origin Resource Sharing (CORS) regelt die Ko­ope­ra­ti­on. Wie funk­tio­niert das?

Wie funk­tio­niert CORS?

Die Same-Origin-Policy (SOP) verbietet beim Besuch einer Website das Nachladen von anderen Servern. Alle Daten sollen von der gleichen Quelle kommen, also dem gleichen Server ent­sprin­gen. Das ist eine Si­cher­heits­maß­nah­me, denn Ja­va­Script und CSS könne ohne das Wissen der Nutzer Inhalte von anderen Servern laden – auch schäd­li­che Inhalte. Ein solcher Zu­griffs­ver­such wird als Cross-Origin-Request be­zeich­net. Ist aber beiden Web­site­be­trei­bern der Da­ten­aus­tausch bekannt und von diesen auch gewünscht, kann man den Vorgang erlauben. Der an­ge­frag­te Server – also der, von dem Inhalte nach­ge­la­den werden sollen – erlaubt den Zugriff dann per Cross-Origin Resource Sharing.

Dies geschieht al­ler­dings immer nur für bestimmte Clients. Das heißt: CORS ist kein Freibrief für jegliche Cross-Origin-Requests. Statt­des­sen erlaubt der zweite Server dem ersten per HTTP-Header den ex­klu­si­ven Zugriff. In dem Kopf der HTTP-Antwort ist genau be­schrie­ben, welche Server die Daten nachladen und dem Nutzer schließ­lich zur Verfügung stellten dürfen. Nur durch die Ein­bin­dung von Wildcards ist eine generelle Erlaubnis zum Zugriff durch alle Clients erlaubt. Dies ist aber nur sinnvoll für Server, die solche In­for­ma­tio­nen anbieten, die für die All­ge­mein­heit zur Verfügung stehen sollen – Web-Schrift­ar­ten bei­spiels­wei­se.

Der Nutzer bekommt von dem Austausch der beiden be­tei­lig­ten Server im besten Fall nichts mit. Alle aktuellen Browser un­ter­stüt­zen CORS, und das Senden von Anfragen und Antworten geschieht beim Aufruf einer Website innerhalb kürzester Zeit im Hin­ter­grund.

Bild: Ablauf von CORS
Cross-Origin Resource Sharing Ablauf: CORS regelt den Zugriff auf Inhalte von fremden Servern.

Aufbau der CORS-Header

Im Sinne der Same-Origin-Policy bestehen bei einer Ser­ver­ver­bin­dung die Angaben zur Herkunft aus drei Elementen: Host, Port und Protokoll. Die Richt­li­nie verbietet demnach, dass im obigen Beispiel "https://example.com" auf "http://example.com" oder auf "https://example.org" zugreift. Im ersten Fall ist das Protokoll nicht das gleiche, im zweiten sind die beiden Host-Angaben nicht identisch.

Bei einem Cross-Origin-Request handelt es sich im Prinzip um einen HTTP-Request. Bestimmte Methoden stellen grund­sätz­lich keine Probleme dar. GET und HEAD können Daten nicht ändern und werden deshalb in der Regel nicht als Si­cher­heits­ri­si­ko wahr­ge­nom­men. Anders sieht es bei PATCH, PUT oder DELETE aus: Hiermit ist es möglich, schäd­li­che Eingriffe vor­zu­neh­men. Deshalb muss hierfür auch Cross-Origin Resource Sharing aktiviert werden. Demnach kann CORS nicht nur In­for­ma­tio­nen zum erlaubten Ursprung be­inhal­ten, sondern auch darüber, welche HTTP-Requests durch die Quelle erlaubt sind.

Handelt es sich um si­cher­heits­re­le­van­te HTTP-Methoden, sendet der Client zunächst eine Preflight-Anfrage. In dieser gibt man ei­gent­lich nur an, welche HTTP-Methode man als nächstes an den Server richten wird und erfragt, ob die Anfrage als sicher gewertet wird. Dafür verwendet man den OPTIONS-Header. Erst nach einer positiven Rück­ant­wort kann dann die ei­gent­li­che Anfrage gestellt werden.

Es gibt ver­schie­de­ne CORS-Header, die sich jeweils mit un­ter­schied­li­chen Aspekten aus­ein­an­der­set­zen. Genannt wurden schon die beiden wichtigen Header zur Be­stim­mung von sicheren Ur­sprün­gen und erlaubten Methoden. Aber es gibt noch weitere:

  • Access-Control-Allow-Origin: Welche Herkunft ist erlaubt?
  • Access-Control-Allow-Cre­den­ti­als: Sind Anfragen auch dann erlaubt, wenn der Cre­den­ti­als Mode auf include 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ül­tig­keit verliert?
  • Access-Control-Request-Headers: Welcher HTTP-Header ist in der Preflight-Anfrage angegeben?
  • Access-Control-Request-Method: Welcher HTTP-Methode ist in der Preflight-Anfrage angegeben?
  • Origin: Was ist die Quelle der Anfrage?

Der besondere Fokus liegt auf dem ersten Header. Dort spe­zi­fi­ziert der Server, welcher andere Host auf ihn zugreifen darf. Neben einer konkreten Adresse kann man dort auch eine Wildcard in Form eines Asterisks angeben. Damit erlaubt der Server Cross-Origin-Requests von jeglichen Quellen.

Beispiel von Cross-Origin Resource Sharing

In unserem nach­fol­gen­den Beispiel nehmen wir nun an, Host A (example.com) möchte einen DELETE-Request an Host B (example.org) senden. Dafür schickt der ur­sprüng­li­che Server zunächst eine Preflight-Anfrage:

/OPTIONS
Origin: http://example.com
Access-Control-Request-Method: DELETE

Hat Host B kein Problem mit diesem Cross-Origin-Request, antwortet er mit den ent­spre­chen­den CORS-Headern:

Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: PUT, POST, DELETE

Stimmen die Header in der Antwort nicht mit den Spe­zi­fi­ka­tio­nen der Anfrage überein oder antwortet der an­ge­frag­te Server nicht, kann kein Cross-Origin-Request durch­ge­führt werden.

Vor- und Nachteile von CORS

Ei­gent­lich dient CORS dazu, eine an sich sichere Grund­ein­stel­lung – nämlich die Same-Origin-Policy – zu umgehen. Die SOP ist wiederum ein wirksames Mittel, um po­ten­zi­ell ge­fähr­li­che Ver­bin­dun­gen zu un­ter­bin­den. Das Internet basiert aber vielfach auf eben solchen Cross-Origin-Requests, denn viele Ver­bin­dun­gen von einem Host zum anderen sind durchaus gewünscht.

CORS bietet somit einen Zwi­schen­weg: Für solche Si­tua­tio­nen, bei denen Cross-Origin-Requests explizit benötigt werden, lassen sich durch CORS Ausnahmen schaffen. Al­ler­dings besteht die Gefahr, dass Website-Betreiber aus Gründen der Be­quem­lich­keit nur auf Wildcards setzen. Dadurch würde man tat­säch­lich jeglichen Schutz durch die SOP negieren. Deshalb ist es wichtig, CORS nur in aus­ge­wähl­ten Son­der­fäl­len ein­zu­set­zen und so re­strik­tiv wie möglich zu kon­fi­gu­rie­ren.

Zum Hauptmenü