Wer hat diesem Iframe Kamera-Zugriff gegeben? Permissions Policy richtig prüfen

Ein Termin-Widget braucht plötzlich das Mikrofon. Ein Video-Support-Tool möchte Kamera-Zugriff. Eine eingebettete Karte fragt nach dem Standort. Im Browser erscheint eine Berechtigungsabfrage – und im Team weiß niemand mehr genau, welche Seite welche Fähigkeit überhaupt erhalten sollte.

Das wird oft als reine Nutzerentscheidung behandelt: Der Browser fragt doch nach Erlaubnis, also ist alles abgesichert.

Das ist nur die halbe Wahrheit.

Die Permissions Policy ist eine zusätzliche Browser-Grenze. Sie kann festlegen, welche Dokumente und eingebetteten Frames bestimmte Funktionen wie Kamera, Mikrofon oder Geolocation überhaupt verwenden dürfen. Erst innerhalb dieser technischen Grenze greift bei sogenannten mächtigen Funktionen weiterhin die eigentliche Nutzerberechtigung des Browsers.

Die Audit-Frage lautet deshalb nicht nur: „Fragt der Browser den Nutzer?“ Sondern: „Welche Teile unserer Website dürfen diese Frage überhaupt stellen?“

Permissions Policy erteilt keine Nutzerzustimmung

Dieser Unterschied ist zentral.

Die W3C-Permissions-Spezifikation beschreibt Berechtigungen als Kontrolle des User Agents über mächtige Funktionen mit möglichen Datenschutz-, Sicherheits- und Performance-Auswirkungen. Nutzer können solche Berechtigungen erlauben, verweigern oder später wieder entziehen.

Permissions Policy sitzt davor beziehungsweise daneben. Sie begrenzt, in welchen Dokumenten eine Funktion verfügbar ist. Wenn die Policy Kamera für ein Dokument blockiert, kann dessen JavaScript nicht einfach durch einen Nutzerprompt daran vorbeikommen. Ist Kamera dagegen durch die Policy erlaubt, bedeutet das noch nicht automatisch, dass der Nutzer sie freigegeben hat.

Praktisch entstehen also zwei Fragen:

1. Darf dieses Dokument die Fähigkeit grundsätzlich nutzen? Permissions Policy.
2. Hat der Nutzer den Zugriff tatsächlich erlaubt? Browser-Permission und API-spezifische Regeln.

Wer beides vermischt, baut entweder unnötig breite technische Freigaben oder wundert sich über Widgets, die trotz sichtbarer Browser-Erlaubnis nicht funktionieren.

Kamera, Mikrofon und Geolocation sind für Cross-Origin-Frames nicht einfach offen

Die aktuellen W3C-Spezifikationen definieren für Kamera und Mikrofon eine Default-Allowlist von self. Auch Geolocation ist standardmäßig auf self begrenzt.

Das bedeutet vereinfacht: Die Top-Level-Seite und passende Same-Origin-Kontexte können die Funktion im Rahmen weiterer Bedingungen nutzen. Ein fremder Cross-Origin-Iframe erhält diese Fähigkeit nicht automatisch.

Soll ein externer Frame sie bekommen, muss die Delegation bewusst erfolgen. Typischerweise spielen zwei Ebenen zusammen:

• der Permissions-Policy-Response-Header der Seite;
• das allow-Attribut des konkreten <iframe>.

Wichtig: Das allow-Attribut kann eine restriktive Header-Policy nicht aufheben. Es wirkt als zusätzliche Begrenzung innerhalb dessen, was die übergeordnete Policy überhaupt zulässt.

Genau hier entstehen viele Integrationsfehler.

Red Flag 1: Die Policy ist ein kopierter Security-Header-Block

Viele Websites haben irgendwann einen Header-Schnipsel aus einem Security-Scanner, Blogpost oder Hosting-Template übernommen. Dann steht dort etwas wie camera=(), microphone=(), geolocation=() – ohne dass geprüft wurde, ob ein legitimes Support-, Meeting-, Upload- oder Karten-Widget diese Funktionen benötigt.

Das Ergebnis kann ein sauber aussehender Header und ein kaputter Geschäftsprozess sein.

Umgekehrt ist eine Policy wie camera=* oder microphone=* keine sinnvolle Standardlösung nur deshalb, weil danach alle Widgets wieder funktionieren. Der Stern erweitert die Policy auf alle Origins, soweit die jeweilige Funktion und der restliche Browserkontext dies zulassen. Die Nutzerberechtigung bleibt zwar eine eigene Ebene, aber die technische Delegation wird unnötig breit.

Ein guter Audit beginnt deshalb nicht mit „welcher Header bekommt den besten Score?“, sondern mit einem Fähigkeiten-Inventar.

Red Flag 2: Niemand weiß, welches Widget eine Fähigkeit braucht

Listen Sie zunächst die eingebetteten Dienste auf. Typische Kandidaten sind:

• Video- oder Support-Tools;
• Termin- und Telemedizin-Widgets;
• Karten und Standortsuche;
• Dokumentenscanner oder Kamera-Uploads;
• Sprachaufnahme und Diktat;
• WebRTC-Komponenten;
• Payment-, Identitäts- oder Verifizierungsdienste;
• eingebettete Produktdemos.

Für jeden Dienst sollte beantwortet werden:

• Welche Browser-Funktion benötigt er wirklich?
• Auf welchen Seiten wird er geladen?
• Von welchem Origin kommt der Frame?
• Ist die Funktion Kernbestandteil oder nur optional?
• Was sieht der Nutzer, wenn sie blockiert ist?
• Gibt es eine funktionierende Alternative ohne Kamera, Mikrofon oder Standort?
• Wer ist fachlich und technisch für die Integration verantwortlich?

Ein Widget sollte nicht mehr Fähigkeiten erhalten, nur weil sein Anbieter eine großzügige Beispielkonfiguration dokumentiert.

Red Flag 3: Header und iframe-allow erzählen unterschiedliche Geschichten

Stellen Sie sich vor, die Seite sendet eine Policy, die Kamera ausschließlich für self erlaubt. Gleichzeitig enthält ein externer Video-Frame allow="camera; microphone".

Die sichtbare HTML-Konfiguration wirkt so, als sei Kamera delegiert. Die übergeordnete Header-Policy kann die Fähigkeit trotzdem blockieren.

Die umgekehrte Richtung ist genauso relevant: Ein Header kann einen Partner-Origin zulassen, aber der konkrete Frame erhält die Fähigkeit nicht, wenn seine Container-Policy sie nicht passend delegiert.

Darum sollten Header und Markup gemeinsam geprüft werden. Nicht im Repository isoliert, sondern an der tatsächlich ausgelieferten Produktionsseite. Reverse Proxy, CDN, Framework-Middleware und CMS können Header verändern oder nur auf bestimmten Routen setzen.

Red Flag 4: Die Origin-Liste ist größer als der reale Integrationsbedarf

Eine Berechtigung sollte möglichst an konkrete Origins gebunden sein.

Problematisch sind beispielsweise:

• Wildcards, obwohl nur ein Anbieter-Origin benötigt wird;
• alte Anbieter-Domains nach einer Migration;
• Staging-Origins in der Produktionspolicy;
• ganze Subdomain-Bereiche, obwohl nur ein Host genutzt wird;
• nicht dokumentierte Ports oder alternative Hosts;
• Policies, die aus Konfiguration dynamisch immer weiter anwachsen.

Die aktuelle Permissions-Policy-Spezifikation definiert AllowLists explizit als Origins beziehungsweise Origin-Ausdrücke. Das ist eine gute Erinnerung daran, die Grenze technisch genauso klein zu halten wie die Geschäftsbeziehung.

Wenn Ihr Videodienst nur unter einem definierten Embed-Origin läuft, sollte die Website nicht vorsorglich jede Domain des Anbieters oder gar jede Origin freigeben.

Red Flag 5: „Der Nutzer hat doch erlaubt“ wird als Debugging-Endpunkt behandelt

Ein häufiger Supportfall lautet: „Kamera ist im Browser erlaubt, aber das Meeting funktioniert trotzdem nicht.“

Dann werden nur Betriebssystem- und Browserberechtigungen geprüft. Die Permissions Policy bleibt unsichtbar.

Bei Kamera oder Mikrofon kann getUserMedia() scheitern, wenn die Funktion durch die Policy im Dokument nicht verfügbar ist. Die Media-Capture-Spezifikation macht zudem deutlich, dass selbst ein grundsätzlich erteilter Kamerazugriff keine Garantie dafür ist, dass ein konkreter getUserMedia()-Aufruf erfolgreich sein wird – Gerätebelegung, Constraints und weitere Bedingungen können ebenfalls eine Rolle spielen.

Ein sauberer Fehlerpfad sollte deshalb unterscheiden können zwischen:

• Funktion durch Policy blockiert;
• Nutzerberechtigung verweigert;
• kein passendes Gerät vorhanden;
• Gerät bereits belegt;
• technische Constraints nicht erfüllbar;
• Drittanbieter-Frame falsch konfiguriert.

„Bitte erlauben Sie die Kamera erneut“ ist keine gute Fehlermeldung, wenn die Website selbst den Zugriff per Policy verhindert.

Red Flag 6: Legacy Feature-Policy wird weiterkopiert

Permissions Policy hieß früher Feature Policy. Dabei wurde nicht nur der Name geändert; auch die Syntax des HTTP-Headers hat sich verändert. MDN weist ausdrücklich darauf hin, alte Feature-Policy-Beispiele nicht ungeprüft auf moderne Implementierungen zu übertragen.

Bei älteren Websites lohnt sich deshalb eine Suche nach:

• Feature-Policy;
• Permissions-Policy;
• allow= auf iframes;
• Header-Konfiguration in CDN, Proxy und Hosting;
• Framework-Middleware und Security-Paketen.

Doppelte oder widersprüchliche Konfigurationen sind besonders unangenehm, weil sie je nach Route oder Infrastrukturpfad unterschiedlich wirken können.

Ein sinnvoller Rollout: erst inventarisieren, dann einschränken

Eine strenge Policy sollte nicht blind in Produktion eingeschaltet werden. Der bessere Ablauf ist:

1. Reale Fähigkeiten erfassen

Welche Features verwendet First-Party-Code? Welche benötigen eingebettete Drittanbieter? Welche existieren nur noch historisch?

2. Repräsentative Seitentypen prüfen

Startseite allein reicht nicht. Testen Sie mindestens Seiten mit Karten, Video, Support, Login, Checkout, Uploads und eingeloggten Bereichen, falls dort andere Embeds vorkommen.

3. Default-deny dort einsetzen, wo die Funktion sicher nicht gebraucht wird

Für ungenutzte Fähigkeiten kann eine leere Allowlist wie camera=() eine klare Aussage sein: Diese Seite und ihre Nachfahren sollen Kamera nicht verwenden.

4. Benötigte Delegationen eng freigeben

Wenn ein Drittanbieter-Frame Mikrofon benötigt, erlauben Sie genau den erforderlichen Origin und genau die erforderliche Funktion. Nicht die gesamte Browser-Fähigkeitspalette des Widgets.

5. Kritische Nutzerwege mit echten Browsern testen

Browserunterstützung für einzelne Permissions-Policy-Funktionen und Reporting ist nicht überall identisch. MDN kennzeichnet mehrere Direktiven weiterhin mit eingeschränkter Verfügbarkeit. Eine Policy ist deshalb nicht fertig, wenn sie in einem Browser erwartungsgemäß aussieht.

6. Reporting vorsichtig nutzen

Der aktuelle W3C-Entwurf definiert Permissions-Policy-Report-Only, und MDN dokumentiert den Header als experimentell. Damit können potenzielle Verstöße beobachtet werden, ohne sofort durchzusetzen. Das kann beim Rollout helfen, sollte aber wegen unterschiedlicher Browserunterstützung nicht die einzige Teststrategie sein.

Automatisierte Browser-Tests und manuelle Prüfungen der echten Integrationen bleiben notwendig.

Ein praktischer Audit in 25 Minuten

Öffnen Sie eine repräsentative Produktionsseite und erfassen Sie zunächst die tatsächlich gelieferten Permissions-Policy-Header. Prüfen Sie danach alle iframes und deren allow-Attribute.

Für jedes Vorkommen beantworten Sie:

1. Welche Fähigkeit wird erlaubt oder blockiert?
2. Welche Origins erhalten Zugriff?
3. Ist der Origin noch aktuell?
4. Ist die Freigabe auf dieser Route überhaupt nötig?
5. Wird dieselbe Funktion im Header und am Frame konsistent behandelt?
6. Was passiert, wenn das Widget auf einen anderen Origin weiterleitet?
7. Wie reagiert die Oberfläche bei einer blockierten Fähigkeit?
8. Kann der Nutzer den Prozess ohne diese Fähigkeit fortsetzen?
9. Existieren Staging- oder Legacy-Konfigurationen in Produktion?
10. Funktioniert die Policy in den Browsern, die reale Nutzer verwenden?

Danach provozieren Sie kontrolliert einen Fehler: Entfernen Sie in einer Testumgebung die benötigte Delegation eines Widgets und prüfen Sie, ob die Anwendung verständlich reagiert. Ein gutes System sollte nicht nur funktionieren, wenn alles erlaubt ist. Es sollte auch erklären können, warum eine Funktion nicht verfügbar ist.

Was Website-Pflichtencheck prüfen würde

Bei einem Permissions-Policy-Audit würden wir nicht einfach möglichst viele Browserfunktionen abschalten. Wir würden die Fähigkeitsgrenze der realen Website prüfen:

• tatsächlich ausgelieferte Permissions-Policy-Header über verschiedene Routen;
• Kamera-, Mikrofon- und Geolocation-Nutzung;
• iframe-allow-Attribute und konkrete Drittanbieter-Origins;
• Zusammenspiel von Header- und Container-Policy;
• veraltete Feature-Policy-Konfigurationen;
• Unterschiede zwischen Produktion, Staging und Preview;
• Fehlerverhalten, wenn eine Fähigkeit blockiert wird;
• Browser- und Gerätekompatibilität;
• Report-Only- beziehungsweise Reporting-Strategie, soweit sinnvoll unterstützt;
• Ownership und Dokumentation jeder sensiblen Capability.

Das Ziel ist nicht ein maximal langer Security-Header. Das Ziel ist eine nachvollziehbare Aussage: Diese Seite braucht diese Browser-Fähigkeit, für diesen Zweck, in diesem Frame, von diesem Origin – und sonst niemand.

Permissions Policy ist damit weniger ein Header-Häkchen als eine kleine Architekturkarte der Browser-Fähigkeiten Ihrer Website.

Wenn Sie heute nicht erklären können, warum ein Drittanbieter-Frame Kamera, Mikrofon oder Standort verwenden darf, ist genau diese Unklarheit ein guter Anlass für einen technischen Website-Check.