Schützen Sie Ihre Website mit Feature-Richtlinien

Eine der Funktionen der Webplattform, die auf dem letzten Chrome Dev Summit hervorgehoben wurde, war die Funktionsrichtlinie, die darauf abzielt, „Website-Autoren zu ermöglichen, die Verwendung verschiedener Browserfunktionen und APIs selektiv zu aktivieren und zu deaktivieren“. In diesem Artikel werde ich anhand einiger praktischer Beispiele einen Blick darauf werfen, was das für Webentwickler bedeutet.

In seinem Einführungsartikel auf der Google Developers-Website beschreibt Eric Bidelman die Funktionsrichtlinie wie folgt:

„Die Feature-Richtlinien selbst sind kleine Opt-in-Vereinbarungen zwischen Entwickler und Browser, die dazu beitragen können, unsere Ziele beim Erstellen (und Warten) hochwertiger Web-Apps zu fördern.“

Die Spezifikation wurde bei Google im Rahmen der Aktivität der Web Platform Incubator Group entwickelt. Das Ziel der Funktionsrichtlinie besteht darin, dass wir als Webentwickler unsere Nutzung einer Webplattformfunktion ausdrücklich gegenüber dem Browser angeben können. Dadurch treffen wir eine Vereinbarung über unsere Nutzung oder Nichtnutzung dieser bestimmten Funktion. Auf dieser Grundlage kann der Browser bestimmte Funktionen blockieren oder uns melden, dass eine Funktion verwendet wird, die er nicht erwartet hat.

Beispiele könnten sein:

1. Ich binde einen Iframe ein und möchte nicht, dass die eingebettete Website auf die Kamera meines Besuchers zugreifen kann;
2. Ich möchte Situationen abfangen, in denen nicht optimierte Bilder über das CMS auf meiner Website bereitgestellt werden.
3. An meinem Projekt arbeiten viele Entwickler, und ich würde gerne wissen, ob sie veraltete APIs wie document.write verwenden.

All diese Dinge können als Teil der Funktionsrichtlinie verfolgt, blockiert oder gemeldet werden.

So verwenden Sie die Funktionsrichtlinie

Um die Funktionsrichtlinie zu verwenden, muss der Browser zwei Dinge wissen: für welche Funktion Sie eine Richtlinie erstellen und wie diese Funktion gehandhabt werden soll.

 Feature-Policy: <directive> <allowlist>

Die <directive> ist der Name der Funktion, für die Sie die Richtlinie festlegen.

Die aktuelle Liste der Funktionen (aus der Präsentation auf dem Chrome Dev Summit) lautet wie folgt:

• Beschleunigungsmesser
• Umgebungslichtsensor
• automatisches Abspielen
• Kamera
• Dokument schreiben
• verschlüsselte Medien
• Vollbild
• Geolokalisierung
• Gyroskop
• Layout-Animationen
• faul
• Legacy-Bildformate
• Magnetometer
• Midi-
• übergroße Bilder
• Zahlung
• Bild im Bild
• Lautsprecher
• Sync-Skript
• sync-xhr
• nicht optimierte Bilder
• undimensionierte Medien
• USB
• vertikal scrollen
• vr

Die <allowlist> beschreibt, wie die Funktion verwendet werden kann – falls überhaupt – und nimmt einen oder mehrere der folgenden Werte an.

• *
  Die liberalste Richtlinie, die besagt, dass das Feature in diesem Dokument und allen IFrames, ob von dieser Domäne oder anderswo, zulässig ist. Darf nur als einzelner Wert verwendet werden, da es keinen Sinn macht, alles zu aktivieren und z. B. auch eine Liste von Domänen zu übergeben.
• self
  Die Funktion ist im Dokument und allen Iframes verfügbar, die Iframes müssen jedoch denselben Ursprung haben.
• src
  Gilt nur bei Verwendung eines allow -Zulassungsattributs. Dies ermöglicht eine Funktion, solange das darin geladene Dokument vom selben Ursprung stammt wie die URL im src-Attribut des Iframes.
• none
  Deaktiviert die Funktion für das Dokument und alle verschachtelten iFrames. Darf nur als Einzelwert verwendet werden.
• <origin(s)>
  Die Funktion ist für bestimmte Ursprünge zulässig; Das bedeutet, dass Sie eine Liste von Domänen angeben können, in denen die Funktion zulässig ist. Die Liste der Domänen ist durch Leerzeichen getrennt.

Es gibt zwei Methoden, mit denen Sie Funktionsrichtlinien auf Ihrer Website aktivieren können: Sie können einen HTTP-Header senden oder das allow -Attribut in einem Iframe verwenden.

HTTP-Header

Das Senden eines HTTP-Headers bedeutet, dass Sie eine Funktionsrichtlinie für die Seite oder die gesamte Website aktivieren können, die diesen Header sowie alles, was in die Website eingebettet ist, einstellt. Header können für Ihre gesamte Site auf dem Webserver festgelegt oder von Ihrer Anwendung gesendet werden.

Wenn ich beispielsweise die Verwendung der Geolokalisierungs-API verhindern wollte und den NGINX-Webserver verwendete, konnte ich die Konfigurationsdateien für meine Site in NGINX bearbeiten, um den folgenden Header hinzuzufügen, der jedes Dokument auf meiner Site und alle verhindern würde iFrame eingebettet in von der Verwendung der Geolokalisierungs-API.

 add_header Feature-Policy "geolocation none;";

Mehrere Richtlinien können in einem einzigen Header festgelegt werden. Um Geolokalisierung und Vibration zu verhindern, aber unsized-media ohne Größe von der Domain example.com zuzulassen, könnte ich Folgendes einstellen:

 add_header Feature-Policy "vibrate none; geolocation none; unsized-media https://example.com;";

Das Allow-Attribut auf allow

Wenn es uns in erster Linie darum geht, was mit dem Inhalt in einem Iframe passiert, können wir Feature Policy auf dem Iframe selbst anwenden; Dies profitiert von einer etwas besseren Browserunterstützung zum Zeitpunkt des Schreibens, da Chrome und Safari diese Verwendung unterstützen.

Wenn ich eine Website einbette und nicht möchte, dass diese Website Geolokalisierungs-, Kamera- oder Mikrofon-APIs verwendet, würde mein Iframe wie im folgenden Beispiel aussehen:

 <iframe allow="geolocation 'none'; camera 'none'; microphone 'none'">

Möglicherweise sind Sie bereits mit den einzelnen Attributen vertraut, die den Inhalt von iframes allowfullscreen , allowpaymentrequest und allowusermedia . Diese können durch das Attribut Feature Policy allow ersetzt werden, und aus Gründen der Browserkompatibilität können Sie beide in einem Iframe verwenden. Wenn Sie beide Attribute verwenden, gilt das restriktivste. Der Google-Artikel zeigt ein Beispiel für einen iframe, der allowfullscreen verwendet – was bedeutet, dass der iframe in den Vollbildmodus wechseln darf, aber dann eine widersprüchliche Feature-Richtlinie von fullscreen none . Diese widersprechen sich, sodass die restriktivste Richtlinie gewinnt und dieser iFrame nicht im Vollbildmodus angezeigt werden darf.

 <iframe allowfullscreen allow="fullscreen 'none'" src="...">

Das iframe-Element hat auch ein sandbox Attribut, das entwickelt wurde, um die Unterstützung für viele Funktionen zu verwalten. Diese Funktion wurde auch der Inhaltssicherheitsrichtlinie mit einem sandbox -Wert hinzugefügt, der alle Sandbox-Funktionen deaktiviert, die dann selektiv wieder aktiviert werden können. Es gibt einige Überschneidungen zwischen Sandbox-Features und denen, die von Feature Policy gesteuert werden, und Feature Policy versucht nicht, die Werte zu duplizieren, die bereits von Sandbox abgedeckt werden. Es adressiert jedoch einige der Einschränkungen der Sandbox, indem es einen feinkörnigeren Ansatz zur Verwaltung dieser Richtlinien verfolgt, anstatt alles global als einen großen Richtliniensatz auszuschalten.

Funktionsrichtlinie und Berichts-API

Verstöße gegen Funktionsrichtlinien können über die Berichts-API gemeldet werden, was bedeutet, dass Sie einen umfassenden Satz von Richtlinien entwickeln könnten, die die Verwendung von Funktionen auf Ihrer Website verfolgen. Dies wäre für Ihre Benutzer völlig transparent, gibt Ihnen jedoch eine große Menge an Informationen darüber, wie Funktionen verwendet wurden.

Browserunterstützung für Funktionsrichtlinie

Derzeit ist die Browserunterstützung für Feature Policy auf Chrome beschränkt, aber in vielen Fällen, in denen Sie Feature Policy während der Entwicklung und bei der Vorschau von Websites verwenden, ist dies nicht unbedingt ein Problem.

Viele der Anwendungsfälle, die ich im Folgenden skizziere, sind bereits jetzt verwendbar, ohne dass dies Auswirkungen auf Website-Besucher hat, die Browser ohne Unterstützung verwenden.

Wann sollte die Funktionsrichtlinie verwendet werden?

Mir gefällt die Idee sehr gut, Feature-Richtlinien verwenden zu können, um Entscheidungen zu unterstützen, die bei der Entwicklung der Website getroffen wurden. Entscheidungen, die möglicherweise in Dokumenten wie einem Leistungsbudget oder im Rahmen eines DSGVO-Audits niedergeschrieben werden, die dann aber zu etwas werden, an das wir uns während der gesamten Lebensdauer der Website erinnern müssen. Dies ist nicht immer einfach, wenn mehrere Personen an einer Site arbeiten. Personen, die bei dieser anfänglichen Entscheidungsfindung möglicherweise nicht beteiligt waren oder sich der Anforderungen einfach nicht bewusst sind. Wir denken viel darüber nach, wie es Dritten gelingt, unsere Website irgendwie zu beeinflussen, aber manchmal müssen unsere Websites vor uns selbst geschützt werden!

Dritte im Auge behalten

Sie können verhindern, dass eine Drittanbieter-Website auf die Kamera oder das Mikrofon zugreift, indem Sie eine Funktionsrichtlinie für den Iframe mit dem Attribut allow verwenden. Wenn der Grund für das Einbetten dieser Website nichts mit diesen Funktionen zu tun hat, bedeutet das Deaktivieren dieser Funktionen, dass die Website niemals danach fragen kann. Dies könnte dann mit Ihren Prozessen zur Gewährleistung der DSGVO-Konformität verknüpft werden. Während Sie die Datenschutzauswirkungen Ihrer Website prüfen, können Sie Prozesse zum Sperren des Zugriffs Dritter durch Feature-Richtlinien einbauen – was Ihnen und Ihren Besuchern zusätzliche Sicherheit und Seelenfrieden gibt.

Diese Verwendung hängt von der Browserunterstützung für Feature Policy ab, um die Verwendung zu blockieren. Sie können jedoch den Funktionsrichtlinien-Berichtsmodus verwenden, um Sie über die Verwendung dieser APIs zu informieren, wenn der Drittanbieter seine Vorgehensweise ändert. Dies würde Ihnen eine sehr schnelle Vorwarnung geben – im Wesentlichen sobald die erste Person, die Chrome verwendet, die Website besucht.

Funktionen selektiv aktivieren

Möglicherweise möchten wir auch einige Funktionen selektiv aktivieren, die normalerweise blockiert sind. Vielleicht möchten wir einem Iframe, der Inhalte von einer anderen Website lädt, erlauben, die Geolokalisierungsfunktion im Browser zu verwenden. Chrome blockiert dies standardmäßig, aber wenn Sie Inhalte von einer vertrauenswürdigen Website laden, können Sie die Cross-Origin-Anforderung mithilfe der Funktionsrichtlinie aktivieren. Dies bedeutet, dass Sie Funktionen sicher aktivieren können, wenn Sie Inhalte von einer anderen Domain laden, die Ihrer Kontrolle unterliegt.

Erkennung der Verwendung veralteter APIs und Funktionen mit schlechter Leistung

Feature Policy kann in einem Nur-Bericht-Modus ausgeführt werden. Es kann dann die Nutzung bestimmter Funktionen verfolgen und Sie darüber informieren, wenn sie auf der Website gefunden werden. Dies kann in vielen Szenarien nützlich sein. Wenn Sie eine sehr große Website mit viel Legacy-Code haben, hilft Ihnen die Aktivierung der Funktionsrichtlinie dabei, die Stellen aufzuspüren, die Ihrer Aufmerksamkeit bedürfen. Wenn Sie mit einem großen Team arbeiten (insbesondere, wenn Entwickler häufig Codebibliotheken von Drittanbietern abrufen), kann Feature Policy Dinge erfassen, die Sie lieber nicht auf der Website sehen würden.

Umgang mit schlecht optimierten Bildern

Während sich die meisten Artikel, die ich über Feature Policy gesehen habe, auf die Sicherheits- und Datenschutzaspekte konzentrieren, haben mich die Features rund um die Bildoptimierung wirklich angesprochen, da ich mich mit vielen Inhalten befasse, die von technisch und nicht technisch versierten Benutzern generiert werden. Feature Policy kann verwendet werden, um die Benutzererfahrung sowie die Leistung Ihrer Website zu schützen, indem verhindert wird, dass übermäßig große – oder nicht optimierte Bilder – von Besuchern heruntergeladen werden.

In einer idealen Welt würde sich Ihr CMS um die Bildverwaltung kümmern und sicherstellen, dass die Größe der Bilder sinnvoll geändert, für das Web und den Kontext, in dem sie angezeigt werden, optimiert wurde. Das wirkliche Leben ist jedoch selten diese ideale Welt, und daher ist es manchmal die Aufgabe, die Größe zu ändern und die Optimierung von Bildern wird den Inhaltsredakteuren überlassen, um sicherzustellen, dass sie keine riesigen Bilder ins Internet hochladen. Dies ist insbesondere dann ein Problem, wenn Sie ein statisches CMS ohne darüber liegende Content-Management-Ebene verwenden. Selbst als Techniker vergisst man leicht, die Größe des riesigen Screenshots oder Kamerabilds zu ändern, das man als Platzhalter in einen Ordner eingefügt hat.

Derzeit stecken hinter einer Flagge in Chrome Funktionen, die helfen können. Die Idee hinter diesen Funktionen ist es, die problematischen Bilder hervorzuheben, damit sie repariert werden können – ohne die Website vollständig zu zerstören.

Die Richtlinie für unsized-media Code festgelegt ist. Wenn ein Medienelement ohne Größe geladen wird, kann es dazu führen, dass der Inhalt auf der Seite neu fließt.

Um zu verhindern, dass Medien ohne Größe zur Site hinzugefügt werden, legen Sie den folgenden Header fest. Medien werden dann mit einer Standardgröße von 300×150 Pixel angezeigt. Sie werden sehen, wie Ihre Website mit kleinen Medien geladen wird, und erkennen, dass Sie ein Problem beheben müssen.

 Feature-Policy: unsized-media 'none'

Sehen Sie sich eine Demo an (erfordert Chrome Canary mit aktivierten experimentellen Webplattformfunktionen).

Die Funktionsrichtlinie für oversized-images überprüft, ob Bilder nicht viel größer als ihr Container sind. Wenn dies der Fall ist, wird stattdessen ein Platzhalter angezeigt. Diese Richtlinie ist unglaublich nützlich, um zu überprüfen, ob Sie keine riesigen Desktop-Bilder an Ihre mobilen Benutzer senden.

 Feature-Policy: oversized-images 'none'

Sehen Sie sich eine Demo an (erfordert Chrome Canary mit aktivierten experimentellen Webplattformfunktionen).

Die Funktionsrichtlinie für nicht unoptimized-images mal größer ist als der Renderingbereich in Pixeln. Wenn diese Richtlinie aktiviert ist und Bilder dagegen verstoßen, wird anstelle des Bilds ein Platzhalter angezeigt.

 Feature-Policy: unoptimized-images 'none'

Sehen Sie sich eine Demo an (erfordert Chrome Canary mit aktivierten experimentellen Webplattformfunktionen).

Testen und Berichten über Feature-Richtlinien

Chrome DevTools zeigt eine Meldung an, um Sie darüber zu informieren, dass bestimmte Funktionen durch eine Funktionsrichtlinie blockiert oder aktiviert wurden. Wenn Sie Feature Policy auf Ihrer Website aktiviert haben, können Sie überprüfen, ob dies funktioniert.

Unterstützung für Feature Policy wurde auch zur Security Headers-Site hinzugefügt, was bedeutet, dass Sie diese zusammen mit Headern wie Content Security Policy auf Ihrer Site – oder anderen Sites im Web – überprüfen können.

Es gibt eine Chrome DevTools-Erweiterung, mit der Sie verschiedene Funktionsrichtlinien ein- und ausschalten können (auch eine großartige Möglichkeit, Ihre Seiten zu überprüfen, ohne Kopfzeilen konfigurieren zu müssen).

Wenn Sie Ihre Feature-Richtlinien mit der Reporting-API integrieren möchten, finden Sie hier weitere Informationen dazu.

Weiterführende Literatur und Ressourcen

Ich habe eine Reihe von Ressourcen gefunden, von denen ich viele bei der Recherche zu diesem Artikel verwendet habe. Diese sollten Ihnen alles geben, was Sie brauchen, um mit der Implementierung der Funktionsrichtlinie in Ihren eigenen Anwendungen zu beginnen. Wenn Sie bereits die Inhaltssicherheitsrichtlinie verwenden, scheint dies ein zusätzlicher logischer Schritt zur Kontrolle der Funktionsweise Ihrer Website mit dem Browser zu sein, um die Sicherheit und den Datenschutz der Benutzer Ihrer Website zu gewährleisten. Sie haben den zusätzlichen Vorteil, dass Sie die Funktionsrichtlinie verwenden können, um den Überblick über leistungsschädigende Elemente zu behalten, die Ihrer Website im Laufe der Zeit hinzugefügt werden.

• Spezifikation der Funktionsrichtlinie
• Einführung in die Funktionsrichtlinie
• Blick vom Chrome Dev Summit
• Funktionsrichtlinie auf MDN
• Kann ich die Funktionsrichtlinie verwenden
• Feature-Richtlinien-Demos
• Richten Sie die Header Feature-Policy, Referrer-Policy und Content Security Policy in Nginx ein