安全上下文

為什麼有些功能需要受限？

Web 上的某些 API 非常強大，可以使攻擊者能夠執行以下操作，以及更多

• 侵犯使用者隱私。
• 獲得對使用者計算機的底層訪問許可權。
• 獲取對使用者憑據等資料的訪問許可權。

何時認為上下文是安全的？

當一個上下文滿足 安全上下文 規範中定義的某些最低身份驗證和保密性標準時，該上下文即被認為安全。當一個特定文件是安全上下文的 頂層瀏覽上下文（基本上是一個包含的視窗或標籤頁）的 活動文件 時，該文件即被認為處於安全上下文中。

例如，即使是使用 TLS 在 <iframe> 中傳遞的文件，如果它的祖先不是透過 TLS 傳遞的，那麼它的上下文也不會被認為安全。

但是，需要注意的是，如果一個不安全的上下文建立了一個新視窗（無論是否指定了 noopener），那麼開啟者不安全這一事實不會影響新視窗是否被認為是安全的。這是因為判斷一個特定文件是否處於安全上下文僅基於其關聯的頂層瀏覽上下文，而不考慮用於建立它的上下文是否不安全。

非本地資源要被認為是安全的，必須滿足以下標準：

• 它們必須透過 https:// URL 提供。
• 用於傳遞資源的網路的加密通道的安全屬性不得被視為已棄用。

潛在可信來源

潛在可信來源 是瀏覽器通常可以信任其安全地提供資料的來源，儘管嚴格來說它不符合安全上下文的標準。

本地提供資源，如 http://127.0.0.1、https:// 和 http://*.localhost URL（例如，http://dev.whatever.localhost/），不是透過 HTTPS 提供，但它們可以被認為是安全提供的，因為它們與瀏覽器在同一裝置上。因此它們是潛在可信的。這對於本地測試應用程式的開發人員來說很方便。

對於 file:// URL，通常也是如此。

安全的 WebSocket ("wss://") URL 也被認為是潛在可信的。

特定於供應商的 URL 方案，如 app:// 或 chrome-extension://，並非所有瀏覽器都將其視為潛在可信，但它們可能被其來源的供應商的瀏覽器視為潛在可信。

特性檢測

頁面可以使用功能檢測，透過使用暴露於全域性作用域的 Window.isSecureContext 或 WorkerGlobalScope.isSecureContext 布林值來檢查它們是否處於安全上下文中。

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

規範

另見

• 僅限安全上下文的平臺功能 — 僅在安全上下文中可用的功能列表
• Window.isSecureContext 和 WorkerGlobalScope.isSecureContext
• https://permission.site — 一個允許您檢查瀏覽器在 HTTP 和 HTTPS 上採用哪些 API 許可權檢查的網站
• Strict-Transport-Security HTTP 標頭