Was es tut
Der HTTP-Header Permissions-Policy sagt dem Browser, welche mächtigen Web-Features deine Seite - und jedes eingebettete iframe - nutzen darf. Kamera, Mikrofon, Geolocation, Sensoren, USB, Screen-Sharing: Standardmäßig steht jedes davon deiner eigenen Origin zur Verfügung und wartet darauf, dass ein Skript darum bittet.
Dieses Tool verwandelt den Header von einer handgetippten Zeichenkette in einen strukturierten Direktiven-Editor. Jene Direktivenkarte benennt ein Feature - bekannte Features tragen ein Privacy-Impact-Badge (hoch / mittel / niedrig) und eine Notiz, was das Feature tut - und wählt eine Allowlist: überall erlauben (*), nur gleiche Origin (self), komplett deaktiviert (()) oder eine eigene Origin-Liste. Der Header baut sich live neben den Steuerelementen selbst zusammen. Füge einen bestehenden Header ein, um ihn zu laden und zu bearbeiten.
So verwendest du es
- Starte mit einem Preset - All deny (jedes Katalog-Feature deaktiviert), Camera self (
camera=(self)) oder Fullscreen * (fullscreen=*). - Bearbeite die Direktivenkarten - tippe einen Feature-Namen, wähle seine Allowlist (
Off/Self/All/Origins) und gib fürOriginseine leerzeichengetrennte Origin-Liste an. Füge Direktiven frei hinzu oder entferne sie. - Füge einen bestehenden Header ein - klapp das Import-Panel aus, füge deinen aktuellen
Permissions-Policy-Wert ein, und Parse & load holt ihn in den Editor (Header-Namenspräfix und quotete Origins werden behandelt; fehlerhafte Eingaben werden gemeldet). - Kopieren oder herunterladen - kopiere den Header für deine Server-/CDN-Konfiguration oder lade ihn als
permissions-policy.txtherunter. - Teile das Setup - deine ganze Direktivenliste ist in der Seiten-URL codiert; kopiere die Adresse, um jemandem die exakte Policy zu übergeben.
Beispiele
Ein strenger Standard für eine Seite, die keine dieser APIs braucht:
camera=(), display-capture=(), geolocation=(), hid=(), idle-detection=(),
microphone=(), serial=(), usb=(), xr-spatial-tracking=()Ein Video-Partner eingebettet, der Kamera + Mikrofon nur im eigenen Frame braucht:
camera=(https://partner.example.com), geolocation=(), microphone=(https://partner.example.com)Fullscreen und Payment für dich selbst behalten, alles andere verriegelt:
fullscreen=(self), payment=(self)Gut zu wissen
- Live-Validierung - das Tool markiert doppelte Direktiven (nur die letzte überlebt im Header),
*auf dem sensiblen Trio (camera,geolocation,microphone- jede Origin bekommt den Hardware-Prompt) und Namen außerhalb des Katalogs (Tippfehler oder ein Feature, das Browser noch nicht kennen - wird still ignoriert). - Warum Features sperren, die du nie nutzt? Ein deaktiviertes Feature kann von einer kompromittierten Abhängigkeit, einem Schad-Skript aus Werbung oder einem injizierten iframe nicht wieder aktiviert werden. Es verkleinert auch deine Fingerprinting-Oberfläche - Sensor- und Battery-APIs sind klassische Tracking-Vektoren.
- Feature Detection funktioniert weiter. Skripte, die
navigator.mediaDevicesbei einem deaktivierten Feature aufrufen, bekommen einen abgelehnten Promise statt eines Prompts - setzeallow="camera"nur auf die spezifischen iframes, die ihn brauchen. - Das ist kein CSP. Die Content-Security-Policy kontrolliert, welche Inhalte geladen werden; die Permissions-Policy kontrolliert, welche Hardware/APIs genutzt werden dürfen. Shippe beide.
- 100 % clientseitig - der Header wird in deinem Browser gebaut; nichts wird hochgeladen.
- Verwandte Tools: CSP Builder, Basic Auth Generator.