Sichere Kontexte

Warum sollten einige Funktionen eingeschränkt werden?

Einige APIs im Web sind sehr mächtig und ermöglichen einem Angreifer unter anderem Folgendes:

• Verletzung der Privatsphäre eines Benutzers.
• Niedrigstufiger Zugriff auf den Computer eines Benutzers.
• Zugriff auf Daten wie Benutzeranmeldedaten.

Wann wird ein Kontext als sicher angesehen?

Ein Kontext wird als sicher angesehen, wenn er bestimmte Mindeststandards in Bezug auf Authentifizierung und Vertraulichkeit erfüllt, die in der Secure Contexts-Spezifikation definiert sind. Ein bestimmtes Dokument wird als sicherer Kontext betrachtet, wenn es das aktive Dokument eines Top-Level-Browsing-Kontexts ist (im Wesentlichen ein enthaltendes Fenster oder Tab), der ein sicherer Kontext ist.

Zum Beispiel wird selbst ein über TLS geliefertes Dokument innerhalb eines <iframe> nicht als sicherer Kontext angesehen, wenn es einen Vorfahren hat, der nicht ebenfalls über TLS geliefert wurde.

Es ist jedoch wichtig zu beachten, dass, wenn ein unsicherer Kontext ein neues Fenster erstellen lässt (mit oder ohne Angabe von noopener), die Tatsache, dass der Eröffner unsicher war, keinen Einfluss darauf hat, ob das neue Fenster als sicher angesehen wird. Das liegt daran, dass die Bestimmung, ob ein bestimmtes Dokument in einem sicheren Kontext ist, nur auf Grundlage der Betrachtung innerhalb des zugehörigen Top-Level-Browsing-Kontexts erfolgt — und nicht darauf, ob ein unsicherer Kontext zufällig zur Erstellung verwendet wurde.

Ressourcen, die nicht lokal sind, müssen folgende Kriterien erfüllen, um als sicher zu gelten:

• Sie müssen über https:// URLs geliefert werden.
• Die Sicherheitsmerkmale des Netzwerkkanals, der zur Bereitstellung der Ressource verwendet wird, dürfen nicht als veraltet angesehen werden.

Potenziell vertrauenswürdige Ursprünge

Ein potenziell vertrauenswürdiger Ursprung ist einer, dem der Browser im Allgemeinen vertrauen kann, Datensicherheit bereitzustellen, obwohl er streng genommen nicht die Kriterien eines sicheren Kontexts erfüllt.

Lokal bereitgestellte Ressourcen wie jene mit http://127.0.0.1, http://localhost und http://*.localhost URLs (zum Beispiel http://dev.whatever.localhost/) werden nicht über HTTPS bereitgestellt, können jedoch als sicher angesehen werden, da sie sich auf dem gleichen Gerät wie der Browser befinden. Sie sind daher potenziell vertrauenswürdig. Dies ist für Entwickler praktisch, die Anwendungen lokal testen.

Dasselbe gilt im Allgemeinen für file:// URLs.

Gesicherte WebSocket ("wss://") URLs werden ebenfalls als potenziell vertrauenswürdig betrachtet.

Anbieter-spezifische URL-Schemata wie app:// oder chrome-extension:// werden nicht von allen Browsern als potenziell vertrauenswürdig angesehen, können jedoch von den Browsern, deren Anbieter sie stammen, als vertrauenswürdig betrachtet werden.

Feature-Erkennung

Seiten können die Feature-Erkennung nutzen, um zu überprüfen, ob sie in einem sicheren Kontext sind oder nicht, indem sie den booleschen Wert Window.isSecureContext oder WorkerGlobalScope.isSecureContext verwenden, der im globalen Gültigkeitsbereich verfügbar ist.

if (window.isSecureContext) {
  // Page is a secure context so service workers are now available
  navigator.serviceWorker.register("/offline-worker.js").then(() => {
    // …
  });
}

Spezifikationen

Siehe auch

• Plattform-Funktionen, die auf sichere Kontexte beschränkt sind — eine Liste der Funktionen, die nur in sicheren Kontexten verfügbar sind
• Window.isSecureContext und WorkerGlobalScope.isSecureContext
• https://permission.site — Eine Seite, die es Ihnen ermöglicht, zu überprüfen, welche API-Berechtigungsprüfungen Ihr Browser über HTTP und HTTPS durchführt
• Strict-Transport-Security HTTP-Header