详细了解确保网站安全并快速查询最重要的详细信息的标头。
本文列出了可用于保护的最重要的安全标头 。通过它来了解基于网络的安全功能,学习如何 在网站上实施这些建议,并在需要提醒时作为参考。
- 对于处理敏感用户数据的网站,建议使用安全标头:
- 内容安全政策 (CSP)
- 可信类型
- 建议为所有网站使用的安全标头:
- X-Content-Type-Options
- X-Frame 选项
- 跨域资源政策 (CORP)
- 跨源打开者政策 (COOP)
- HTTP 严格传输安全协议 (HSTS)
- 适用于具备高级功能的网站的安全标头:
- 跨域资源共享 (CORS)
- 跨源嵌入器政策 (COEP)
在深入了解安全标头之前,请先了解网络上的已知威胁 以及为什么要使用这些安全标头
保护您的网站免受注入漏洞的影响
如果您的 Google 内部服务处理不受信任的数据,就会出现注入漏洞 可能会影响其行为,通常会导致 由攻击者控制的脚本由注入引起的最常见的漏洞 bug 是跨网站 运行脚本 (XSS) 各种形式,包括 XSS, 存储的 XSS、 基于 DOM XSS 和 其他变体。
XSS 漏洞通常可让攻击者完全访问用户数据 以及由应用程序处理的任何其他信息 来源。
防止注入的传统防御措施包括始终使用自动转义 HTML 模板系统,避免使用危险的 JavaScript API 发出,以及通过托管 文件在单独的网域中上传,并清理由用户控制的 HTML。
- 使用内容安全政策 (CSP) 来控制可以使用哪些脚本 来降低注入风险。
- 使用可信类型对传递到危险来源的数据强制执行清理 JavaScript API。
- 使用 X-Content-Type-Options 阻止浏览器 错误解读网站资源的 MIME 类型, 脚本执行。
将您的网站与其他网站隔离开来
网络的开放性让各个网站能够以多种方式彼此互动, 可能会违反应用的安全预期这包括 发出经过身份验证的请求,或者从 文档,使攻击者能够修改或读取应用数据。
破坏 Web 隔离功能的常见漏洞包括 点击劫持、跨网站 请求伪造 (CSRF)、跨网站 脚本包含 (XSSI) 以及各种 跨网站泄露。
- 使用 X-Frame-Options 可防止 恶意网站。
- 使用跨源资源政策 (CORP) 防止您的网站出现 禁止跨源网站添加资源
- 使用跨源打开者政策 (COOP) 保护您网站的 阻止恶意网站互动
- 使用跨域资源共享 (CORS) 来控制对 从跨源文档中获取和利用网站资源。
后 Spectre 网络出现后 开发是一门很好的读物 如果您对这些标头感兴趣。
安全地构建功能强大的网站
Spectre 将所有数据
同一浏览上下文组中,可能具有可读性
(尽管存在同源政策)。浏览器限制功能
可能会利用名为
“cross-origin violation”借助跨域隔离功能
使用 SharedArrayBuffer
等强大功能。
- 结合使用跨源嵌入器政策 (COEP) 和 COOP: 启用跨域隔离
对流向您网站的流量进行加密
如果应用未完全加密 传输,允许窃听攻击者了解用户的互动情况 应用
在以下情况下,可能会导致加密不足:未使用 HTTPS、
混合内容,在不使用 Secure
的情况下设置 Cookie
属性
(或__Secure
前缀),
或宽松的 CORS 验证
逻辑。
- 使用 HTTP 严格传输安全协议 (HSTS) 持续传送您的 通过 HTTPS 传输内容。
内容安全政策 (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';
推荐用法
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, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
推荐用法
-
针对危险的 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 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<aside class="note"><b>注意:</b>您可以通过设置额外的 <code>trusted-types</code> 来限制允许的可信类型政策名称。指令(例如 <code>trusted-types myPolicy</code>)。不过,这不是一项强制性要求。</aside>
-
定义政策
政策:
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\/g, '>');
}
});
}
-
应用政策
在将数据写入 DOM 时使用该政策:
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.</p>
<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src="x" onerror="alert(1)">');
el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
使用 require-trusted-types-for 'script'
时,使用可信类型
。将任何危险的 DOM API 与字符串一起使用会导致
错误。
支持的浏览器
了解详情
X-Content-Type-Options
当您的网域提供恶意 HTML 文档时(例如,如果 上传到照片服务的图片包含有效的 HTML 标记), 会将文档视为有效文档,并允许其在 应用上下文,从而导致跨站脚本攻击 bug。
X-Content-Type-Options: nosniff
会指示浏览器
MIME 类型(在
给定响应的 Content-Type
标头正确无误。此标头为
推荐用于您的所有资源。
用法示例
X-Content-Type-Options: nosniff
推荐用法
建议为以下来源提供的所有资源使用 X-Content-Type-Options: nosniff
您的服务器以及正确的 Content-Type
标头。
![X-Content-Type-Options:nosniff](https://web.developers.google.cn/static/articles/security-headers/image/x-content-type-options-n-7088b3ce0282f.png?authuser=5&hl=sv)
随文档 HTML 发送的标头示例
X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8
支持的浏览器
了解详情
X 帧选项
如果恶意网站可以将您的网站作为 iframe 嵌入, 攻击者通过 点击劫持。此外,在某些 案例 Spectre 类型 攻击 让恶意网站有机会了解嵌入文档的内容。
X-Frame-Options
指示是否应允许浏览器呈现
<frame>
、<iframe>
、<embed>
或 <object>
中的页面。所有文档
发送此标头来指明它们是否允许
嵌入其他文档。
用法示例
X-Frame-Options: DENY
推荐用法
所有未设计为嵌入的文档都应使用 X-Frame-Options
标头。
您可以在此
演示。更改 X-Frame-Options
下拉菜单,然后点击重新加载 iframe 按钮。
防止您的网站被任何其他网站嵌入
拒绝嵌入任何其他文档。
![X-Frame-Options:DENY](https://web.developers.google.cn/static/articles/security-headers/image/x-frame-options-deny-0729b63f3a2e.png?authuser=5&hl=sv)
X-Frame-Options: DENY
防止任何跨源网站嵌入您的网站
仅允许同源文档嵌入。
X-Frame-Options: SAMEORIGIN
支持的浏览器
了解详情
跨源资源政策 (CORP)
攻击者可能会嵌入来自其他来源(例如您的网站)的资源, 来通过利用基于 Web 的跨站资源来掌握 泄漏。
Cross-Origin-Resource-Policy
为降低这种风险
哪些网站可以加载标头采用以下三个值之一:
same-origin
、same-site
和cross-origin
。所有资源
建议发送此标头来指明是否允许
其他网站。
用法示例
Cross-Origin-Resource-Policy: same-origin
推荐用法
建议为所有资源提供以下其中一项 三个标头。
您可以尝试以下配置如何影响
Cross-Origin-Embedder-Policy: require-corp
环境对此
演示。将
Cross-Origin-Resource-Policy下拉菜单,然后点击重新加载
iframe 或重新加载图片按钮,可查看效果。
允许加载资源 cross-origin
建议类似 CDN 的服务将 cross-origin
应用于资源
(因为它们通常由跨源网页加载),除非这些网页已经投放
实现类似的效果。CORS
![Cross-Origin-Resource-Policy:cross-origin](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-resource-pol-365b98767bed6.png?authuser=5&hl=sv)
Cross-Origin-Resource-Policy: cross-origin
限制要从 same-origin
加载的资源
same-origin
应应用于仅用于加载的资源
同一来源的网页。您应该将此配置应用于包含敏感数据的资源,
与用户相关的信息或旨在调用 API 的 API 的响应
同一来源。
请注意,具有此标头的资源仍然可以直接加载, 例如,在新的浏览器窗口中打开该网址。跨源资源 政策只能防止其他网站嵌入相应资源。
![跨源资源政策:同源](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-resource-pol-27b9213f10fd2.png?authuser=5&hl=sv)
Cross-Origin-Resource-Policy: same-origin
限制要从 same-site
加载的资源
建议将 same-site
应用于与上面类似的资源
但会由您网站的其他子网域加载。
![跨源资源政策:同网站](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-resource-pol-158905cfe6687.png?authuser=5&hl=sv)
Cross-Origin-Resource-Policy: same-site
支持的浏览器
了解详情
跨源打开者政策 (COOP)
攻击者的网站可以在弹出式窗口中打开另一个网站 获取相关信息,利用基于 Web 的跨网站资源, 泄漏。在某些情况下,此操作还可能会允许 对攻击者的 Spectre。
Cross-Origin-Opener-Policy
标头提供了一种将文档分隔开来的方法,
从通过 window.open()
或包含
target="_blank"
,不包含 rel="noopener"
。因此,任何跨源打开程序
文档将不会引用该文档,因此无法与其交互
。
用法示例
Cross-Origin-Opener-Policy: same-origin-allow-popups
推荐用法
您可以尝试以下配置如何影响与 跨源弹出式窗口。 更改这两个文档的 Cross-Origin-Opener-Policy 下拉菜单 在弹出式窗口中,点击打开弹出式窗口按钮,然后点击发送 postMessage 以查看消息是否实际递送了。
将文档与跨源窗口隔离开来
设置 same-origin
会将文档与跨源隔离开来
文档窗口。
![Cross-Origin-Opener-Policy:same-origin](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-opener-polic-2d273fc0106eb.png?authuser=5&hl=sv)
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](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-opener-polic-7311769f30905.png?authuser=5&hl=sv)
Cross-Origin-Opener-Policy: same-origin-allow-popups
允许跨源窗口引用文档
unsafe-none
是默认值,但您可以明确指示
可通过跨源窗口打开并保持相互访问。
![Cross-Origin-Opener-Policy:unsafe-none](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-opener-polic-6542ad44c7cdc.png?authuser=5&hl=sv)
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"
支持的浏览器
了解详情
跨源资源共享 (CORS)
与本文中的其他内容不同,跨域资源共享 (CORS) 功能不适用于 标头,而是请求和允许访问 跨域资源
默认情况下,浏览器会强制执行同源政策 阻止网页访问跨源资源。例如,当 即使跨域图片显示在网页上,系统也会加载 直观地说,网页上的 JavaScript 无法访问图片的数据。 资源提供商可以放宽限制并允许其他网站读取 选择使用 CORS 访问资源。
用法示例
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
在了解如何配置 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 秒。
支持的浏览器
了解详情
跨源嵌入器政策 (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 有单个值:require-corp
。通过发送此标头,您可以
指示浏览器阻止加载未通过
CORS 或 CORP。
![COEP 的运作方式](https://web.developers.google.cn/static/articles/security-headers/image/how-coep-works-28c183abab5d5.png?authuser=5&hl=sv)
您可以在此 演示。将 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"
支持的浏览器
了解详情
HTTP 严格传输安全协议 (HSTS)
普通 HTTP 连接的通信没有加密,因此 网络级窃听者可访问传输的数据。
Strict-Transport-Security
标头会告知浏览器绝不应加载
并使用 HTTPS。设置完毕后,浏览器将使用
使用 HTTPS(而非 HTTP)访问网域,且在一段时间内无需重定向
标头中定义的相同名称。
用法示例
Strict-Transport-Security: max-age=31536000
推荐用法
所有从 HTTP 转换到 HTTPS 的网站都应使用
Strict-Transport-Security
标头。
Strict-Transport-Security: max-age=31536000
支持的浏览器