Permissions-Policy: Kamera, Mikrofon und Standort sperren

Was die Permissions-Policy regelt

Die Spezifikation beschreibt einen Mechanismus, mit dem Entwickler einzelne Browserfunktionen und Schnittstellen gezielt ein- und ausschalten können (W3C). Jede dieser Funktionen trägt ein Kürzel, etwa camera, microphone, geolocation oder payment, und heißt dort policy-controlled feature. Bis zur Umbenennung hieß der Mechanismus Feature Policy. Der alte Kopf Feature-Policy gilt als veraltet und verliert laut Web Almanac weiter an Verbreitung (Web Almanac 2025). Die Spezifikation selbst steht beim W3C noch als Arbeitsentwurf (Working Draft); umgesetzt ist der Header bisher in Chromium-basierten Browsern, dazu weiter unten mehr.

Für das Verständnis entscheidend ist die Voreinstellung jeder Funktion, in der Spezifikation Default-Allowlist genannt. Sie greift, solange kein Header etwas anderes sagt. Für Kamera und Mikrofon lautet sie self (W3C Media Capture), für den Standort ebenso (W3C Geolocation). self heißt: Die Seite selbst und Rahmen vom selben Ursprung dürfen die Funktion anfragen, Rahmen fremder Ursprünge dagegen nicht (W3C). Ein eingebettetes Video von einer anderen Domain kann also auch ohne Header nicht einfach die Kamera öffnen, solange niemand es ausdrücklich freigibt.

Die Permissions-Policy ersetzt nicht die Abfrage des Browsers beim Besucher, sie liegt davor. Ist eine Funktion per Policy gesperrt, scheitert der Aufruf, ohne dass jemand gefragt wird: Bei gesperrter Kamera lehnt getUserMedia() mit einem NotAllowedError ab (MDN). Umgekehrt ersetzt eine Freigabe in der Policy nicht die Zustimmung des Besuchers. Heikel ist ein Detail aus der Spezifikation: Weil Browser Berechtigungen in der Regel der obersten Domain zuordnen, kann ein freigegebener Rahmen Kamera oder Mikrofon unter Umständen ohne weitere Nachfrage nutzen, wenn der Besucher Ihrer Seite die Kamera bereits erlaubt hat (W3C). Eine Freigabe an einen Rahmen reicht also das Vertrauen weiter, das der Besucher Ihrer Domain entgegengebracht hat.

Die Permissions Policy ist standardmäßig offen: Wer die Nutzung einer Funktion einschränken will, muss sie im Header ausdrücklich nennen.

— HTTP Archive, Web Almanac 2025, Kapitel Security (übersetzt)

Wie selten diese Arbeit bisher gemacht wird, zeigt die Messung des HTTP Archive: Der Anteil der Websites mit Permissions-Policy ist gegenüber dem Vorjahr zwar deutlich gewachsen, liegt mobil aber bei 3,7 Prozent (Web Almanac 2025). Moderne Köpfe wie Permissions-Policy und Cross-Origin-Opener-Policy stehen damit laut dem Bericht noch am Anfang ihrer Verbreitung. Einen Überblick über alle Sicherheitsköpfe und ihre Aufgaben gibt der Beitrag HTTP Security Headers erklärt.

Header und allow-Attribut: zwei Schalter, die beide zustimmen müssen

Die Permissions-Policy kennt zwei Orte. Der Header Permissions-Policy kommt mit der Antwort des Servers und gilt für das Dokument und alles, was darin eingebettet ist (W3C). Das allow-Attribut steht am einzelnen <iframe> und bestimmt, was genau dieser Rahmen bekommt. Für einen Rahmen mit fremdem Ursprung gilt eine Funktion nur dann als freigegeben, wenn beide Stellen zustimmen: Der Header der Seite muss den Ursprung des Rahmens zulassen, und das allow-Attribut muss die Funktion für diesen Rahmen nennen (W3C).

Daraus ergibt sich eine klare Rollenverteilung. Der Header ist die Obergrenze, die kein Rahmen überschreiten kann, auch keiner, den ein eingeschleustes Skript nachträglich in die Seite setzt. Die Spezifikation beschreibt genau diesen Fall: Mit geolocation=(self "https://example.com") erhalten nur die eigene Seite und Rahmen von example.com den Standort, selbst wenn ein Angreifer eigene Rahmen einbetten kann (W3C). Das allow-Attribut ist die Freigabe im Einzelfall. Eine leere Liste im Header, also camera=(), sperrt die Funktion für alle Dokumente einschließlich aller eingebetteten, unabhängig von ihrem Ursprung (W3C).

Die folgende Übersicht zeigt, was ein Rahmen von video.example laut Policy bekommt, wenn er auf einer Seite von shop.example eingebettet ist. Die Abfrage beim Besucher kommt bei einer Freigabe noch hinzu.

Wie verbreitet das Attribut ist, misst ebenfalls der Web Almanac: Von 33,3 Millionen iframes in der mobilen Messung tragen 29,2 Prozent ein allow-Attribut (Web Almanac 2025). Die häufigsten Einträge darin sind encrypted-media und autoplay, also Funktionen der Medienwiedergabe (Web Almanac 2025). Solche Einträge kommen in der Regel mit dem Einbettungscode des Anbieters auf die Seite. Wer den Code übernimmt, übernimmt die Freigaben mit, und es lohnt sich, sie einmal zu lesen, bevor sie live gehen.

<!-- Video: Wiedergabe ja, Kamera und Mikrofon nein -->
<iframe src="https://video.example/embed/123"
        allow="autoplay; encrypted-media; fullscreen; picture-in-picture"></iframe>

<!-- Zahlung: Payment Request und Passkey-Bestätigung für den Zahlungsdienst -->
<iframe src="https://pay.example/checkout"
        allow="payment; publickey-credentials-get"></iframe>

<!-- Karte: kein Standort, die Adresse gibt der Besucher selbst ein -->
<iframe src="https://karte.example/embed?ort=filiale"></iframe>

Ein Sonderfall ist das ältere Attribut allowfullscreen. Es gibt Vollbild an jeden Ursprung frei, der in den Rahmen geladen wird. Steht fullscreen dagegen im allow-Attribut, hat allowfullscreen keine Wirkung mehr (W3C).

Inventur: Welcher Rahmen braucht welche Funktion?

Bevor eine Zeile in die Serverkonfiguration wandert, steht die Inventur. Gefragt ist zweierlei: Welche Funktionen nutzt die eigene Seite selbst, und welche Rahmen bindet sie mit welchem Zweck ein? Auf einer typischen Unternehmens- oder Shopseite kommen dabei vier Gruppen von Rahmen zusammen.

Hinzu kommen die eigenen Funktionen der Seite. Ein Filialfinder, der den Standort des Besuchers abfragt, braucht geolocation=(self). Eine Anmeldung mit Passkeys braucht publickey-credentials-get für die eigene Seite. Die folgende Tabelle fasst die Kürzel zusammen, die auf Firmen- und Shopseiten am ehesten eine Rolle spielen; die Beschreibungen folgen der Referenz von MDN (MDN).

Nicht jede Drittkomponente steckt in einem Rahmen. Ein Chat-Widget oder ein Tag, das als Skript direkt in die Seite geladen wird, läuft im Dokument der Seite und teilt deren Rechte: Für dieses Skript gilt, was der Header für die eigene Seite erlaubt, ein allow-Attribut gibt es dafür nicht. Wer camera=(self) setzt, gibt die Kamera damit auch jedem eingebundenen Skript frei. Welche Skripte das sind und wie sich ihr Risiko eingrenzen lässt, beschreibt der Beitrag zu Third-Party-Scripts als Sicherheitsrisiko.

Wer viele Websites betreut, führt diese Liste sinnvollerweise zusammen mit dem übrigen Inventar der Seiten: Domains, Software, Zuständigkeiten, eingebettete Dienste. Wie ein solches Inventar bei einer akuten Lücke den Unterschied macht, zeigt der Beitrag zu PHP2Shell und dem Website-Inventar. Für die Permissions-Policy reicht eine Zeile je Seite: Rahmen, Ursprung, Zweck, benötigte Funktionen.

payment und publickey-credentials-get nicht blind sperren

Im Netz kursieren Sammelvorlagen, die in einem Zug fast alles abschalten, was ein Browser kennt. Eine davon ist im Web Almanac gut sichtbar: Eine lange Liste, die unter anderem camera=(), microphone=(), geolocation=(), payment=() und publickey-credentials-get=() setzt, steht in 10 Prozent der mobil gemessenen Permissions-Policy-Header (Web Almanac 2025). Für eine Seite ohne Bezahlweg und ohne Passkey-Anmeldung mag das passen. Für einen Shop kann genau diese Zeile den Abschluss verhindern.

payment steuert die Payment Request API, über die der Browser den Bezahlvorgang zwischen Shop und Käufer vermittelt (W3C Payment Request). Die Voreinstellung ist self; in einem fremden Rahmen funktioniert die Schnittstelle nur mit allow="payment" (W3C Payment Request). Ist die Funktion gesperrt, scheitert schon das Anlegen einer Zahlungsanfrage mit einem Fehler (W3C Payment Request). Auch die Zahlungsbestätigung mit Passkey, die das W3C als Secure Payment Confirmation beschreibt, hängt an derselben Freigabe (W3C SPC).

publickey-credentials-get steuert den Abruf vorhandener Passkeys über die Web Authentication API (MDN). Die Empfehlung WebAuthn Level 3 legt für diese Funktion und für publickey-credentials-create die Voreinstellung self fest und hält fest: Ist die Funktion in einem Dokument gesperrt, darf kein Inhalt dieses Dokuments die Methoden nutzen (W3C WebAuthn). In fremden Rahmen ist die Schnittstelle ohne allow-Attribut ohnehin abgeschaltet (W3C WebAuthn). Eine leere Liste im Header sperrt dagegen auch die eigene Seite. Wer publickey-credentials-get=() setzt und zugleich eine Anmeldung mit Passkeys anbietet, legt die eigene Anmeldung still.

Tragfähiger als die Sperre ist die gezielte Freigabe: Die eigene Seite und der Zahlungsdienst dürfen, alle anderen nicht. Im Header heißt das payment=(self "https://pay.example") und publickey-credentials-get=(self "https://pay.example"), am Zahlungsrahmen steht allow="payment; publickey-credentials-get". Welche Ursprünge der Zahlungsdienst verwendet, gehört aus dessen Dokumentation übernommen, nicht geraten. Öffnet der Dienst die Bestätigung der Bank in einem eigenen Rahmen direkt in Ihrer Seite, kommt ein weiterer Ursprung hinzu, den die Liste kennen muss. Das ist ein Grund mehr, den Bezahlweg mit Testdaten im Testmodus des Anbieters durchzuspielen, bevor der Header live geht.

Die Kopfzeile richtig schreiben

Der Header ist ein strukturiertes Feld nach RFC 8941, genauer ein Dictionary (W3C). Jede Funktion steht mit ihrer Allowlist in Klammern, mehrere Funktionen werden durch Kommas getrennt (MDN). In der Praxis kommen drei Formen vor:

• camera=(): leere Liste, gesperrt für die Seite und alle Rahmen.
• geolocation=(self): nur die Seite selbst und Rahmen vom selben Ursprung.
• payment=(self "https://pay.example"): die Seite und ein benannter fremder Ursprung, der in Anführungszeichen steht.

Am allow-Attribut gelten andere Schreibregeln: Funktionen werden durch Semikolons getrennt, Ursprünge stehen ohne Anführungszeichen, und fehlt die Angabe, gilt der Ursprung aus dem src-Attribut des Rahmens (MDN). Wer die Schreibweisen vertauscht, erzeugt Einträge, die der Browser stillschweigend übergeht.

Schwerer wiegt ein Fehler, der die ganze Zeile unlesbar macht. Lässt sich der Header nicht als Dictionary lesen, behandelt der Browser ihn so, als gäbe es ihn nicht (W3C). Ein typischer Auslöser ist die alte Feature-Policy-Schreibweise wie camera 'none', gesendet unter dem neuen Namen. Unbekannte Funktionsnamen dagegen überspringt der Browser einzeln, der Rest der Zeile bleibt wirksam (W3C). Eine veraltete Direktive in der Liste schadet also nicht, eine falsche Syntax schon.

Das Gegenteil einer Sperre ist der Platzhalter *: Er lässt eine Funktion für jeden Ursprung zu und hebt damit die Obergrenze des Headers auf. Ein Rahmen mit fremdem Ursprung braucht für Kamera, Mikrofon oder Standort trotzdem ein allow-Attribut, denn ohne Freigabe am Rahmen bleibt es bei der Voreinstellung self (W3C). In der Desktop-Messung setzen 0,27 Prozent der Permissions-Policy-Header diesen Platzhalter, in der mobilen Messung kam er nicht vor (Web Almanac 2025). In eine Zeile gehört er nur, wenn die Freigabe für alle Ursprünge wirklich gewollt ist.

# Im server-Block: gilt für jede location ohne eigenes add_header
add_header Permissions-Policy 'camera=(), microphone=(), geolocation=(self), payment=(self "https://pay.example"), publickey-credentials-get=(self "https://pay.example")' always;

# Achtung: Ein add_header in einer location ersetzt die geerbten Zeilen.
location /filialen/ {
    add_header Cache-Control "no-cache";
    add_header Permissions-Policy 'camera=(), microphone=(), geolocation=(self)' always;
}

Bei nginx lauert eine Falle, die mit der Permissions-Policy selbst nichts zu tun hat: add_header-Zeilen werden nur dann von der übergeordneten Ebene geerbt, wenn auf der aktuellen Ebene keine eigene add_header-Zeile steht (nginx). Eine einzige Cache-Anweisung in einer location lässt dort alle Sicherheitsköpfe verschwinden, wenn sie nicht wiederholt werden. Neuere nginx-Versionen bieten mit add_header_inherit eine Möglichkeit, dieses Verhalten umzustellen (nginx). Der Parameter always sorgt dafür, dass der Kopf unabhängig vom Statuscode mitgeht, also auch auf Fehlerseiten (nginx). In Apache, Caddy, IIS oder Node/Express gilt dasselbe Prinzip: Der Kopf muss auf jeder Antwort ankommen, auf der er wirken soll.

Schrittweise einführen statt auf einen Schlag

Eine Permissions-Policy lässt sich nicht wie ein Schalter umlegen, ohne vorher zu wissen, was sie bricht. Sinnvoll ist ein Ablauf in Stufen, ähnlich wie bei HSTS, wo der Wert ebenfalls erst beobachtet und dann angehoben wird; die Parallele beschreibt der Beitrag zu den Voraussetzungen für HSTS-Preload.

1. Inventur abschließen. Eigene Funktionen und alle Rahmen mit Ursprung und Zweck erfassen, wie oben beschrieben.
2. Erst beobachten. Die Spezifikation sieht einen Kopf Permissions-Policy-Report-Only vor, der Verstöße meldet, ohne sie durchzusetzen (W3C). Chrome unterstützt ihn laut den Kompatibilitätsdaten von MDN ab Version 120, als experimentelle Funktion (MDN). Berichte gehen an einen Endpunkt, den der Kopf Reporting-Endpoints benennt, oder lassen sich in der Seite mit einem ReportingObserver mitlesen (MDN).
3. Sperren, was niemand braucht. Zuerst die Funktionen, die laut Inventur weder die Seite noch ein Rahmen nutzt, typischerweise camera, microphone, display-capture, usb oder serial. Diese Zeile bricht in der Regel nichts.
4. Gezielt freigeben. Für jede benötigte Funktion den eigenen Ursprung und die Ursprünge der Rahmen im Header nennen und am jeweiligen Rahmen das passende allow setzen.
5. Durchspielen. Bezahlweg, Anmeldung, Videos, Karte und Chat auf der Testumgebung in einem Chromium-basierten Browser testen, erst dann live schalten.
6. Messen statt vermuten. Nach dem Rollout prüfen, ob der Header auf allen Antworten ankommt, auch auf Unterseiten aus eigenen location-Blöcken und auf Fehlerseiten.

Die zweite Abfrage zeigt das Muster aus dem nginx-Beispiel: Auf der Unterseite fehlt der Kopf, weil ihre location eigene add_header-Zeilen trägt und die Permissions-Policy dort nicht wiederholt wurde. Wer nicht zur Kommandozeile greifen will, sieht alle Kopfzeilen der letzten Antwort im kostenlosen HTTP-Header-Check.

Bei der Prüfung hilft es zu wissen, wer den Header überhaupt auswertet. Laut den Kompatibilitätsdaten von MDN tut das Chrome ab Version 85, Firefox und Safari werten ihn nicht aus (MDN). Das allow-Attribut am Rahmen verstehen dagegen alle drei: Firefox ab Version 74, Safari ab Version 11.1, Safari allerdings nicht für jede Funktion, etwa nicht für den Standort (MDN). Daraus folgt eine praktische Regel: Die Freigabe am Rahmen ist die Stelle, die browserübergreifend wirkt, der Header die zusätzliche Obergrenze in Chromium-basierten Browsern. Auf das eine zu verzichten, weil das andere gesetzt ist, verschenkt Schutz.

Was die Permissions-Policy nicht leistet

Die Policy regelt Gerätefunktionen und Schnittstellen, nicht das Laden von Inhalten. Welche Skripte, Rahmen und Verbindungen eine Seite überhaupt zulässt, bestimmt die Content-Security-Policy; wie sie aufgebaut wird, zeigt der Beitrag Content Security Policy richtig konfigurieren. Ein Skript, das Formulareingaben abgreift, braucht weder Kamera noch Standort. Gegen solches Web-Skimming hilft die Permissions-Policy nicht.

Was sie leistet, beschreibt das OWASP-Projekt knapp: Sie verhindert, dass eine eingeschleuste Schwachstelle wie ein XSS Kamera, Mikrofon oder andere Browserfunktionen aktiviert (OWASP). Die Empfehlung dort lautet, alle Funktionen abzuschalten, die die Seite nicht braucht, oder sie nur für berechtigte Ursprünge freizugeben (OWASP). Zusammen mit der Trennung der Fenster durch COOP und den übrigen Cross-Origin-Köpfen, beschrieben in COOP, COEP und CORP richtig setzen, entsteht ein Bild, in dem jeder Kopf eine eigene Aufgabe hat.

Für den Datenschutz ist die Policy ein Baustein, kein Nachweis. Art. 25 Abs. 2 DSGVO verlangt Voreinstellungen, die sicherstellen, dass grundsätzlich nur die für den jeweiligen Zweck erforderlichen personenbezogenen Daten verarbeitet werden (DSGVO). Wer den Standort sperrt, wo ihn kein Zweck verlangt, setzt diesen Gedanken technisch um. Ob ein eingebetteter Dienst schon vor der Einwilligung Daten überträgt, beantwortet die Policy dagegen nicht; dafür braucht es eine Messung der Anfragen beim Seitenaufruf, wie sie die DSGVO-Prüfung von XICTRAQ® vornimmt.

Permissions-Policy im Security-Scan von XICTRAQ®

Der Security-Scan von XICTRAQ® liest die Kopfzeilen der Antwort, die der Browser anzeigt, und vergibt für eine vorhandene Permissions-Policy 8 von 100 Punkten des Security-Scores (XICTRAQ-Handbuch). Fehlt der Header, steht der Befund „Permissions-Policy Header fehlt“ in der Liste. Die Punktevergabe und eine nginx-Vorlage, die Kamera, Mikrofon und Standort sperrt, finden sich im Handbuch zu den Security-Headern.

Nützlich ist der Scan vor allem im Verlauf. Ein manuell gestarteter Scan hält im Changelog fest, wenn der Header hinzugekommen oder weggefallen ist. Unterschreitet der Score den eingestellten Mindestwert, meldet XICTRAQ® das über die eingerichteten Benachrichtigungskanäle. Wöchentlich fasst eine Zusammenfassung den Score und die Kern-Header je Website in Klartext zusammen, die Permissions-Policy eingeschlossen. Wer eingebettete Drittskripte zusätzlich auf unbemerkte Änderungen überwachen will, findet das in der Skript-Integritätsprüfung.

Erst freigeben, was gebraucht wird

Die Permissions-Policy ist kein Kopf, den man einmal aus einer Vorlage übernimmt. Sie ist die schriftliche Antwort auf die Frage, welche Gerätefunktionen Ihre Seite und jeder eingebettete Anbieter bekommen sollen. Die Antwort beginnt mit der Inventur, sperrt zuerst das Unstrittige, gibt Bezahlweg und Anmeldung gezielt frei und wird gemessen, nachdem sie live ist. Kamera, Mikrofon und Standort sind dabei die einfachen Fälle: Wo die Inventur keinen Dienst zeigt, der sie braucht, kostet die Sperre eine Zeile.