Same-Origin Policy (SOP).

Die Same-Origin Policy ist die grundlegende Isolationsgrenze des Webs und wurde mit Netscape Navigator 2 (1995) eingefuhrt. Zwei URLs teilen dieselbe Origin nur, wenn Schema, Host und Port ubereinstimmen; andernfalls verhindert der Browser, dass Skripte Antworten lesen, auf das DOM fremder Frames zugreifen oder Cookies anderer Sites einsehen. SOP verhindert, dass eine bosartige Seite den Inhalt einer in einem anderen Tab geoffneten Banking-Sitzung liest.

Was SOP abdeckt - und was nicht

SOP regelt Lesezugriffe, nicht Sendevorgange: Eine Seite kann weiterhin Cross-Origin-Requests auslosen (ein <form>-POST, ein <img>-Load), weshalb CSRF eine eigene Fehlerklasse ist. Gelockert wird sie kontrolliert durch CORS (definiert im WHATWG-Fetch-Standard), postMessage, document.domain und das veraltete JSONP-Muster. Zu freizugige Ausnahmen - etwa das Zuruckspiegeln von Access-Control-Allow-Origin zusammen mit Access-Control-Allow-Credentials: true - sind eine haufige Ursache fur Cross-Origin-Datenlecks und Authentifizierungsumgehungen.

Hartung uber SOP hinaus

Die Spectre-Veroffentlichungen von 2018 zeigten, dass SOP allein nicht verhindern kann, dass eine Origin den Speicher einer anderen innerhalb eines geteilten Renderer-Prozesses liest. Chrome 67 aktivierte daraufhin Site Isolation standardmassig, sodass jede Site einen eigenen Betriebssystemprozess erhalt, und erganzte Cross-Origin Read Blocking (CORB), heute Teil des Fetch-Standards. Moderne Abwehr legt die Header COOP, COEP und CORP uber SOP, um vollstandige Cross-Origin-Isolation zu aktivieren.

flowchart TD
  A[Skript von https://app.example:443] --> B{Ziel-Origin gleich?<br/>Schema + Host + Port}
  B -->|Gleiche Origin| C[Lesen von Antwort, DOM, Cookies erlaubt]
  B -->|Cross-Origin| D{Explizite Lockerung?}
  D -->|CORS / postMessage| E[Header-gesteuerter Zugriff]
  D -->|Keine| F[Browser blockiert Lesen<br/>CORB / opake Antwort]