安全上下文

为什么有些功能需要受限？

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 标头