Die Same-Origin Policy: was eine Origin ist und was sie isoliert

Worum es geht

RFC 6454 definiert eine Origin als das Tupel aus Schema, Host und Port; MDN nennt es das «scheme/host/port tuple». https://example.com, https://example.com:8443, http://example.com und https://app.example.com sind vier verschiedene Origins; Pfad und Query spielen keine Rolle. Die Same-Origin Policy ist die Regel des Browsers für Interaktionen zwischen Origins. MDN teilt sie in drei Gruppen ein: ursprungsübergreifende Schreibzugriffe (Links, Weiterleitungen, Formularübermittlungen) sind in der Regel erlaubt; ursprungsübergreifende Einbettung (img, script, iframe, Stylesheets, Fonts) ist in der Regel erlaubt, doch der eingebettete Inhalt bleibt für Skripte undurchsichtig; ursprungsübergreifende Lesezugriffe (das DOM eines anderen Fensters oder Frames, der Body einer fetch-Antwort, der Speicher einer anderen Origin) sind in der Regel nicht erlaubt. CORS ist das serverseitige Opt-in, das Lesezugriffe lockert. Cookies folgen ihrem eigenen Geltungsbereich: RFC 6265 merkt an, dass sie keine Isolierung nach Port bieten.

Warum es wichtig ist

Die Policy ist der Grund, weshalb eine feindliche Seite die eigene Bank nicht in einem versteckten Frame laden und den Kontostand auslesen kann, und ebenso der Grund, weshalb ein legitimes Frontend auf einer anderen Origin die Antworten der eigenen API nicht lesen kann, bis die API es erlaubt. Aus einem Missverständnis dieser Policy folgen zwei Arten von Fehlern: CORS für jede Origin mit Credentials zu öffnen, nur weil «der Browser es blockiert hat», sowie anzunehmen, die Policy verhindere Cross-Site Request Forgery – was sie nicht tut, da Schreibzugriffe erlaubt sind.

So wird es angewendet

• Eine gemeinsame Origin für Anwendung und API bevorzugen (ein Reverse Proxy unter einem Host); das erübrigt die CORS-Konfiguration und hält Cookies einfach.
• Subdomains für Skript und Speicher als fremd behandeln; ein Cookie mit Domain=example.com überspannt sie, was wichtig ist, wenn eine Subdomain Nutzerinhalte hostet.
• document.domain nie verwenden, um die Prüfung zu lockern; MDN markiert es als deprecated, weil es die Isolierung untergräbt.
• Daten mit eingebetteten Drittanbieter-Frames über postMessage mit einer expliziten Ziel-Origin austauschen und beim Empfang event.origin prüfen.
• Zustandsändernde Endpunkte mit CSRF-Tokens oder SameSite-Cookies schützen; die Policy tut das nicht.
• Mit der CSP-Direktive frame-ancestors steuern, wer die eigene Seite framen darf, und mit Cross-Origin-Resource-Policy, wer die eigenen Subressourcen laden darf.

Stolpersteine

Während der Entwicklung sind http://localhost:3000 und http://localhost:5173 verschiedene Origins, weshalb Dev-Server Proxys anbieten. Ein iframe einer anderen Origin kann vom Elternfenster nicht inspiziert werden, wohl aber navigiert. Eine mit mode: "no-cors" abgerufene Antwort ist undurchsichtig: Die anfragende Seite kann weder ihren Status noch ihren Body lesen.