*随着Chrome 83的最新发布以及即将发布的Mozilla Firefox 79的发布，web开发人员正在设计更强大的新安全机制，以保护其应用程序免受常见Web漏洞的侵害。在本文中，将介绍信息安全工程团队是如何在Google内部署“受信任类型”，“ 内容安全策略”，“ 获取元数据请求标头”和“ 跨域开放者政策”，以帮助指导和启发其他开发人员同样采用这些功能来保护其应用程序。

过去

自从现代Web应用程序问世以来，例如电子邮件客户端或可在浏览器中访问的文档编辑器，开发人员一直在处理常见的Web漏洞，这些漏洞可能使用户数据容易受到攻击者的攻击。虽然Web平台为基础操作系统提供了强大的隔离，但是Web应用程序本身之间的隔离却是另一回事。如问题XSS、CSRF和跨站点泄露已经成为Web开发的不幸的方面，影响到几乎每一个网站在某个时间点。

这些漏洞是Web某些最奇妙的特性的意外后果：可组合性，开放性和易于开发。简而言之，网络的原始愿景是相互关联的文档网格无法预期会创建一个充满活力的Web应用程序生态系统，以处理全球数十亿人的私人数据。因此，旨在帮助开发人员保护其用户数据的Web平台的安全功能发展缓慢，并且仅提供了针对常见漏洞的部分保护。

传统上，Web开发人员通过构建其他安全工程工具和流程来保护其应用程序免受常见漏洞的影响，从而弥补了平台的缺点。事实证明，此类基础架构的开发和维护成本很高。随着Web不断变化，为开发人员提供了更多令人印象深刻的功能，并且Web应用程序对我们的生活变得越来越重要，我们发现自己对直接内置于Web平台的更强大，更全面的安全机制的需求日益增长。

在过去的两年中，来自Google和其他公司的浏览器制造商和安全工程师已经合作设计和实施了几种主要的安全功能，以防御常见的Web漏洞。我们在本文中重点介绍的这些机制可防止注入，并提供隔离功能，解决了网络上两个长期存在的不安全根源。

注入漏洞

在网络上，应用程序代码历来与页面数据交织在一起。HTML标记（例如< script>元素或事件处理程序属性（onclick或onload））允许执行JavaScript；导航到javascript时，即使是熟悉的URL也可以携带代码并导致脚本执行：链接。尽管有时很方便，但这种设计的结果是–除非应用程序注意保护自己，否则用于编写HTML页面的数据可以轻松地插入不需要的脚本并在用户的浏览器中控制该应用程序。

以原则上的方式解决此问题需要允许应用程序将其数据与代码分开；这可以通过启用两个新的安全功能来完成：受信任的类型和基于脚本随机数的内容安全策略。

信任的类型

开发人员构建Web应用程序中使用JavaScript函数通常依赖于分析任意结构进行串。传递给通用API（例如（innerHTML）的似乎包含数据的字符串可以直接转换为代码。这是大多数基于DOM的XSS漏洞的根本原因。

信任类型通过限制危险的操作（例如生成HTML或创建脚本）来要求特殊对象–信任类型，从而使JavaScript代码默认情况下安全。浏览器将确保仅在正确的对象提供给该函数的情况下才允许使用危险的DOM函数。只要应用程序在中央“ 受信任的类型”策略中安全地生成这些对象，它就不会包含基于DOM的XSS错误。

您可以通过设置以下响应标头来启用“受信任的类型”：

我们最近为My Google Activity的所有用户启动了Trusted Types，并且正在与Google的数十个产品团队以及JavaScript框架所有者合作，以使他们的代码支持这一重要的安全机制。

Chrome 83和其他基于Chromium的浏览器支持“受信任的类型” ，其他用户代理也可以使用polyfill。

基于脚本随机数的内容安全策略

内容安全策略（CSP）允许开发人员要求页面上的每个< script>都包含攻击者未知的秘密值。脚本随机数属性（对于每次页面加载均设置为不可预测的数字）可确保给定脚本处于应用程序的控制之下：即使攻击者注入了部分页面，浏览器也将拒绝执行任何操作。注入的脚本无法以正确的随机数标识自己。这样可以减轻任何服务器端注入错误的影响，例如反射的XSS和存储的XSS。

可以通过设置以下HTTP响应标头来启用CSP：

此标头要求HTML模板系统中的所有脚本都包括一个nonce属性，其值与响应标头中的值匹配：

我们的CSP评估工具可帮助您配置强大的政策。

自Google首次推出CSP以来，我们已经针对来自应用程序的75％的出站流量部署了强大的政策，包括旗舰产品（如GMail和Google Docs＆Drive）。在过去两年中，CSP减轻了Google对30多个高风险XSS漏洞的利用。

Chrome，Firefox，Microsoft Edge和其他基于Chromium的浏览器均支持基于Nonce的CSP。Safari也提供对CSP变体的部分支持。

隔离能力
攻击者的网站利用了许多类型的Web漏洞，迫使它们与另一个Web应用程序进行不必要的交互。防止这些问题要求浏览器提供新的机制，以允许应用程序限制此类行为。提取元数据请求标头可在处理传入的HTTP请求时建立服务器端限制。在跨来源开瓶器策略是客户端机制，保护应用程序的窗口从不需要DOM的相互作用。

获取元数据请求标头

的网络安全问题的常见原因是应用程序没有收到有关一个给定的HTTP请求的来源，因此不能够区分良性自发起网络来自其他网站发送的有害请求的流量。这导致诸如跨站点请求伪造（CSRF）和基于Web的信息泄漏（XS-leaks）之类的漏洞。

浏览器附加到传出HTTP请求的获取元数据标头通过为应用程序提供有关发送到服务器的请求来源的可信信息来解决此问题：请求的源，请求的类型（例如，是导航还是请求资源）以及其他与安全性相关的元数据。

通过检查这些新的HTTP标头（Sec-Fetch-Site，Sec-Fetch-Mode和Sec-Fetch-Dest）的值，应用程序可以构建灵活的服务器端逻辑来拒绝不受信任的请求，类似于以下内容：

我们在web.dev/fetch-metadata 中提供了有关此逻辑和采用注意事项的详细说明。重要的是，“获取元数据”可以补充并促进跨域资源策略的采用，该策略提供了针对意外子资源负载的客户端保护；此标头在resourcepolicy.fyi中详细描述。

在Google，我们已在一些主要产品（例如Google Photos）中使用Fetch Metadata标头启用了限制，并且正在跟进整个应用程序生态系统的大规模推广。

提取元数据标头当前由基于Chrome和Chromium的浏览器发送，并且在Firefox的开发版本中可用。

跨域开放者政策

在默认情况下，在网络允许与属于另一个应用程序的浏览器窗口的某些交互：任何网站可以打开一个弹出来的网页邮件客户端，并通过发送邮件的postMessage API，将其导航到另一个URL，或获取有关其框架的信息。所有这些功能都可能导致信息泄漏漏洞：

跨域开放者政策（COOP）允许您锁定应用程序以防止此类交互。要在您的应用程序中启用COOP，请设置以下HTTP响应标头：

如果您的应用程序将其他站点作为弹出窗口打开，则可能需要将标头值设置为same-origin-allow-popups；

我们目前正在多个Google应用程序中测试跨源开放者政策，我们期待在未来几个月中广泛启用它。

从Chrome 83和Firefox 79开始提供COOP。

未来

创建强大而充满活力的网站要求开发人员能够保证其用户数据的安全性。向Web平台添加安全机制-将其直接构建到浏览器中-是生态系统迈出的重要一步：浏览器可以帮助开发人员理解和控制影响其安全状况的网站方面。当用户更新到他们喜欢的浏览器的最新版本时，他们将获得免受过去曾影响Web应用程序的许多安全漏洞的保护。

尽管本文中描述的安全功能不是万能药，但它们提供了基本的构建基块，可帮助开发人员构建安全的Web应用程序。期待与浏览器制造商和Web标准社区合作在将来改进它们。