Was ist der Cross-Origin-Opener-Policy Header und warum ist er wichtig?

Der Cross-Origin-Opener-Policy Header, meist als COOP geschrieben, ist ein Response-Header, der steuert, ob Ihre Seite eine Fensterbeziehung mit Seiten anderer Origins teilt. Auf same-origin gesetzt, isoliert er Ihr Dokument in einer eigenen Browsing Context Group, sodass eine Seite einer anderen Origin, die die Ihre öffnet oder die Sie öffnen, keine skriptfähige Referenz zurück auf Ihr Fenster halten kann. Das schließt eine Klasse von Cross-Origin-Angriffen, die als XS-Leaks und Side-Channel-Angriffe bekannt sind, und es ist zugleich die Einstellung, die bestimmte leistungsstarke Browserfunktionen freischaltet.

Warum gibt es den Cross-Origin-Opener-Policy Header?

COOP existiert, weil das Öffnen eines Fensters eine Verbindung schafft, die missbraucht werden kann. Wenn eine Seite eine andere mit window.open() öffnet, oder eine Seite die Ihre öffnet, kann der Browser über die Eigenschaft window.opener eine Referenz zwischen den beiden Fenstern behalten. Stammen diese beiden Seiten von unterschiedlichen Origins, wird diese Referenz zu einem Weg, über den eine Cross-Origin-Seite die Ihre ausspähen kann.

Die Angriffe, die dies ermöglicht, sind subtil. Sie stehlen Ihre Daten nicht direkt, sondern leiten sie über Side Channels, Timing und gemeinsam genutzten Browserzustand ab, in einer Familie von Techniken, die die Sicherheitsgemeinschaft XS-Leaks nennt. Laut der Dokumentation von Mozilla wurde COOP genau dafür eingeführt, dass eine Website sicherstellen kann, dass ihr Top-Level-Dokument keine Browsing Context Group mit Cross-Origin-Dokumenten teilt, und genau das trennt diese Referenz und schließt den Weg.

Was leistet der Cross-Origin-Opener-Policy Header eigentlich?

COOP entscheidet, ob Ihr Dokument und die Seiten, mit denen es interagiert, zur selben Browsing Context Group gehören, dem internen Browserbegriff, der bestimmt, ob zwei Fenster einander skripten können. Wenn Sie ihn streng setzen, kommt Ihr Fenster in eine eigene Gruppe, und jedes Cross-Origin-Fenster verliert seine Referenz auf das Ihre.

Der Header kennt eine kleine Wertemenge. Der Standardwert, unsafe-none, wendet keine Isolierung an und lässt Ihr Dokument eine Browsing Context Group mit Cross-Origin-Seiten teilen. Der strenge Wert, same-origin, isoliert Ihr Dokument so, dass nur Same-Origin-Seiten, die selbst ebenfalls same-origin setzen, in derselben Gruppe bleiben können. Ein Zwischenwert, same-origin-allow-popups, erhält diese Isolierung, lässt aber Popups, die Sie selbst öffnen, normal funktionieren, was die praktische Wahl für Websites ist, die auf Popup-Abläufe wie Bezahlung oder Single Sign-on angewiesen sind. Wird ein Cross-Origin-Fenster unter same-origin geöffnet, wird sein window.opener zu null, sodass die Referenz schlicht nicht existiert.

Was passiert, wenn Sie ihn nicht setzen?

Ohne COOP gilt der Standard unsafe-none, was bedeutet, dass es keine Isolierung gibt und die Fensterreferenz offen bleibt. Eine Cross-Origin-Seite, die die Ihre öffnet, oder die Sie öffnen, kann einen Zugriff auf Ihr Fenster behalten und ihn als Ansatzpunkt für die oben beschriebenen Side-Channel-Techniken nutzen.

Dies ist eine leise Lücke, keine laute. Nichts auf Ihrer Website wirkt kaputt, und die meisten Besucher werden sie nie auslösen, und genau deshalb bleibt sie oft unbehandelt. Doch für eine Website, die etwas Sensibles verarbeitet, einen Login, ein Patientenportal, einen Bezahlschritt, ist das Offenlassen der Fensterbeziehung eine vermeidbare Angriffsfläche, und es ist eine, die Sicherheitsscanner und Audits zunehmend als fehlenden Header kennzeichnen.

Wie implementieren Sie den Cross-Origin-Opener-Policy Header?

Sie setzen COOP als einen einzigen HTTP-Response-Header. Für die meisten Websites ist der richtige Startwert Cross-Origin-Opener-Policy: same-origin-allow-popups, der Ihnen Isolierung gibt und zugleich Popup-Abläufe erhält; eine Website ohne solche Abhängigkeiten kann zum strengeren same-origin wechseln. Er kann am Webserver, in der Anwendungsebene oder am Rand in einem CDN oder einer Sicherheitsschicht vor der Website hinzugefügt werden.

Die einzige nachdrückliche Empfehlung lautet: testen, bevor Sie erzwingen. COOP unterstützt einen Report-only-Modus, gesendet als Cross-Origin-Opener-Policy-Report-Only, der die Reporting-API des Browsers nutzt, um Ihnen mitzuteilen, was die Richtlinie brechen würde, ohne dass tatsächlich etwas bricht. Zuerst Report-only zu betreiben, auf Popup- oder Fensterabläufe zu achten, die betroffen wären, und erst dann auf den erzwungenen Header umzuschalten, ist der sichere Weg, besonders bei einer Website mit Integrationen Dritter, die Sie nicht selbst gebaut haben.

Was ändert sich auf Ihrer Website, sobald er aktiv ist?

Für die meisten Websites nichts Sichtbares. Gewöhnliche Seitenaufrufe, Navigation und Same-Origin-Verhalten bleiben unberührt, und die Isolierung geschieht unsichtbar auf Browserebene. Der Gewinn ist, dass Cross-Origin-Fenster keine Referenz auf das Ihre mehr halten können, was die Angriffsfläche beseitigt, ohne die Nutzererfahrung zu berühren.

Zu prüfen ist jeder Ablauf, der bewusst eine andere Origin öffnet oder von ihr geöffnet wird. Ein Zahlungsanbieter, ein Identity Provider oder ein eingebettetes Tool, das über Fensterreferenzen kommuniziert, kann von einem strengen Same-Origin-Wert betroffen sein, und genau deshalb gibt es same-origin-allow-popups und deshalb ist das Testen im Report-only-Modus wichtig. Es gibt auch einen erwähnenswerten Vorteil: same-origin gemeinsam mit dem verwandten Cross-Origin-Embedder-Policy Header zu setzen, versetzt Ihr Dokument in einen Cross-Origin-Isolated-Zustand, den manche leistungsstarke Browserfunktionen voraussetzen, etwa SharedArrayBuffer und hochauflösende Timer.

Was sollten Sie als Nächstes tun?

Prüfen Sie zunächst, ob Ihre Website überhaupt einen Cross-Origin-Opener-Policy Header sendet, denn der Standard ohne Header bedeutet keine Isolierung. Fehlt er, ist der risikoarme Weg, ihn im Report-only-Modus hinzuzufügen, zu bestätigen, dass in Ihren Popup- oder Drittanbieter-Abläufen nichts bricht, und dann same-origin-allow-popups als sinnvollen Standard zu erzwingen, oder same-origin, wenn Ihre Website keine Popup-Abhängigkeiten hat.

Wenn Sie dies über Ihre gesamte Website hinweg korrekt prüfen und konfigurieren lassen möchten statt Stück für Stück, kann EuroraCloud Ihre aktuellen Security Header überprüfen und Ihnen zeigen, was unsere Plattform löst. Sehen Sie, was EuroraCloud löst

Fazit: Was sollten Sie zum Cross-Origin-Opener-Policy Header mitnehmen?

COOP ist ein leiser, aber lohnender Header: Er isoliert Ihr Browserfenster von Cross-Origin-Seiten und schließt eine Klasse von Side-Channel- und Popup-Angriffen, die kein sichtbares Zeichen hinterlassen, bis ein Scanner oder ein Angreifer sie findet. Für die meisten Websites ist der sichere Weg, im Report-only-Modus zu testen und dann same-origin-allow-popups zu erzwingen, was das Fenster schützt und zugleich legitime Popup-Abläufe erhält. Der nützlichste Schritt ist zu prüfen, ob Ihre Website den Header heute sendet, denn solange sie das nicht tut, ist der Standard gar keine Isolierung.