安全标头快速参考

详细了解有助于确保网站安全的标头，并快速查找最重要的详细信息。

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas

本文列出了可用于保护网站的最重要的安全标头。您可以使用它来了解基于 Web 的安全功能，学习如何在网站上实现这些功能，并在需要提醒时将其作为参考。

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

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

保护您的网站免遭注入漏洞的攻击

当应用处理的不受信任的数据会影响其行为时，就会出现注入漏洞，并且通常会导致执行攻击者控制的脚本。注入 bug 导致的最常见漏洞是各种形式的跨站脚本攻击 (XSS)，包括反射型 XSS、存储型 XSS、基于 DOM 的 XSS 和其他变体。

XSS 漏洞通常会让攻击者完全访问应用处理的用户数据以及托管在同一网络源中的任何其他信息。

针对注入的传统防御措施包括：始终使用自动转义 HTML 模板系统、避免使用危险的 JavaScript API，以及通过在单独的网域中托管文件上传和清理用户控制的 HTML 来正确处理用户数据。

  • 使用内容安全政策 (CSP) 来控制应用可以执行哪些脚本，以降低注入风险。
  • 使用可信类型来强制对传递到危险 JavaScript API 中的数据进行清理。
  • 使用 X-Content-Type-Options 可防止浏览器错误地解读网站资源的 MIME 类型，从而避免脚本执行。

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

Web 的开放性使得网站能够以可能违反应用安全预期的各种方式相互交互。这包括意外发出经过身份验证的请求，或将来自其他应用的数据嵌入攻击者的文档中，从而使攻击者能够修改或读取应用数据。

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

如果您对这些标头感兴趣，不妨阅读后 Spectre 时代 Web 开发。

安全地构建强大的网站

Spectre 会使加载到同一浏览上下文组中的任何数据都可能被读取，即使存在同源政策也是如此。浏览器会限制可能利用特殊环境（称为“跨源隔离”）背后漏洞的功能。通过跨源隔离，您可以使用 SharedArrayBuffer 等强大的功能。

加密网站流量

当应用未完全加密传输中的数据时，就会出现加密问题，从而使窃听攻击者能够了解用户与应用的互动。

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

内容安全政策 (CSP)

跨站脚本攻击 (XSS) 是一种攻击，其中网站上的漏洞允许注入和执行恶意脚本。

Content-Security-Policy 通过限制网页可执行的脚本来提供额外的层，以缓解 XSS 攻击。

建议您使用以下方法之一启用严格的 CSP：

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

用法示例：基于随机数的 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 中，为了加载脚本，请将所有 <script> 标记的 nonce 属性设置为相同的 {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 评估程序是评估 CSP 的好工具，同时也是基于随机数的严格 CSP 的一个很好的示例。使用开发者工具查看其使用方式。

支持的浏览器

有关 CSP 的其他注意事项

  • frame-ancestors 指令可保护您的网站免遭点击劫持的侵害。如果您允许不受信任的网站嵌入您的网站，则会面临这种风险。如果您偏好更简单的解决方案，可以使用 X-Frame-Options 来阻止加载，但 frame-ancestors 可为您提供高级配置，以仅允许特定来源作为嵌入者。
  • 您可能已使用 CSP 来确保网站的所有资源都通过 HTTPS 加载。这已变得不太相关：如今，大多数浏览器都会屏蔽混合内容。
  • 您还可以设置处于仅报告模式的 CSP。
  • 如果您无法在服务器端将 CSP 设置为标头，也可以将其设置为元标记。请注意，您无法针对元标记使用仅报告模式（不过这种情况可能会发生变化）。

了解详情

可信类型

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

Trusted Types 提供了一些工具，可用于编写、安全审核和维护不含 DOM XSS 的应用。它们可以通过 CSP 启用，并通过限制危险的 Web API 仅接受特殊对象（即受信任的类型）来默认确保 JavaScript 代码的安全。

如需创建这些对象，您可以定义安全政策，确保在将数据写入 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 接收器强制执行 Trusted Types CSP 和 Trusted Types 标头： 

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

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

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

将上述基于随机数的 CSP 与 Trusted Types 合并： 

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>）来限制允许的可信类型政策名称。不过，这不是必需的。</aside>


    
  
  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 标记），某些浏览器会将其视为有效文档，并允许其在应用上下文中执行脚本，从而导致跨站脚本攻击。

X-Content-Type-Options: nosniff 通过指示浏览器给定响应的 Content-Type 标头中设置的 MIME 类型 是正确的，来防止这种情况。建议您为所有资源添加此标头。

使用示例

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

支持的浏览器

Browser Support

  • Chrome: 64.
  • Edge: 12.
  • Firefox: 50.
  • Safari: 11.

Source

了解详情

X-Frame-Options

如果恶意网站可以将您的网站嵌入为 iframe，攻击者可能会通过点击劫持来调用用户无意执行的操作。此外，在某些情况下，Spectre 型攻击会使恶意网站有机会了解嵌入式文档的内容。

X-Frame-Options 用于指示是否应允许浏览器在 <frame>、<iframe>、<embed> 或 <object> 中渲染网页。建议所有文档都发送此标头，以指明它们是否允许被其他文档嵌入。

使用示例

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

所有不打算嵌入的文档都应使用 X-Frame-Options 标头。

您可以尝试以下配置对在此演示中加载 iframe 的影响。更改 X-Frame-Options 下拉菜单，然后点击重新加载 iframe 按钮。

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

拒绝被任何其他文档嵌入。

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

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

仅允许被同源文档嵌入。

X-Frame-Options: SAMEORIGIN

支持的浏览器

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 4.

Source

了解详情

跨源资源政策 (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 的响应。

请注意，带有此标头的资源仍可直接加载，例如通过在新浏览器窗口中前往相应网址来加载。跨源资源政策仅保护资源免遭其他网站的嵌入。

Cross-Origin-Resource-Policy: same-origin 
Cross-Origin-Resource-Policy: same-origin

限制从 same-site 加载的资源

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

Cross-Origin-Resource-Policy: same-site 
Cross-Origin-Resource-Policy: same-site

支持的浏览器

Browser Support

  • Chrome: 73.
  • Edge: 79.
  • Firefox: 74.
  • Safari: 12.

Source

了解详情

跨源打开者政策 (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 下拉菜单，点击 Open a popup 按钮，然后点击 Send a postMessage，查看消息是否实际已传送。

将文档与跨源窗口隔离

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

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

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

设置 same-origin-allow-popups 可让文档保留对其弹出式窗口的引用，除非它们将 COOP 设置为 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"

支持的浏览器

Browser Support

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Source

了解详情

跨源资源共享 (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 表示预检请求的结果可以缓存 86400 秒。

支持的浏览器

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 3.5.
  • Safari: 4.

Source

了解详情

跨源嵌入器政策 (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 不兼容的资源

您可以使用 Reporting API 接收因 COEP 而被屏蔽的资源的报告。

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

COEP 还支持仅报告模式，因此您可以在不实际阻止加载资源的情况下接收报告。

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

支持的浏览器

Browser Support

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Source

了解详情

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

通过纯 HTTP 连接进行的通信不会加密，因此网络级窃听者可以访问传输的数据。

Strict-Transport-Security 标头会告知浏览器，它绝不应使用 HTTP 加载网站，而应使用 HTTPS。设置完成后，浏览器将使用 HTTPS 而不是 HTTP 来访问网域，而无需在标头中定义的时长内进行重定向。

使用示例

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

所有从 HTTP 迁移到 HTTPS 的网站都应在收到 HTTP 请求时通过 Strict-Transport-Security 标头进行响应。

Strict-Transport-Security: max-age=31536000

支持的浏览器

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 7.

Source

了解详情

深入阅读