Über Kreuz
Cross-Site-Zugriffe mit CORS gezielt steuern
Browser bemühen sich, Cross-Site-Angriffe im Web zu erschweren und blockieren HTTP-Zugriffe von JavaScript-Code auf fremde Domains. Manchmal will man genau das aber zulassen. Mit CORS-Headern geben Entwickler ausgewählte Ressourcen für andere Seiten frei.
Um zu verstehen, warum es nötig ist, Ressourcen auf Webservern per Cross-Origin-Resource-Sharing (CORS) freizugeben, muss man zunächst einen Blick auf den Umgang von Browsern mit Cookies und sogenannten CSRF-Angriffen werfen. Ursache der beschriebenen Probleme ist die Natur von HTTP – ein Protokoll, das ursprünglich dafür konzipiert war, statische Seiten in einem Wissenschaftsnetzwerk auszuliefern. Auf modernden Webseiten ist es aber üblich, dass man nicht nur Inhalte liest, sondern selbst Inhalte schreibt oder Aktionen in der realen Welt über den Browser auslöst.
Für solche Anwendungen ist es entscheidend, dass sich der Benutzer zunächst anmeldet, klassisch mit Benutzername und Kennwort. HTTP ist statuslos, die Verbindung wird also nach jeder Übertragung eines Datensatzes, HTML-Dokuments oder Bildes geschlossen. Folgende Aufrufe kann der Server keinen vorangegangenen zuordnen. Damit der Nutzer nicht bei jedem Aufruf einer Ressource sein Kennwort wieder eintippen muss, braucht man ein Verfahren, um angemeldete Nutzer wiederzuerkennen. Viele Webseiten arbeiten mit einer Technik, die alle Browser schon seit Jahrzehnten unterstützen: Bei der erfolgreichen Anmeldung schickt der Server per HTTP-Header eine Zeichenkette an den Browser, das sogenannte Cookie. Der Header enthält zusätzlich die Information, für welche Domain dieses Cookie bestimmt ist und wie lange es gültig sein soll.