Sicherheits-Ratgeber
Permissions-Policy, verständlich erklärt
Kamera, Mikrofon, Standort und Bezahlfunktion stehen im Browser jeder Seite offen, solange Sie nichts anderes sagen, und das schließt alles ein, was Ihre Seiten einbetten. Dieser Ratgeber erklärt die Syntax der Positivliste, die Funktionen, die Sie nennen sollten, und den Fehler, der einen Header gesetzt aussehen lässt, obwohl er nichts bewirkt.
01 Warum es wichtig ist
Die Berechtigung, nach der niemand Sie gefragt hat
Ein Browser gibt die Kamera nicht heraus, ohne den Besucher zu fragen, und deshalb wirkt die Permissions-Policy schnell wie eine Kür. Der Dialog ist aber nur die halbe Geschichte. Er regelt, wer gefragt wird, nicht, wer fragen darf, und von Haus aus darf alles fragen, was auf Ihrer Seite läuft: Ihre eigenen Skripte, ein Widget von Dritten, ein Werbe-Iframe, ein Chat-Werkzeug, das letztes Jahr den Besitzer gewechselt hat. Jedes davon kann Ihren Besuchern einen Berechtigungsdialog mit Ihrer Domain im Titel vorlegen.
Der Header verlagert diese Entscheidung vom Besucher zu Ihnen. Funktionen, die Ihre Website nicht nutzt, sind abgeschaltet, bevor überhaupt jemand danach fragen kann; damit entfallen der Dialog und das Risiko, dass ihn jemand bestätigt. Günstiger wird Härtung nicht: nichts zu pflegen, und der sichere Zustand ist die Voreinstellung.
02 Die Syntax
Vier Positivlisten zur Auswahl
camera=()
Was er bewirkt. Eine leere Positivliste. Die Funktion ist für Ihre eigenen Seiten und für jeden eingebetteten Frame abgeschaltet, ein Dialog lässt sich gar nicht erst auslösen.
Warum er wichtig ist. Das ist der Wert für alles, was Sie nicht nutzen. Es ist keine Anfrage, die der Browser doch noch gewähren könnte: die Programmierschnittstelle ist schlicht nicht vorhanden.
camera=(), microphone=() geolocation=(self)
Was er bewirkt. Erlaubt die Funktion nur auf Ihrer eigenen Domain. Eingebettete Frames fremder Domains bleiben ausgeschlossen, auch wenn sie fragen.
Warum er wichtig ist. Der richtige Wert für eine Funktion, die Ihre eigenen Seiten wirklich brauchen. Ein kompromittierter fremder Inhalt kommt trotzdem nicht daran.
geolocation=(self) payment=(self "https://pay.example.com")
Was er bewirkt. Erlaubt Ihre eigene Domain und die Domains, die Sie nennen. Jede Domain steht in Anführungszeichen, die Einträge werden durch Leerzeichen getrennt.
Warum er wichtig ist. So bekommt ein Zahlungs- oder Videoanbieter, was er braucht, ohne die Funktion für alles andere zu öffnen, was Sie einbetten.
payment=(self "https://pay.example.com") fullscreen=*
Was er bewirkt. Erlaubt die Funktion überall, auch in jedem eingebetteten Frame.
Warum er wichtig ist. Für etwas Harmloses wie Vollbild auf einer Videoseite vertretbar und die falsche Antwort für alles, was an einen Sensor oder eine Bezahlfunktion reicht. Im Zweifel nennen Sie lieber die Domains.
fullscreen=*03 Einführung
Nennen Sie jede Funktion, die aus sein soll
Der Header ist eine Zeile im server-Block, in der Funktion und Wert paarweise durch Kommas getrennt stehen. Eine Funktion, die Sie nicht aufführen, behält die Voreinstellung des Browsers, und die erlaubt sie üblicherweise Ihrer eigenen Domain. Ein kurzer Header ist also kein strenger. Gehen Sie von den Funktionen aus, die Sie tatsächlich nutzen, schalten Sie den Rest namentlich ab und laden Sie neu.
server { add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(), usb=()" always; }Prüfen Sie die ausgelieferte Antwort und nicht die Konfigurationsdatei. Einen Funktionsnamen, den er nicht kennt, überspringt der Browser stillschweigend, ein Tippfehler sieht deshalb genauso aus wie ein wirksamer Header. Unser Scan liest den Header so, wie er ankommt.
04 Fragen
Was zu Berechtigungen gefragt wird
Ist das dasselbe wie der alte Feature-Policy-Header?
Er löst ihn ab. Feature-Policy nutzte eine andere Syntax und ist nicht mehr der Standard; aktuelle Browser lesen Permissions-Policy. Wer nur den alten Header sendet, sendet nichts, was heute noch zählt.
Brauche ich ihn, wenn meine Website die Kamera nie anfragt?
Genau dann ist er am günstigsten. Dass Ihr eigener Code nicht fragt, sagt nichts über die Skripte und Iframes Dritter auf derselben Seite. Der Header macht aus "wir nutzen das nicht" eine Regel, die der Browser durchsetzt, statt einer Absichtserklärung.
Was passiert mit einem Iframe, dessen Funktion abgeschaltet ist?
Die Schnittstelle steht darin nicht zur Verfügung, der Aufruf scheitert, als kenne der Browser die Funktion nicht. Es stürzt nichts ab, aber ein Widget, das die Funktion wirklich braucht, hört auf zu arbeiten, und deshalb nennen Sie die Domains, die sie behalten sollen.
Macht ein unbekannter Funktionsname den Header kaputt?
Nein, der Browser überspringt den Eintrag, den er nicht kennt, und wendet den Rest an. Für neue Funktionen ist das praktisch, für Tippfehler unpraktisch, prüfen Sie deshalb gegen die Antwort statt gegen die Datei.
05 Im Detail
Verwandte Sicherheitsthemen
Berechtigungen regeln, worauf eine Seite zugreifen darf. Diese Ratgeber behandeln, was sie laden darf und wer sie einbetten darf.
HTTP-Security-Header
Was jeder Response-Header bewirkt, welche Ihre Website senden sollte und wie Sie sie richtig konfigurieren.
Content Security Policy
Der stärkste Schutz gegen Cross-Site-Scripting: welche Direktiven Sie setzen, wie Sie eine Richtlinie im Report-Only-Modus einführen und wie Sie erzwingend werden, ohne Ihre Website zu zerlegen.
HSTS
Strict-Transport-Security erklärt: was max-age, includeSubDomains und preload wirklich bewirken und warum die Preload-Liste eine Entscheidung ist, die Sie nicht schnell zurücknehmen können.
Cookie-Sicherheit
Secure, HttpOnly und SameSite: die Cookie-Attribute, die eine Sitzung vor Skripten und fremden Seiten schützen, samt Einstellungen für einen typischen Stack.
Clickjacking und X-Frame-Options
Wie eine unsichtbare Überlagerung aus einem Besucherklick eine Aktion auf Ihrer Website macht, und die zwei Header, die das verhindern: X-Frame-Options für ältere Clients, frame-ancestors für alles andere.
Referrer-Policy
Welcher Teil Ihrer URLs an fremde Seiten geht, wenn ein Besucher weiterklickt: die fünf Werte, die zählen, was jeder davon preisgibt und welcher der sinnvolle Standard ist.
SPF, DMARC und DNSSEC
Die Einträge, die verhindern, dass jemand in Ihrem Namen Mails verschickt, und der, der Ihre DNS-Antworten ehrlich hält: was jeder leistet und in welcher Reihenfolge Sie sie einführen.
security.txt
Die Datei, die Sicherheitsforschern sagt, wohin eine Schwachstelle gemeldet wird. Zwei Pflichtfelder, zehn Minuten Arbeit, und der Unterschied zwischen einer privaten und einer öffentlichen Meldung.
Security-Header überwachen
Ein Header, der heute stimmt, kann nach dem nächsten Deploy fehlen. Drei Wege, das zu bemerken: ein Cronjob mit curl, eine Prüfung in Ihrer CI-Pipeline und ein geplanter Scan, jeweils mit dem, was er findet und was nicht.
CSP-Änderungen erkennen
Wie sich eine Richtlinie durch Deploys, Plugins und CDN-Regeln unbemerkt ändert und wie Sie es merken: ein Header-Diff, Verstoßmeldungen über report-to und was ein Scan-Vergleich zeigen kann und was nicht.
Weiterlesen
Weitere Ratgeber
Jeder Ratgeber steht für sich, zusammen decken sie ab, worauf unser Scanner schaut. Wählen Sie den, der Ihrer nächsten Frage am nächsten kommt.
Sehen Sie, welche Funktionen Ihre Website offen lässt
Unser kostenloser Quickscan liest Ihre Permissions-Policy aus der ausgelieferten Antwort, zusammen mit dem Rest Ihrer Security-Header, und erklärt jeden Befund verständlich.