Zusammenfassung

  • Der Origin-Entwurf vom Januar 2009 wollte einem Server mitteilen, aus welchem Sicherheitskontext eine Anfrage kam. RFC 6454 vom Dezember 2011 beschrieb die umfassendere Grenze, nach der Browser Webseiten zu einer gemeinsamen Origin zusammenfassen.
  • Schema, Host und Port zählen; der Pfad zählt nicht. Aktives HTML von Fremden kann unter derselben Origin die Browserrechte der Anwendung teilen, wenn der Betreiber es dort ausliefert.

Zwei Verzeichnisse, ein Browserausweis

Ein Dienst legt Kontoseiten unter /konto ab und Beiträge seiner Nutzer unter /beitraege. Im Betrieb sehen das nach verschiedenen Abteilungen aus. Der Browser liest eine andere Ordnung. Stimmen Schema, Host und Port überein, gehören beide Seiten zu derselben Origin. Die Wörter hinter dem Schrägstrich stehen nicht auf seinem Ausweis.

RFC 6454 vom Dezember 2011 beschrieb eine Regel, die sich in Browsern schon über Jahre entwickelt hatte. Das Dokument erfand die Same-Origin-Policy nicht mit einem Federstrich. Es legte fest, wie sich die Schutzdomäne einer Adresse bestimmen und vergleichen lässt. Eine Anwendung besteht aus vielen Seiten und Dateien. Jede einzelne URL wie einen Fremden zu behandeln, hätte ihre Zusammenarbeit schwerfällig gemacht. Die Origin bindet diese Ressourcen zusammen.

Die Beispiele im RFC sind genauer als ein Schlagwort über Domains. Eine HTTP-Seite auf example.com und ein weiterer Pfad auf demselben Host mit ausdrücklich genanntem Port 80 haben dieselbe Origin; 80 ist der Standardport von HTTP. Ein anderer Port verschiebt die Grenze. Auch https verschiebt sie, selbst bei gleichem Host. Die ungeschützte HTTP-Seite soll nicht einfach die Browservertrauensstellung ihrer geschützten Nachbarin erhalten. Dagegen verschiebt ein anderer Pfad gar nichts.

Die fremde Seite bekam die Schlüsselkarte

Diese Grobheit macht eine Veröffentlichungsentscheidung brisant. Liefert ein Betreiber von Nutzern eingereichtes Material als aktives HTML unter der Haupt-Origin aus, kann dessen Skript im Sicherheitskontext dieser Origin laufen. RFC 6454 weist bei fremdem Material ausdrücklich auf den Medientyp hin. Der Server darf für einzelne Kontofunktionen weiterhin eigene Berechtigungen prüfen; seine Entscheidung ersetzt die Einordnung des Browsers nicht. Ein Verzeichnis namens /beitraege entzieht dem HTML keine Browserrechte.

Der Origin-Entwurf vom Januar 2009 begann bei der ankommenden HTTP-Anfrage. Ein Header sollte den Kontext nennen, der die Anfrage auslöste, damit Server unter anderem gefälschte Anfragen über Websites hinweg untersuchen konnten. Es war ein Internet-Draft, kein verabschiedeter Standard. RFC 6454 machte anschließend deutlicher, dass die Origin auch ohne ausgehende Anfrage eine Einheit der Browserpolitik ist. Der Header kann diese Herkunft melden. Fehlt ein gewöhnliches Schema-Host-Port-Triple, wird die Origin als null serialisiert; für Anfragen aus datenschutzsensiblen Kontexten sieht der RFC ebenfalls null vor.

Die CORS-Empfehlung des W3C von 2014 verwendete diese Herkunft später bei der Frage, wer eine Antwort von einem anderen Standort lesen darf. Sie trennte das Lesen einer Antwort von der Erlaubnis für die Wirkung einer Anfrage. Die Lesefreigabe ist ihre eigene Geschichte. Die ältere Grenze entscheidet, welche Seiten der Browser bereits als Mitbewohner betrachtet.

RFC 6454 schrieb den Maßstab auf: Der Port zählt, der Pfad nicht. Der Betreiber bestimmt durch seine Auslieferung, wer ihn teilt.