保護されたコンテキスト

機能をアクセス制限すべき理由

Web の API には強力なものもあり、攻撃者に対して以下のような (それよりも多くの) 能力を与えてしまう可能性があります。

• ユーザーのプライバシーを侵害する
• ユーザーのコンピューターに対して低水準のアクセス権限を得る
• ユーザーの認証情報のようなデータへのアクセス権限を得る

コンテキストが保護されているとみなされる場合

コンテキストは、Secure Contexts 仕様で定義されている認証および機密性の一定の最低基準を満たしている場合に、保護されたコンテキストとみなされます。特定の文書が保護されたコンテキストであるトップレベルの閲覧コンテキスト (基本的には、保護されたコンテキストであるウィンドウやタブを含むコンテキスト) のアクティブな文書である場合、その文書は保護されたコンテキストにあるとみなされます。

例えば、<iframe> 内で TLS 上で配信された文書であっても、TLS 上で配信されなかった祖先がある場合には、そのコンテキストは保護されているとは見なされません。

しかし、保護されていないコンテキストによって (noopener を指定してもしなくても) 新しいウィンドウが作成された場合、 オープナーが保護されていないという事実は、新しいウィンドウが保護されているとみなされるかどうかに影響を与えないことに注意してください。これは、特定の文書が保護されたコンテキストにあるかどうかの判断は、それが関連付けられているトップレベルの閲覧コンテキスト内でそれを考慮することにのみ基づいており、保護されていないコンテキストがたまたまその文書を作成するために使用されたかどうかではないからです。

ローカルではないリソースが保護されているとみなされるためには、以下の基準を満たす必要があります。

• https:// の URL で提供されなければなりません
• リソースを配信するために使用されるネットワークチャネルのセキュリティプロパティは、非推奨と見なされてはなりません

潜在的に信頼できるオリジン

潜在的に信頼できるオリジンとは、たとえ保護されたコンテキストの基準を満たしていないものの、ブラウザーが一般的にデータセキュリティを保証できると信頼できるオリジンを指します。

http://127.0.0.1、http://localhost、http://*.localhost といったローカルで配信されるリソース（例えば http://dev.whatever.localhost/）は HTTPS を使用して配信されませんが、ブラウザーと同じ端末上にあるため、安全に配信されたと考えることができます。したがって、これらは潜在的に信頼できるものです。これは、開発者がアプリケーションをローカルでテストする際に便利です。

file:// の URL についても、一般的に同じことが言えます。

保護された WebSocket ("wss://") URLも、同時に潜在的に信頼できるものとみなされます。

ベンダー固有の URL スキーム（例: app:// や chrome-extension://）は、すべてのブラウザーで潜在的に信頼できると考えられるわけではありませんが、それらのスキームが由来するベンダーのブラウザーでは信頼されることがあります。

機能検出

ページは、 Window.isSecureContext または WorkerGlobalScope.isSecureContext という論理値を使用して、保護されてたコンテキストにあるかどうかを調べることができます。これらの値はグローバルスコープで公開されます。

if (window.isSecureContext) {
  // ページが保護されたコンテキストなので、サービスワーカーを有効にする
  navigator.serviceWorker.register("/offline-worker.js").then(() => {
    // …
  });
}

仕様書

関連情報

• 保護されたコンテキストに制限されている機能 — 保護されたコンテキストでのみ使用できる機能のリスト
• Window.isSecureContext および WorkerGlobalScope.isSecureContext
• https://permission.site — HTTP と HTTPS を使用して、ブラウザーが使用している API のアクセス許可チェックを確認できるサイト。
• Strict-Transport-Security HTTP ヘッダー