[{"data":1,"prerenderedAt":286},["ShallowReactive",2],{"blog-tag-de-security-header":3},{"tagName":4,"posts":5},"Security Header",[6,141],{"id":7,"title":8,"author":9,"body":10,"category":4,"date":107,"description":108,"extension":109,"faq":110,"meta":129,"navigation":130,"path":131,"readingTime":132,"seo":133,"slug":134,"stem":135,"tags":136,"__hash__":140},"blog\u002Fblog\u002Fde\u002Fwhat-is-cross-origin-opener-policy.md","Was ist der Cross-Origin-Opener-Policy Header und warum ist er wichtig?","EuroraCloud Team",{"type":11,"value":12,"toc":96},"minimark",[13,17,21,26,29,32,36,39,42,46,49,52,56,59,62,66,69,72,76,79,89,93],[14,15,8],"h1",{"id":16},"was-ist-der-cross-origin-opener-policy-header-und-warum-ist-er-wichtig",[18,19,20],"p",{},"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.",[22,23,25],"h2",{"id":24},"warum-gibt-es-den-cross-origin-opener-policy-header","Warum gibt es den Cross-Origin-Opener-Policy Header?",[18,27,28],{},"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.",[18,30,31],{},"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.",[22,33,35],{"id":34},"was-leistet-der-cross-origin-opener-policy-header-eigentlich","Was leistet der Cross-Origin-Opener-Policy Header eigentlich?",[18,37,38],{},"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.",[18,40,41],{},"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.",[22,43,45],{"id":44},"was-passiert-wenn-sie-ihn-nicht-setzen","Was passiert, wenn Sie ihn nicht setzen?",[18,47,48],{},"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.",[18,50,51],{},"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.",[22,53,55],{"id":54},"wie-implementieren-sie-den-cross-origin-opener-policy-header","Wie implementieren Sie den Cross-Origin-Opener-Policy Header?",[18,57,58],{},"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.",[18,60,61],{},"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.",[22,63,65],{"id":64},"was-ändert-sich-auf-ihrer-website-sobald-er-aktiv-ist","Was ändert sich auf Ihrer Website, sobald er aktiv ist?",[18,67,68],{},"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.",[18,70,71],{},"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.",[22,73,75],{"id":74},"was-sollten-sie-als-nächstes-tun","Was sollten Sie als Nächstes tun?",[18,77,78],{},"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.",[18,80,81,82],{},"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. ",[83,84,88],"a",{"href":85,"rel":86},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=coop",[87],"nofollow","Sehen Sie, was EuroraCloud löst",[22,90,92],{"id":91},"fazit-was-sollten-sie-zum-cross-origin-opener-policy-header-mitnehmen","Fazit: Was sollten Sie zum Cross-Origin-Opener-Policy Header mitnehmen?",[18,94,95],{},"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.",{"title":97,"searchDepth":98,"depth":98,"links":99},"",2,[100,101,102,103,104,105,106],{"id":24,"depth":98,"text":25},{"id":34,"depth":98,"text":35},{"id":44,"depth":98,"text":45},{"id":54,"depth":98,"text":55},{"id":64,"depth":98,"text":65},{"id":74,"depth":98,"text":75},{"id":91,"depth":98,"text":92},"2026-07-13","Der Cross-Origin-Opener-Policy Header ermöglicht es einer Seite, ihr Browserfenster von Cross-Origin-Seiten zu isolieren, die sie öffnen oder von ihr geöffnet werden, und schließt so eine Klasse von Side-Channel- und Popup-Angriffen. Das leistet der Header, so setzen Sie ihn, und das ändert sich dadurch.","md",[111,113,115,118,120,123,126],{"question":25,"answer":112},"COOP existiert, weil das Öffnen eines Fensters eine skriptfähige Verbindung schafft, die missbraucht werden kann. Wenn eine Seite eine andere öffnet, kann der Browser über window.opener eine Referenz zwischen den beiden Fenstern behalten, und stammen die Seiten von unterschiedlichen Origins, wird diese Referenz zu einem Weg, über den eine Cross-Origin-Seite die Ihre über Side Channels und Timing ausspähen kann, eine Familie von Techniken, die als XS-Leaks bekannt ist. COOP lässt eine Website sicherstellen, dass ihr Top-Level-Dokument keine Browsing Context Group mit Cross-Origin-Dokumenten teilt, was diese Referenz trennt.",{"question":35,"answer":114},"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. Streng gesetzt kommt Ihr Fenster in eine eigene Gruppe und Cross-Origin-Fenster verlieren ihre Referenz auf das Ihre. Die Werte sind unsafe-none (Standard, keine Isolierung), same-origin (strenge Isolierung) und same-origin-allow-popups (Isolierung, die von Ihnen geöffnete Popups zulässt). Unter same-origin wird der window.opener eines Cross-Origin-Fensters zu null.",{"question":116,"answer":117},"Was passiert, wenn Sie den Cross-Origin-Opener-Policy Header 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 Side-Channel-Angriffe nutzen. Nichts wirkt kaputt, und deshalb bleibt es unbehandelt, doch für eine Website mit einem Login, Patientenportal oder Bezahlschritt ist es eine vermeidbare Angriffsfläche, die Scanner zunehmend kennzeichnen.",{"question":55,"answer":119},"Setzen Sie COOP als einen einzigen HTTP-Response-Header, am Webserver, in der Anwendungsebene oder am Rand. Für die meisten Websites ist der richtige Startwert same-origin-allow-popups, der Isolierung gibt und Popup-Abläufe erhält; eine Website ohne Popup-Abhängigkeiten kann das strengere same-origin verwenden. Testen Sie vor dem Erzwingen mit dem Report-only-Modus, gesendet als Cross-Origin-Opener-Policy-Report-Only, der meldet, was die Richtlinie brechen würde, ohne sie zu brechen.",{"question":121,"answer":122},"Was ändert sich auf Ihrer Website, sobald der Cross-Origin-Opener-Policy Header aktiv ist?","Für die meisten Websites ändert sich nichts Sichtbares; gewöhnliche Seitenaufrufe und Same-Origin-Verhalten bleiben unberührt und die Isolierung geschieht auf Browserebene. Zu prüfen ist jeder Ablauf, der bewusst eine andere Origin öffnet oder von ihr geöffnet wird, etwa ein Zahlungs- oder Identity-Provider, weshalb es same-origin-allow-popups gibt und das Testen im Report-only-Modus wichtig ist. same-origin gemeinsam mit Cross-Origin-Embedder-Policy zu setzen, aktiviert zudem einen Cross-Origin-Isolated-Zustand, den manche leistungsstarke Funktionen wie SharedArrayBuffer voraussetzen.",{"question":124,"answer":125},"Was sollten Sie als Nächstes zum Cross-Origin-Opener-Policy Header tun?","Prüfen Sie, ob Ihre Website überhaupt einen Cross-Origin-Opener-Policy Header sendet, denn kein Header bedeutet keine Isolierung. Fehlt er, fügen Sie ihn im Report-only-Modus hinzu, bestätigen Sie, dass in Ihren Popup- oder Drittanbieter-Abläufen nichts bricht, und erzwingen Sie dann same-origin-allow-popups als sinnvollen Standard, oder same-origin, wenn Ihre Website keine Popup-Abhängigkeiten hat.",{"question":127,"answer":128},"Was sollten Sie zum Cross-Origin-Opener-Policy Header mitnehmen?","COOP ist ein leiser, aber lohnender Header, der Ihr Browserfenster von Cross-Origin-Seiten isoliert und eine Klasse von Side-Channel- und Popup-Angriffen schließt, die kein sichtbares Zeichen hinterlassen. 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 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.",{},true,"\u002Fblog\u002Fde\u002Fwhat-is-cross-origin-opener-policy","7 Minuten",{"title":8,"description":108},"what-is-cross-origin-opener-policy","blog\u002Fde\u002Fwhat-is-cross-origin-opener-policy",[137,4,138,139],"Cross-Origin-Opener-Policy","Web-Sicherheit","Browser-Isolierung","dIQHUjFaEJBccxaQDY70KD3e_dwisCj55HESIIkenGg",{"id":142,"title":143,"author":9,"body":144,"category":4,"date":107,"description":253,"extension":109,"faq":254,"meta":276,"navigation":130,"path":277,"readingTime":278,"seo":279,"slug":280,"stem":281,"tags":282,"__hash__":285},"blog\u002Fblog\u002Fde\u002Fwhat-is-permissions-policy.md","Was ist der Permissions-Policy Header und warum ist er wichtig?",{"type":11,"value":145,"toc":243},[146,149,152,156,159,162,166,179,185,189,192,195,197,200,203,207,210,213,216,218,221,224,226,229,236,240],[14,147,143],{"id":148},"was-ist-der-permissions-policy-header-und-warum-ist-er-wichtig",[18,150,151],{},"Der Permissions-Policy Header ist ein Response-Header, der einer Website erlaubt zu steuern, welche Browserfunktionen ihre eigenen Seiten und alle darin eingebetteten Inhalte nutzen dürfen. Funktionen wie Kamera, Mikrofon, Geolokalisierung und Zahlung können jeweils erlaubt, auf Ihre eigene Origin beschränkt oder ganz abgeschaltet werden. Ihn zu setzen bedeutet, dass der Browser die Nutzung verweigert, selbst wenn ein Skript oder ein eingebetteter Dritter versucht, eine dieser Funktionen zu erreichen, sofern Ihre Richtlinie es nicht erlaubt, was sowohl Ihre Datenschutzangriffsfläche als auch Ihre allgemeine Angriffsfläche verringert.",[22,153,155],{"id":154},"warum-gibt-es-den-permissions-policy-header","Warum gibt es den Permissions-Policy Header?",[18,157,158],{},"Moderne Browser stellen Webseiten viele leistungsstarke Fähigkeiten bereit: Standort, Kamera, Mikrofon, Bewegungssensoren und mehr. Jedes Skript, das auf Ihrer Seite läuft, einschließlich der Drittanbieter-Skripte, die Sie für Analytics, Chat oder Werbung eingebettet haben, kann den Browser im Prinzip auffordern, diese Fähigkeiten zu nutzen. Permissions-Policy existiert, damit Sie auf Ebene der gesamten Website festlegen können, welche dieser Funktionen erlaubt sind und für wen.",[18,160,161],{},"Der Sinn besteht darin, die Lücke zwischen dem, was ein Browser kann, und dem, was Ihre Website tatsächlich braucht, zu schließen. Die meisten Websites nutzen nie den Beschleunigungssensor oder die Payment-API, doch ohne Richtlinie bleiben diese Funktionen für jeden Code auf der Seite erreichbar. Laut der Dokumentation von MDN wird der Nutzer, wenn eine Richtlinie eine Funktion blockiert, nicht einmal um Erlaubnis gebeten, und der Versuch eines Skripts, sie zu nutzen, scheitert schlicht, was genau die Eindämmung ist, die Sie für Funktionen wünschen, die Sie nie nutzen wollten.",[22,163,165],{"id":164},"was-leistet-der-permissions-policy-header-eigentlich","Was leistet der Permissions-Policy Header eigentlich?",[18,167,168,169,173,174,178],{},"Der Header funktioniert als Liste von Direktiven, eine pro Funktion, jede mit einer Allowlist, die angibt, welche Origins sie nutzen dürfen. Die Syntax ist der Funktionsname, ein Gleichheitszeichen und die erlaubten Origins in Klammern, wobei mehrere Direktiven durch Kommas getrennt werden, zum Beispiel geolocation=(), camera=(self). Eine leere Allowlist, geschrieben als (), schaltet die Funktion überall ab; self erlaubt sie nur auf Ihrer eigenen Origin; eine bestimmte Origin wie (\"",[83,170,171],{"href":171,"rel":172},"https:\u002F\u002Fexample.com",[87],"\") erlaubt diese Origin; und ",[175,176,177],"code",{},"*"," erlaubt sie überall, auch in eingebetteten Frames.",[18,180,181,182,184],{},"Ein nützliches Detail ist, dass jede Funktion eine Standard-Allowlist hat, die gilt, wenn Sie nichts angeben, und je nach Funktion ist dieser Standard ",[175,183,177],{},", self oder keine. Der Wert, den Header explizit zu setzen, besteht also darin, dass Sie sich nicht länger auf die Standards je Funktion verlassen, sondern eine bewusste, einheitliche Entscheidung treffen: alles abschalten, was Sie nicht nutzen, und alles, was Sie nutzen, auf Ihre eigene Origin oder die bestimmten Partner beschränken, die es brauchen.",[22,186,188],{"id":187},"wie-verhält-sich-der-header-mit-eingebetteten-iframes","Wie verhält sich der Header mit eingebetteten iframes?",[18,190,191],{},"Das ist der Teil, über den die meisten stolpern, daher lohnt sich Genauigkeit. Eine Funktion ist innerhalb eines eingebetteten iframes nur verfügbar, wenn zwei Bedingungen zugleich erfüllt sind: Ihre Top-Level-Seite muss die Funktion für die Origin dieses Frames in ihrer Permissions-Policy erlauben, und das iframe selbst darf sie nicht deaktiviert haben. Anders gesagt setzt die übergeordnete Seite die äußere Grenze, und nichts Eingebettetes kann sich selbst eine Funktion gewähren, die die übergeordnete Seite vorenthalten hat.",[18,193,194],{},"Es gibt außerdem eine Steuerung je iframe, die neben dem Header wirkt, das allow-Attribut am iframe-Element, zum Beispiel eine eingebettete Karte, hinzugefügt mit einem Frame, dessen allow-Attribut geolocation erlaubt. Das Denkmodell, das Sie behalten sollten, ist, dass der Header die websiteweite Richtlinie ist und das allow-Attribut die Ausnahme je Einbettung darin: Der Frame kann nur erhalten, was der Header bereits erlaubt, und das Attribut grenzt es dann ein oder lenkt es auf diese bestimmte Einbettung. Genau deshalb meldet ein Drittanbieter-Widget manchmal, dass eine Funktion blockiert ist, obwohl der Code des Widgets korrekt ist, weil die enthaltende Seite diese Funktion für die Origin des Widgets nie erlaubt hat.",[22,196,45],{"id":44},[18,198,199],{},"Ohne den Header fällt jede Funktion auf ihre eigene Standard-Allowlist zurück, die für mehrere Funktionen freizügiger ist, als eine typische Website braucht. In der Praxis bedeutet das, dass Fähigkeiten, die Sie nie nutzen, erreichbar bleiben, und dass eingebettete Drittinhalte Funktionen anfordern können, die Sie nicht gewährt hätten, wenn man Sie gefragt hätte.",[18,201,202],{},"Dies ist meist keine dringende Lücke, weshalb sie unbehandelt bleibt, aber es ist eine echte. Sie wiegt am schwersten dort, wo Sie Code einbetten, den Sie nicht geschrieben haben: ein Analytics-Tag, ein Chat-Widget, ein Marketing-Pixel. Funktionen einzuschränken, die Sie nicht nutzen, verkleinert, was all dieser eingebettete Code versuchen kann, und es ist genau die Art fehlender Header, die Sicherheitsscanner und Audits inzwischen auf fast jeder Website kennzeichnen, die ihn nicht gesetzt hat.",[22,204,206],{"id":205},"wie-implementieren-sie-den-permissions-policy-header","Wie implementieren Sie den Permissions-Policy Header?",[18,208,209],{},"Sie setzen Permissions-Policy als einen einzigen HTTP-Response-Header. Eine sinnvolle Ausgangsrichtlinie besteht darin, die Funktionen abzuschalten, von denen Sie wissen, dass Sie sie nicht nutzen, und den Rest auf Ihre eigene Origin zu beschränken, zum Beispiel Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), und dann einzelne Direktiven nur dort zu lockern, wo ein echter Bedarf besteht. Er kann am Webserver, in der Anwendungsebene oder am Rand in einem CDN oder einer Sicherheitsschicht vor der Website angewendet werden.",[18,211,212],{},"Es hilft, dies an einer echten Website statt im Abstrakten zu betrachten. Nehmen Sie eine Klinik-Website, die eine eingebettete Karte zeigt, damit Patienten die Praxis finden, und ein Online-Buchungstool betreibt, das einen Bezahlschritt öffnet, aber sonst keine Browserfunktionen nutzt. Eine auf diese Website zugeschnittene Richtlinie würde alles abschalten, was sie nie berührt, und nur erlauben, was diese beiden Funktionen brauchen: geolocation beschränkt auf die Origin des Kartenanbieters, payment beschränkt auf den Buchungs- oder Zahlungsanbieter, und Kamera, Mikrofon und die verschiedenen Sensorfunktionen alle mit einer leeren Allowlist abgeschaltet. Das Ergebnis ist eine Seite, auf der Karte und Bezahlvorgang genau wie zuvor funktionieren, während jede andere Fähigkeit für jedes Skript schlicht nicht verfügbar ist, ob dieses Skript Ihres ist oder zu einem eingebetteten Dritten gehört. Das Prinzip lässt sich verallgemeinern: Listen Sie auf, was die Website wirklich nutzt, erlauben Sie diese den bestimmten Origins, die sie bereitstellen, und schließen Sie den Rest.",[18,214,215],{},"Testen Sie, bevor Sie ihn festzurren. Der Header hat einen Report-only-Begleiter, Permissions-Policy-Report-Only, der die Reporting-API des Browsers nutzt, um Ihnen mitzuteilen, was eine Richtlinie blockieren würde, ohne sie tatsächlich durchzusetzen. Diesen zuerst zu betreiben ist der sichere Weg, um herauszufinden, ob eine echte Funktion, eine Karte, die geolocation braucht, ein Buchungstool, das einen Zahlungsablauf öffnet, ein eingebettetes Video, von Ihrer Richtlinie erfasst würde, sodass Sie sie bewusst erlauben, statt sie überraschend zu brechen.",[22,217,65],{"id":64},[18,219,220],{},"Für die meisten Websites nichts Sichtbares. Gewöhnliche Seiten, die keine eingeschränkten Funktionen nutzen, verhalten sich genau wie zuvor, und Besucher bemerken nichts, weil die Richtlinie nur eingreift, wenn Code versucht, eine Funktion zu erreichen, die Sie nicht erlaubt haben.",[18,222,223],{},"Zu prüfen ist jede Funktion, auf die Ihre eigene Website wirklich angewiesen ist, und alles, was Ihre eingebetteten Dritten brauchen. Ein Filialfinder mit Geolokalisierung, eine Videoanruf-Funktion mit Kamera und Mikrofon oder ein Checkout mit der Payment-API müssen alle ihre Direktiven so gesetzt haben, dass die richtigen Origins erlaubt sind, was genau der Grund ist, warum Tests im Report-only-Modus vor der Durchsetzung wichtig sind. Machen Sie das einmal richtig, und der Header hält danach leise die Linie, erlaubt, was Sie beabsichtigt haben, und verweigert alles andere.",[22,225,75],{"id":74},[18,227,228],{},"Prüfen Sie zunächst, ob Ihre Website überhaupt einen Permissions-Policy Header sendet, denn ohne ihn fällt jede Funktion schlicht auf ihren Standard zurück. Fehlt er, ist der risikoarme Weg, ihn im Report-only-Modus hinzuzufügen, die Funktionen aufzulisten, die Sie tatsächlich nutzen, zu bestätigen, dass nichts, worauf Sie angewiesen sind, blockiert wird, und dann eine Richtlinie durchzusetzen, die alles andere abschaltet.",[18,230,231,232],{},"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 prüfen und Ihnen zeigen, was unsere Plattform löst. ",[83,233,88],{"href":234,"rel":235},"https:\u002F\u002Fwww.euroracloud.eu\u002F",[87],[22,237,239],{"id":238},"fazit-was-sollten-sie-zum-permissions-policy-header-mitnehmen","Fazit: Was sollten Sie zum Permissions-Policy Header mitnehmen?",[18,241,242],{},"Permissions-Policy ist ein leiser, praktischer Header: Er lässt Sie die Browserfunktionen abschalten, die Ihre Website nie nutzt, und jene, die sie nutzt, auf genau die Origins beschränken, die sie brauchen, sodass weder Ihre eigenen Skripte noch eingebettete Dritte Fähigkeiten erreichen können, die Sie nie offenlegen wollten. Der sichere Weg der Einführung ist, im Report-only-Modus zu testen, zu bestätigen, dass Ihre echten Funktionen weiterhin arbeiten, und dann eine Richtlinie durchzusetzen, die den Rest abschaltet. Der nützlichste Schritt ist zu prüfen, ob Ihre Website den Header heute sendet, denn solange sie das nicht tut, bleibt jede Funktion auf ihrem Standard.",{"title":97,"searchDepth":98,"depth":98,"links":244},[245,246,247,248,249,250,251,252],{"id":154,"depth":98,"text":155},{"id":164,"depth":98,"text":165},{"id":187,"depth":98,"text":188},{"id":44,"depth":98,"text":45},{"id":205,"depth":98,"text":206},{"id":64,"depth":98,"text":65},{"id":74,"depth":98,"text":75},{"id":238,"depth":98,"text":239},"Der Permissions-Policy Header lässt eine Website entscheiden, welche Browserfunktionen, etwa Kamera, Mikrofon und Geolokalisierung, ihre eigenen Seiten und eingebettete Inhalte nutzen dürfen. Das leistet der Header, so setzen Sie ihn, und das ändert sich dadurch.",[255,257,259,262,265,267,270,273],{"question":155,"answer":256},"Moderne Browser stellen leistungsstarke Fähigkeiten wie Standort, Kamera, Mikrofon und Bewegungssensoren bereit, und jedes Skript auf Ihrer Seite, einschließlich eingebetteten Drittcodes, kann im Prinzip auffordern, sie zu nutzen. Permissions-Policy existiert, damit Sie auf Websiteebene festlegen können, welche Funktionen erlaubt sind und für wen, und so die Lücke zwischen dem, was ein Browser kann, und dem, was Ihre Website braucht, schließen. Wenn eine Richtlinie eine Funktion blockiert, wird der Nutzer nicht einmal gefragt und der Versuch eines Skripts scheitert schlicht.",{"question":165,"answer":258},"Der Header ist eine Liste von Direktiven, eine pro Funktion, jede mit einer Allowlist von Origins, die sie nutzen dürfen. Die Syntax ist der Funktionsname, ein Gleichheitszeichen und die erlaubten Origins in Klammern, Direktiven durch Kommas getrennt, zum Beispiel geolocation=(), camera=(self). Eine leere Allowlist () schaltet die Funktion überall ab, self erlaubt nur Ihre eigene Origin, eine bestimmte Origin erlaubt diese Origin, und * erlaubt sie überall. Jede Funktion hat zudem eine Standard-Allowlist aus *, self oder keine, die gilt, wenn Sie nichts angeben.",{"question":260,"answer":261},"Wie verhält sich der Permissions-Policy Header mit eingebetteten iframes?","Eine Funktion ist innerhalb eines eingebetteten iframes nur verfügbar, wenn zwei Bedingungen zugleich erfüllt sind: Ihre Top-Level-Seite muss die Funktion für die Origin dieses Frames erlauben, und das iframe selbst darf sie nicht deaktiviert haben. Die übergeordnete Seite setzt die äußere Grenze und nichts Eingebettetes kann sich eine Funktion gewähren, die die übergeordnete Seite vorenthalten hat. Das allow-Attribut am iframe-Element wirkt zusätzlich als Ausnahme je Einbettung: Der Frame kann nur erhalten, was der Header bereits erlaubt.",{"question":263,"answer":264},"Was passiert, wenn Sie den Permissions-Policy Header nicht setzen?","Ohne den Header fällt jede Funktion auf ihre eigene Standard-Allowlist zurück, die für mehrere Funktionen freizügiger ist, als eine typische Website braucht. Fähigkeiten, die Sie nie nutzen, bleiben erreichbar, und eingebettete Drittinhalte können Funktionen anfordern, die Sie nicht gewährt hätten. Es ist selten dringend, weshalb es unbehandelt bleibt, aber es wiegt am schwersten dort, wo Sie Code einbetten, den Sie nicht geschrieben haben, etwa ein Analytics-Tag, Chat-Widget oder Marketing-Pixel, und Scanner kennzeichnen es inzwischen auf fast jeder Website, die ihn nicht gesetzt hat.",{"question":206,"answer":266},"Setzen Sie Permissions-Policy als einen einzigen HTTP-Response-Header, am Webserver, in der Anwendungsebene oder am Rand. Eine sinnvolle Ausgangsrichtlinie schaltet Funktionen ab, die Sie nicht nutzen, und beschränkt den Rest auf Ihre eigene Origin, zum Beispiel geolocation=(), camera=(), microphone=(), payment=(). Testen Sie zuerst mit dem Report-only-Begleiter, Permissions-Policy-Report-Only, der die Reporting-API des Browsers nutzt, um mitzuteilen, was eine Richtlinie blockieren würde, ohne sie durchzusetzen, sodass Sie echte Funktionen bewusst erlauben, statt sie überraschend zu brechen.",{"question":268,"answer":269},"Was ändert sich auf Ihrer Website, sobald der Permissions-Policy Header aktiv ist?","Für die meisten Websites ändert sich nichts Sichtbares, weil die Richtlinie nur eingreift, wenn Code versucht, eine Funktion zu erreichen, die Sie nicht erlaubt haben. Zu prüfen ist jede Funktion, auf die Ihre Website angewiesen ist, und alles, was Ihre eingebetteten Dritten brauchen, etwa ein Filialfinder mit Geolokalisierung, eine Videofunktion mit Kamera und Mikrofon oder ein Checkout mit der Payment-API, die alle ihre Direktiven so gesetzt haben müssen, dass die richtigen Origins erlaubt sind. Deshalb sind Tests im Report-only-Modus vor der Durchsetzung wichtig.",{"question":271,"answer":272},"Was sollten Sie als Nächstes zum Permissions-Policy Header tun?","Prüfen Sie, ob Ihre Website überhaupt einen Permissions-Policy Header sendet, denn ohne ihn fällt jede Funktion auf ihren Standard zurück. Fehlt er, fügen Sie ihn im Report-only-Modus hinzu, listen Sie die Funktionen auf, die Sie tatsächlich nutzen, bestätigen Sie, dass nichts, worauf Sie angewiesen sind, blockiert wird, und setzen Sie dann eine Richtlinie durch, die alles andere abschaltet.",{"question":274,"answer":275},"Was sollten Sie zum Permissions-Policy Header mitnehmen?","Permissions-Policy lässt Sie die Browserfunktionen abschalten, die Ihre Website nie nutzt, und jene, die sie nutzt, auf genau die Origins beschränken, die sie brauchen, sodass weder Ihre eigenen Skripte noch eingebettete Dritte Fähigkeiten erreichen können, die Sie nie offenlegen wollten. Der sichere Weg der Einführung ist, im Report-only-Modus zu testen, zu bestätigen, dass Ihre echten Funktionen weiter arbeiten, und dann eine Richtlinie durchzusetzen, die den Rest abschaltet. Der nützlichste Schritt ist zu prüfen, ob Ihre Website den Header heute sendet, denn solange sie das nicht tut, bleibt jede Funktion auf ihrem Standard.",{},"\u002Fblog\u002Fde\u002Fwhat-is-permissions-policy","8 Minuten",{"title":143,"description":253},"what-is-permissions-policy","blog\u002Fde\u002Fwhat-is-permissions-policy",[283,4,138,284],"Permissions-Policy","Datenschutz","q_cuWTHT0Fwcy2g5TuANtLH4yPhjojwSRC4DGe-ej4c",1785141132275]