安全标头快速参考

详细了解确保网站安全并快速查询最重要的详细信息的标头。

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas
Maud Nalpas
X GitHub

本文列出了可用于保护的最重要的安全标头 。通过它来了解基于网络的安全功能，学习如何 在网站上实施这些建议，并在需要提醒时作为参考。

对于处理敏感用户数据的网站，建议使用安全标头：
内容安全政策 (CSP)
可信类型
建议为所有网站使用的安全标头：
X-Content-Type-Options
X-Frame-Options
跨域资源政策 (CORP)
跨源打开者政策 (COOP)
HTTP 严格传输安全协议 (HSTS)
适用于具备高级功能的网站的安全标头：
跨域资源共享 (CORS)
跨源嵌入器政策 (COEP)
网络上的已知威胁
在深入了解安全标头之前，请先了解网络上的已知威胁 以及为什么要使用这些安全标头

在深入了解安全标头之前，请先了解网络上的已知威胁 以及为什么要使用这些安全标头

保护您的网站免受注入漏洞的影响

如果您的 Google 内部服务处理不受信任的数据，就会出现注入漏洞 可能会影响其行为，通常会导致 由攻击者控制的脚本由注入引起的最常见的漏洞 bug 是跨网站 运行脚本 (XSS) 各种形式，包括 XSS 存储的 XSS、 基于 DOM XSS 和 其他变体。

XSS 漏洞通常可让攻击者完全访问用户数据 以及由应用程序处理的任何其他信息 来源。

防止注入的传统防御措施包括始终使用自动转义 HTML 模板系统，避免使用危险的 JavaScript API 发出，以及通过托管 文件在单独的网域中上传，并清理由用户控制的 HTML。

将您的网站与其他网站隔离开来

网络的开放性让各个网站能够以多种方式彼此互动， 可能会违反应用的安全预期这包括 发出经过身份验证的请求，或者从 文档，使攻击者能够修改或读取应用数据。

破坏 Web 隔离功能的常见漏洞包括 点击劫持、跨网站 请求伪造 (CSRF)、跨网站 脚本包含 (XSSI) 以及各种 跨网站泄露。

后 Spectre 网络出现后 开发是一门很好的读物 如果您对这些标头感兴趣。

安全地构建功能强大的网站

Spectre 将所有数据 同一浏览上下文组中，可能具有可读性 （尽管存在同源政策）。浏览器限制功能 可能会利用名为 “cross-origin violation”借助跨域隔离功能 使用 SharedArrayBuffer 等强大功能。

对流向您网站的流量进行加密

如果应用未完全加密 传输，允许窃听攻击者了解用户的互动情况 应用

在以下情况下，可能会导致加密不足：未使用 HTTPS、 混合内容，在不使用 Secure 的情况下设置 Cookie 属性 （或__Secure 前缀）， 或宽松的 CORS 验证 逻辑。

内容安全政策 (CSP)

跨站脚本攻击 (XSS) 即网站上的漏洞允许注入恶意脚本 。

Content-Security-Policy 提供了一个额外的层，可通过以下方式缓解 XSS 攻击： 以限制网页可执行哪些脚本。

建议您采用以下任一方法启用严格 CSP：

  • 如果您在服务器上呈现 HTML 网页，请使用基于 Nonce 的严格 CSP。
  • 如果您的 HTML 必须静态提供或缓存（例如， 单页应用，请使用基于哈希的严格 CSP。

用法示例：基于 Nonce 的 CSP

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
如何使用 CSP

1. 使用基于 Nonce 的严格 CSP {: #nonce-based-csp}

如果您在服务器上呈现 HTML 网页，请使用基于 Nonce 的严格 CSP。

为服务器端的每个请求生成新的脚本 Nonce 值，并设置 以下标头：

服务器配置文件

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

在 HTML 中，若要加载脚本，请将所有资源的 nonce 属性设为 <script> 标记添加到同一 {RANDOM1} 字符串中。

index.html

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
  // Inline scripts can be used with the <code>nonce</code> attribute.
</script>

Google 相册是一个很好的基于 Nonce 的严格 CSP 示例。使用开发者工具了解其使用方式。

2. 使用基于哈希的严格 CSP {: #hash-based-csp}

如果您的 HTML 必须静态提供或缓存（例如， 构建单页应用，请使用基于哈希的严格 CSP。

服务器配置文件

Content-Security-Policy:
  script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

在 HTML 中，您需要内嵌脚本才能应用基于哈希的 政策，因为大多数浏览器不支持外部哈希处理 脚本。

index.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

如需加载外部脚本，请阅读“动态加载来源的脚本”低于 选项 B：基于哈希的 CSP 响应标头部分。

CSP Evaluator 是一款出色的工具， 同时，也是一个基于 Nonce 的严格 CSP 示例。 使用开发者工具了解其使用方式。

支持的浏览器

有关 CSP 的其他注意事项

  • frame-ancestors 指令可保护您的网站免受点击劫持，如果您允许某些内容， 不受信任的网站嵌入您的网站。如果您希望使用更简单的解决方案， X-Frame-Options 用于阻止加载，而 frame-ancestors 则提供 一项高级配置，仅允许特定源作为嵌入器。
  • 您可能使用了内容安全政策来确保网站的所有资源 通过 HTTPS 加载）。这包含 相关性会降低：现如今，大多数浏览器都阻止 mixed-content。
  • 您还可以在“仅限报告”中设置 CSP。 模式。
  • 如果您无法将 CSP 设置为标头服务器端，也可以将其设置为元 标记前面。请注意，您不能对元标记使用 report-only 模式（尽管 这可能会发生变化）。

了解详情

可信类型

基于 DOM XSS 是一个 将恶意数据传递到支持动态代码的接收器的攻击 执行，例如 eval() 或 .innerHTML。

可信类型提供编写、安全审核和维护的工具 DOM XSS 的应用。它们可通过 CSP 启用，并且使 默认情况下，JavaScript 代码安全，因为对危险 Web API 进行了限制，只允许它们接受 一种特殊对象，即可信类型。

要创建这些对象，您可以定义安全政策，确保 以一致的方式应用安全规则（例如转义或清理） 然后再将数据写入 DOM 之前。然后，这些政策是 可能会引入 DOM XSS 的代码。

用法示例

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;
如何使用可信类型

  1. 针对危险的 DOM 接收器强制执行可信类型 CSP 和 Trusted Types 标题： 

    Content-Security-Policy: require-trusted-types-for 'script'

    'script' 是目前唯一可接受的值 require-trusted-types-for 指令。

    当然，您可以将可信类型与其他 CSP 指令结合使用：

将基于 Nonce 的 CSP 与可信类型合并： 

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;




<aside class="note"><b>注意：</b>您可以通过设置额外的 <code>trusted-types</code> 来限制允许的可信类型政策名称。指令（例如 <code>trusted-types myPolicy</code>）。不过，这不是一项强制性要求。&lt;/aside&gt;


    
  
  1. 
    
    定义政策
    
    
    政策：
    
   
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}

    
    
  
    2. 
  
  2. 
    
    应用政策
    
    
    在将数据写入 DOM 时使用该政策：
    
   
    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;

    
    
    使用 require-trusted-types-for 'script' 时，使用可信类型
      。将任何危险的 DOM API 与字符串一起使用会导致
      错误。
    
  
    3. 



支持的浏览器



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


了解详情

X-Content-Type-Options

当您的网域提供恶意 HTML 文档时（例如，如果 上传到照片服务的图片包含有效的 HTML 标记）， 会将文档视为有效文档，并允许其在 应用上下文，从而导致跨站脚本攻击 bug。

X-Content-Type-Options: nosniff 会指示浏览器 MIME 类型（在 给定响应的 Content-Type 标头正确无误。此标头为 推荐用于您的所有资源。

用法示例

X-Content-Type-Options: nosniff
如何使用 X-Content-Type-Options

建议为以下来源提供的所有资源使用 X-Content-Type-Options: nosniff 您的服务器以及正确的 Content-Type 标头。

X-Content-Type-Options：nosniff

随文档 HTML 发送的标头示例

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

支持的浏览器

浏览器支持

  • Chrome：64。 <ph type="x-smartling-placeholder">
  • Edge：12。 <ph type="x-smartling-placeholder">
  • Firefox：50。 <ph type="x-smartling-placeholder">
  • Safari：11. <ph type="x-smartling-placeholder">

来源

了解详情

X-Frame-Options

如果恶意网站可以将您的网站作为 iframe 嵌入， 攻击者通过 点击劫持。此外，在某些 案例 Spectre 类型 攻击 让恶意网站有机会了解嵌入文档的内容。

X-Frame-Options 指示是否应允许浏览器呈现 <frame>、<iframe>、<embed> 或 <object> 中的页面。所有文档 发送此标头来指明它们是否允许 嵌入其他文档。

用法示例

X-Frame-Options: DENY
如何使用 X-Frame-Options

所有未设计为嵌入的文档都应使用 X-Frame-Options 标头。

您可以在此 演示。更改 X-Frame-Options 下拉菜单，然后点击重新加载 iframe 按钮。

防止您的网站被任何其他网站嵌入

拒绝嵌入任何其他文档。

X-Frame-Options：DENY 
X-Frame-Options: DENY

防止任何跨源网站嵌入您的网站

仅允许同源文档嵌入。

X-Frame-Options: SAMEORIGIN

支持的浏览器

浏览器支持

  • Chrome：4. <ph type="x-smartling-placeholder">
  • Edge：12。 <ph type="x-smartling-placeholder">
  • Firefox：4. <ph type="x-smartling-placeholder">
  • Safari：4. <ph type="x-smartling-placeholder">

来源

了解详情

跨源资源政策 (CORP)

攻击者可能会嵌入来自其他来源（例如您的网站）的资源， 来通过使用基于 Web 的跨站资源来掌握 泄漏。

Cross-Origin-Resource-Policy为降低这种风险 哪些网站可以加载标头采用以下三个值之一： same-origin、same-site和cross-origin。所有资源 建议发送此标头来指示它们是否允许 其他网站。

用法示例

Cross-Origin-Resource-Policy: same-origin
如何使用 CORP

建议为所有资源提供以下其中一项 三个标头。

您可以尝试以下配置如何影响 Cross-Origin-Embedder-Policy: require-corp 环境对此 演示。将 Cross-Origin-Resource-Policy下拉菜单，然后点击重新加载 iframe 或重新加载图片按钮，可查看效果。

允许加载资源 cross-origin

建议类似 CDN 的服务将 cross-origin 应用于资源 （因为它们通常由跨源网页加载），除非这些网页已经投放 实现类似的效果。CORS

Cross-Origin-Resource-Policy：cross-origin 
Cross-Origin-Resource-Policy: cross-origin

限制要从 same-origin 加载的资源

same-origin 应应用于仅用于加载的资源 同一来源的网页。您应该将此配置应用于包含敏感数据的资源， 与用户相关的信息或旨在调用 API 的 API 的响应 同一来源。

请注意，具有此标头的资源仍然可以直接加载， 例如，在新的浏览器窗口中打开该网址。跨源资源 政策只能防止其他网站嵌入相应资源。

跨源资源政策：同源 
Cross-Origin-Resource-Policy: same-origin

限制要从 same-site 加载的资源

建议将 same-site 应用于与上面类似的资源 但会由您网站的其他子网域加载。

跨源资源政策：同网站 
Cross-Origin-Resource-Policy: same-site

支持的浏览器

浏览器支持

  • Chrome：73。 <ph type="x-smartling-placeholder">
  • Edge：79。 <ph type="x-smartling-placeholder">
  • Firefox：74。 <ph type="x-smartling-placeholder">
  • Safari：12. <ph type="x-smartling-placeholder">

来源

了解详情

跨源打开者政策 (COOP)

攻击者的网站可以在弹出式窗口中打开另一个网站 获取相关信息，利用基于 Web 的跨网站资源， 泄漏。在某些情况下，此操作还可能会允许 对攻击者的 Spectre。

Cross-Origin-Opener-Policy 标头提供了一种将文档分隔开来的方法， 从通过 window.open() 或包含 target="_blank"，不包含 rel="noopener"。因此，任何跨源打开程序 文档将不会引用该文档，因此无法与其交互 。

用法示例

Cross-Origin-Opener-Policy: same-origin-allow-popups
如何使用 COOP

您可以尝试以下配置如何影响与 跨源弹出式窗口。 更改这两个文档的 Cross-Origin-Opener-Policy 下拉菜单 在弹出式窗口中，点击打开弹出式窗口按钮，然后点击发送 postMessage 以查看消息是否实际递送了。

将文档与跨源窗口隔离开来

设置 same-origin 会将文档与跨源隔离开来 文档窗口。

Cross-Origin-Opener-Policy：same-origin 
Cross-Origin-Opener-Policy: same-origin

将文档与跨源窗口隔离开来，但允许弹出窗口

设置 same-origin-allow-popups 可允许文档保留对 除非使用 same-origin 或 same-origin-allow-popups。这意味着same-origin-allow-popups仍能 在以弹出式窗口的形式打开文档时，防止文档被引用； 允许它与自己的弹出式窗口进行通信。

Cross-Origin-Opener-Policy：same-origin-allow-popups 
Cross-Origin-Opener-Policy: same-origin-allow-popups

允许跨源窗口引用文档

unsafe-none 是默认值，但您可以明确指示 可通过跨源窗口打开并保持相互访问。

Cross-Origin-Opener-Policy：unsafe-none 。 
Cross-Origin-Opener-Policy: unsafe-none

报告与 COOP 不兼容的格式

当 COOP 阻止与 Reporting API。

Cross-Origin-Opener-Policy: same-origin; report-to="coop"

COOP 还支持仅报告模式，因此您无需 来阻止跨源文档之间的通信

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

支持的浏览器

浏览器支持

  • Chrome：83。 <ph type="x-smartling-placeholder">
  • Edge：83。 <ph type="x-smartling-placeholder">
  • Firefox：79。 <ph type="x-smartling-placeholder">
  • Safari：15.2. <ph type="x-smartling-placeholder">

来源

了解详情

跨源资源共享 (CORS)

与本文中的其他内容不同，跨域资源共享 (CORS) 功能不适用于 标头，而是请求和允许访问 跨域资源

默认情况下，浏览器会强制执行同源政策 阻止网页访问跨源资源。例如，当 即使跨域图片显示在网页上，系统也会加载 直观地说，网页上的 JavaScript 无法访问图片的数据。 资源提供商可以放宽限制并允许其他网站读取 选择使用 CORS 访问资源。

用法示例

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
如何使用 CORS

在了解如何配置 CORS 之前，最好先了解一下 请求类型之间的区别请求将根据请求详情 归类为简单请求或预检请求。

简单请求的条件：

  • 方法是 GET、HEAD 或 POST。
  • 自定义标头仅包含 Accept、Accept-Language、 Content-Language和Content-Type。
  • Content-Type为 application/x-www-form-urlencoded， multipart/form-data 或 text/plain。

其他所有请求都会归类为预检请求。如需了解更多详情， 请参阅跨域资源共享 (CORS) - HTTP | MDN。

简单请求

当请求符合简单请求条件时，浏览器会向 带有 Origin 标头（指示发出请求）的跨域请求， 来源。

请求标头示例

Get / HTTP/1.1
Origin: https://example.com

响应标头示例

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com 表示 https://example.com 可以访问响应的内容。所需的资源 以供任何网站读取，则可以将此标头设置为 *，在这种情况下， 浏览器就只会要求在未处理的情况下 凭据。
  • Access-Control-Allow-Credentials: true 表示请求包含 允许凭据 (Cookie) 加载资源。否则 即使发出请求的源是 存在于 Access-Control-Allow-Origin 标头中。

您可以在 Cross-Origin-Embedder-Policy: require-corp 环境对此 演示。点击 跨域资源共享复选框，然后点击重新加载映像 按钮查看效果。

预检请求

预检请求前面会发送 OPTIONS 请求，以检查 允许发送后续请求。

请求标头示例

OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
  • Access-Control-Request-Method: POST 允许发出以下请求 使用 POST 方法。
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type 允许 请求者设置 X-PINGOTHER 和 Content-Type HTTP 标头， 后续请求。

响应标头示例

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
  • Access-Control-Allow-Methods: POST, GET, OPTIONS 表示后续 请求均可使用 POST、GET 和 OPTIONS 方法发出。
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type 表示后续 请求可以包含 X-PINGOTHER 和 Content-Type 标头。
  • Access-Control-Max-Age: 86400 表示预检的结果 请求可以缓存 86,400 秒。

支持的浏览器

浏览器支持

  • Chrome：4. <ph type="x-smartling-placeholder">
  • Edge：12。 <ph type="x-smartling-placeholder">
  • Firefox：3.5。 <ph type="x-smartling-placeholder">
  • Safari：4. <ph type="x-smartling-placeholder">

来源

了解详情

跨源嵌入器政策 (COEP)

为了减少基于 Spectre 的功能 攻击 窃取跨源资源，SharedArrayBuffer 或 performance.measureUserAgentSpecificMemory() 默认处于停用状态。

Cross-Origin-Embedder-Policy: require-corp 会阻止文档和工作器 加载跨源资源，例如图片、脚本、样式表、iframe 和 其他资源，除非这些资源明确选择通过 CORS 加载 或 CORP 标头。COEP 可与 Cross-Origin-Opener-Policy 结合使用 为文档启用跨域隔离。

如需启用，请使用 Cross-Origin-Embedder-Policy: require-corp 为文档设置跨域隔离

用法示例

Cross-Origin-Embedder-Policy: require-corp
如何使用 COEP

用法示例

COEP 有单个值：require-corp。通过发送此标头，您可以 指示浏览器阻止加载未通过 CORS 或 CORP。

COEP 的运作方式

您可以在此 演示。将 Cross-Origin-Embedder-Policy 下拉菜单中， Cross-Origin-Resource-Policy 下拉菜单、Report Only 复选框等 以了解它们对资源加载的影响。此外，打开报告端点 演示，看看被禁止抓取的资源 被举报。

启用跨域隔离

如需启用跨域隔离，请将 Cross-Origin-Embedder-Policy: require-corp，以及 Cross-Origin-Opener-Policy: same-origin。 

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

报告与 COEP 不兼容的资源

您可以通过“报告”页面接收有关 COEP 导致的资源被禁止访问的报告 API。

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP 还支持仅报告模式，因此即使没有实际数据， 阻止加载资源

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

支持的浏览器

浏览器支持

  • Chrome：83。 <ph type="x-smartling-placeholder">
  • Edge：83。 <ph type="x-smartling-placeholder">
  • Firefox：79。 <ph type="x-smartling-placeholder">
  • Safari：15.2. <ph type="x-smartling-placeholder">

来源

了解详情

HTTP 严格传输安全协议 (HSTS)

普通 HTTP 连接的通信没有加密，因此 网络级窃听者可访问传输的数据。

Strict-Transport-Security 标头会告知浏览器绝不应加载 并使用 HTTPS。设置完毕后，浏览器将使用 使用 HTTPS（而非 HTTP）访问网域，且在一段时间内无需重定向 标头中定义的相同名称。

用法示例

Strict-Transport-Security: max-age=31536000
如何使用 HSTS

所有从 HTTP 转换到 HTTPS 的网站都应使用 Strict-Transport-Security 标头。 

Strict-Transport-Security: max-age=31536000

支持的浏览器

浏览器支持

  • Chrome：4. <ph type="x-smartling-placeholder">
  • Edge：12。 <ph type="x-smartling-placeholder">
  • Firefox：4. <ph type="x-smartling-placeholder">
  • Safari：7. <ph type="x-smartling-placeholder">

来源

了解详情

深入阅读