[{"data":1,"prerenderedAt":171},["ShallowReactive",2],{"blog-tag-de-permissions-policy":3},{"tagName":4,"posts":5},"Permissions-Policy",[6],{"id":7,"title":8,"author":9,"body":10,"category":134,"date":135,"description":136,"extension":137,"faq":138,"meta":160,"navigation":161,"path":162,"readingTime":163,"seo":164,"slug":165,"stem":166,"tags":167,"__hash__":170},"blog\u002Fblog\u002Fde\u002Fwhat-is-permissions-policy.md","Was ist der Permissions-Policy Header und warum ist er wichtig?","EuroraCloud Team",{"type":11,"value":12,"toc":122},"minimark",[13,17,21,26,29,32,36,51,57,61,64,67,71,74,77,81,84,87,90,94,97,100,104,107,115,119],[14,15,8],"h1",{"id":16},"was-ist-der-permissions-policy-header-und-warum-ist-er-wichtig",[18,19,20],"p",{},"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,23,25],"h2",{"id":24},"warum-gibt-es-den-permissions-policy-header","Warum gibt es den Permissions-Policy Header?",[18,27,28],{},"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,30,31],{},"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,33,35],{"id":34},"was-leistet-der-permissions-policy-header-eigentlich","Was leistet der Permissions-Policy Header eigentlich?",[18,37,38,39,45,46,50],{},"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 (\"",[40,41,42],"a",{"href":42,"rel":43},"https:\u002F\u002Fexample.com",[44],"nofollow","\") erlaubt diese Origin; und ",[47,48,49],"code",{},"*"," erlaubt sie überall, auch in eingebetteten Frames.",[18,52,53,54,56],{},"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 ",[47,55,49],{},", 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,58,60],{"id":59},"wie-verhält-sich-der-header-mit-eingebetteten-iframes","Wie verhält sich der Header mit eingebetteten iframes?",[18,62,63],{},"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,65,66],{},"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,68,70],{"id":69},"was-passiert-wenn-sie-ihn-nicht-setzen","Was passiert, wenn Sie ihn nicht setzen?",[18,72,73],{},"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,75,76],{},"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,78,80],{"id":79},"wie-implementieren-sie-den-permissions-policy-header","Wie implementieren Sie den Permissions-Policy Header?",[18,82,83],{},"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,85,86],{},"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,88,89],{},"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,91,93],{"id":92},"was-ändert-sich-auf-ihrer-website-sobald-er-aktiv-ist","Was ändert sich auf Ihrer Website, sobald er aktiv ist?",[18,95,96],{},"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,98,99],{},"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,101,103],{"id":102},"was-sollten-sie-als-nächstes-tun","Was sollten Sie als Nächstes tun?",[18,105,106],{},"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,108,109,110],{},"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. ",[40,111,114],{"href":112,"rel":113},"https:\u002F\u002Fwww.euroracloud.eu\u002F",[44],"Sehen Sie, was EuroraCloud löst",[22,116,118],{"id":117},"fazit-was-sollten-sie-zum-permissions-policy-header-mitnehmen","Fazit: Was sollten Sie zum Permissions-Policy Header mitnehmen?",[18,120,121],{},"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":123,"searchDepth":124,"depth":124,"links":125},"",2,[126,127,128,129,130,131,132,133],{"id":24,"depth":124,"text":25},{"id":34,"depth":124,"text":35},{"id":59,"depth":124,"text":60},{"id":69,"depth":124,"text":70},{"id":79,"depth":124,"text":80},{"id":92,"depth":124,"text":93},{"id":102,"depth":124,"text":103},{"id":117,"depth":124,"text":118},"Security Header","2026-07-13","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.","md",[139,141,143,146,149,151,154,157],{"question":25,"answer":140},"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":35,"answer":142},"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":144,"answer":145},"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":147,"answer":148},"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":80,"answer":150},"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":152,"answer":153},"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":155,"answer":156},"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":158,"answer":159},"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.",{},true,"\u002Fblog\u002Fde\u002Fwhat-is-permissions-policy","8 Minuten",{"title":8,"description":136},"what-is-permissions-policy","blog\u002Fde\u002Fwhat-is-permissions-policy",[4,134,168,169],"Web-Sicherheit","Datenschutz","q_cuWTHT0Fwcy2g5TuANtLH4yPhjojwSRC4DGe-ej4c",1785141132325]