Zusammenfassung

  • Ein W3C-Entwurf vom Februar 2007 untersuchte, wie ein Ressourcenanbieter das Lesen seiner Inhalte durch fremde Websites erlauben kann. Der CORS-Entwurf vom März 2009 beschrieb bereits den Austausch zwischen anfragender Origin, Freigabeantwort und Browser.
  • Die Empfehlung vom Januar 2014 regelte die Prüfung von Access-Control-Allow-Origin. Für bestimmte Methoden oder selbst gesetzte Header fragt der Browser zunächst mit OPTIONS an; eine einfache Anfrage kann den Server auch dann erreichen, wenn das Skript die Antwort nicht lesen darf.

Eine Wetterkarte möchte fremde Messdaten anzeigen. Die Zieladresse steht im Quelltext, der Server ist erreichbar. Trotzdem hält der Browser die Antwort zunächst zurück. Die Same-Origin-Grenze lässt ein Skript nicht beliebige Antworten aus fremden Häusern öffnen. CORS gab dem Ressourcenanbieter die Möglichkeit, einzelnen Besuchern eine Leseerlaubnis auszustellen, und dem Browser die Aufgabe, die Einladung zu prüfen.

Der W3C-Entwurf vom 15. Februar 2007, Enabling Read Access for Web Resources, schlug dafür einen HTTP-Header oder eine XML-Verarbeitungsanweisung vor. Verschiedene Muster für Hostnamen standen noch zur Diskussion. Das war ein Vorläufer, kein fertiges CORS. Die tragende Idee war dennoch vorhanden: Die Freigabe kommt von der Seite, die die Ressource bereitstellt. Im CORS-Arbeitsentwurf vom 17. März 2009 nahm das Gespräch eine deutlichere Form an: Origin in der Anfrage, Erlaubnis in der Antwort, Prüfung durch den Browser.

Die W3C-Empfehlung vom 16. Januar 2014 beschreibt, wie die Ressource mit Access-Control-Allow-Origin die zugelassene Herkunft benennt. Der Browser gleicht den Wert mit der Herkunft der anfragenden Seite ab und gibt erst dann die Antwort an deren Skript weiter. Für öffentlich teilbare Ressourcen ohne Zugangsdaten ist auch * vorgesehen. Bei Anfragen mit Zugangsdaten verlangt die Prüfung eine passende konkrete Origin und Access-Control-Allow-Credentials: true. Die offene Tür und die Einladung mit Namen sind absichtlich verschiedene Regeln.

Manchmal fragt der Browser vor dem eigentlichen Besuch an. Eine Methode oder vom Skript gesetzte Header außerhalb der einfachen Auswahl lösen eine OPTIONS-Voranfrage aus. Der Zielserver teilt mit, welche Methoden und Header er für diese Herkunft zulässt. Der Browser prüft die Angaben und kann das Ergebnis vorübergehend zwischenspeichern. Diese Vorprüfung gehört zu bestimmten Anfragen, nicht zum gesamten grenzüberschreitenden Verkehr. Wer jedes Problem auf ein fehlendes OPTIONS schiebt, hört an der falschen Tür klingeln.

Die entscheidende Trennung liegt zwischen Anfrage und Antwort. Eine einfache Anfrage kann beim Server ankommen und dort eine Wirkung entfalten, obwohl der Browser ihre Antwort später für das Skript sperrt. Die Sicherheitsausführungen der Empfehlung unterscheiden ausdrücklich die Autorisierung einer Anfrage samt Nebenwirkungen vom Zugriff auf die zurückgegebene Darstellung. Ob jemand eine Überweisung oder eine Profiländerung auslösen darf, muss der Server selbst prüfen. Ein CORS-Header ist kein Ersatz für diese Entscheidung. Der Browser entscheidet, wer den Brief lesen darf; die Bank entscheidet, wer Geld bewegen darf.

Die W3C-Veröffentlichungsgeschichte führt von den Entwürfen 2007 über die Bekanntgabe der Empfehlung 2014 bis zur formalen Zurückziehung dieses Dokuments 2020. In dieser Geschichte wurde ein alltäglicher Wunsch technisch handhabbar: Ein Anbieter erlaubt einer anderen Herkunft das Lesen einer bestimmten Antwort. Der Browser setzt die Grenze durch. Die Wetterkarte bekommt ihre Zahlen; der Nachbar behält seinen Schlüsselbund.