HTTP协议16个安全防护头字段原理及使用方法

HTTP 头对于增强 Web 安全性至关重要，是任何人都可以实现的最简单的安全措施之一。使用适当的 HTTP 响应头可以降低潜在的安全风险，如跨站脚本（XSS）、点击劫持、信息泄露以及其他许多漏洞。这些头部信息作为第一道防护盾，保护 Web 应用程序免受恶意攻击。

HTTP协议概述

HTTP 头是超文本传输协议（HTTP）的一个组成部分，HTTP 是万维网上数据通信的基础。HTTP 头是在 HTTP 请求（即 HTTP 请求头）或响应（即 HTTP 响应头）中包含的额外信息行。它们提供了有关请求或响应的关键信息，使客户端和服务器能够有效地通信。

HTTP 头由键值对组成，其中键表示所传达的具体信息，值提供相应的数据。发送方将这些头部信息包含在 HTTP 消息的头部部分。

图片

HTTP 头有多种类型，每种类型都有特定的用途。以下是一些常用头及其功能：

• Content-Length：定义消息体的大小（以字节为单位）。
• User-Agent：标识发出 HTTP 请求的软件（例如，网络浏览器）。
• Accept：指定客户端能够理解并在响应中接受的媒体类型。
• Location：用于 HTTP 重定向，向客户端提供新的 URL。
• Server：指示处理请求的软件或服务器名称。

HTTP 请求和响应头支持内容协商、缓存、认证和会话管理等多种功能。它们在客户端与服务器之间的通信中起着至关重要的作用，确保信息的高效交换以及请求和响应的正确处理。

以下是与 Web 域或页面安全相关的所有 HTTP 请求和响应头:

Access-Control-Allow-Origin安全头 

Content-Type 

Content-Security-Policy (CSP) 安全头 

Cross-Origin-Embedder-Policy 安全头 

Cross-Origin-Resource-Policy 安全头 

Cross-Origin-Opener-Policy 安全头 

Set-Cookie 

Strict-Transport-Security (HSTS) 安全头 

Referrer-Policy  

X-Content-Type-Options 安全头 

X-Frame-Options 安全头 

X-XSS-Protection 安全头 

X-Permitted-Cross-Domain-Policies 安全头 

Cache-Control 

X-Powered-By 

Public-Key-Pins(HPKP)

图片

Access-Control-Allow-Origin

“Access-Control-Allow-Origin”响应头表明服务器是否允许来自特定来源的代码共享响应内容，通过控制跨域资源共享（CORS）来强化安全性。

跨域资源共享（CORS）机制依赖于 Access-Control-Allow-Origin 头。此头用于确定特定来源的代码是否可以共享所请求的资源。

例如，当站点A请求站点B的资源时，站点B的响应中包含 Access-Control-Allow-Origin 头，以指示站点A是否可以访问和获取该资源。如果该头不允许访问，同源策略（SOP）将阻止该请求。

图片

默认情况下，网站受同源策略（Same Origin Policy, SOP）的保护，该策略限制了不同来源之间的资源共享。然而，通过设置 Access-Control-Allow-Origin 头，可以在特定情况下放宽这种控制。

Access-Control-Allow-Origin:*

“Access-Control-Allow-Origin”响应头允许来自任何来源的代码访问特定资源，从而提高跨域的可访问性和灵活性。在响应中包含此头表明对资源的无限制访问。在上述示例中，将 Access-Control-Allow-Origin 头的值设置为 "*" 可能看似方便，但这就像把我们网站的大门敞开让所有人进入。正如我们不会将家门钥匙交给陌生人一样，我们也不应对 Web 资源给予不受限制的访问权限。

使用 "*" 作为值，意味着我们允许任何网站向我们的服务器发送请求，这会带来潜在的安全风险，例如跨站请求伪造（CSRF）和跨站脚本包含（XSSI）。为了保持强大的安全态势，必须谨慎选择并验证头部中的来源。这样做可以帮助我们控制哪些网站可以安全地访问资源。

Access-Control-Allow-Origin: https://sample.com

该响应包含 "Access-Control-Allow-Origin" 头，使浏览器允许来自特定来源 "https://sample.com" 的代码访问请求的资源，实现安全的跨域访问。

服务器会将“Origin”请求头与允许的来源列表进行比较。如果找到匹配的“Origin”值，服务器会将“Access-Control-Allow-Origin”值设置为与“Origin”值相同，以限制允许的来源，从而确保安全的跨域通信。

Content-Type

“Content-Type”头指定了正在发送或请求的资源的媒体类型。它通过确保数据的正确处理和解释，提供了一项安全功能，有助于防止恶意内容的执行或接收方对数据的误解。

图片

Content-Type 头对于 Web 安全至关重要，因为它在内容编码之前指定了资源的原始媒体类型。它确保客户端的正确解释，并有助于防止诸如跨站脚本（XSS）等安全风险。

该头设置方法如下:

Content-Type: text/html; charset=UTF-8
Content-Type: multipart/form-data; boundary=sample

Media-type“Content-Type”头通过 MIME 类型（多用途互联网邮件扩展）提供有关正在发送或接收的数据类型或资源的具体信息。

Charset“charset”指的是用于数据的字符编码标准。它指定了内容中的字符应如何被解释和显示，建议使用小写字符格式。

Boundary“boundary”指令对于多部分实体是必要的。它包含 1 到 70 个强健字符（不包括空白），用于标记消息部分的边界，通常前后会加上两个连字符。

在处理由客户端呈现的不可信资源时，必须重视 Content-Type 头。通过设置适当的 Content-Type，开发人员可以降低 XSS 攻击的可能性，从而保障其 Web 应用程序的安全性和可靠性。

Content-Security-Policy (CSP)

内容安全策略（CSP）是一项安全措施，可检测并缓解跨站脚本（XSS）和数据注入等攻击。通过对网站加载和执行资源的方式施加严格规则，CSP可以防止数据泄露、网站篡改以及恶意软件分发。

图片

Content-Security-Policy: policy

此值表示 CSP 使用一个由策略指令组成的字符串来定义网站的安全策略规则。

Content-Security-Policy: default-src 'self'

使用此值时，网站管理员旨在将内容限制为仅从网站的源地址加载，不包括子域。

Content-Security-Policy: default-src 'self' example.com 
*.example.com

网站管理员意图允许内容来自一个受信任的域及其所有子域，不论其是否为设置 CSP 头的同一域。

Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com

网站管理员希望允许应用用户在其内容中包含来自任何来源的图像，同时将音视频媒体限制为特定可信提供商，并允许脚本仅来自托管受信代码的特定服务器。

Content-Security-Policy: default-src https://sample.com

Sample网站的管理员希望对所有内容加载强制使用 TLS（传输层安全协议），以防止未经授权的请求访问，从而抵御窃听攻击。

Content-Security-Policy: default-src 'self' *.example.com; img-src *

使用上述值时，网站管理员意图允许邮件中的 HTML 和图像，但限制包含 JavaScript 或其他潜在有害内容以增强安全性。该示例未显式指定“script-src”指令，因此使用“default-src”指令来限制脚本仅从源服务器加载。

Cross-Origin-Embedder-Policy

启用 COEP 头可能会阻止那些未充分配置授权的跨源资源。这一机制作为一种安全措施，可以防范未授权的资源加载和跨源攻击的潜在风险。

该头设置方法如下:

Cross-Origin-Embedder-Policy: unsafe-none | require-corp | credentialless

图片

COEP 指令解释

• Unsafe-none：此默认值允许文档在不需要通过 CORS 协议或 Cross-Origin-Resource-Policy 头显式授权的情况下获取跨源资源。
• Require-corp：此值确保文档只能加载来自相同源的资源，或那些显式标记为可从其他源加载的资源。如果跨源资源支持 CORS，则必须使用跨源属性或 Cross-Origin-Resource-Policy 头进行加载，以避免被 COEP 阻止。
• Credentialless：当发出 no-cors 的跨源请求时，请求中不包含诸如 cookies 等凭证，响应中也会忽略这些凭证。响应被允许在无明确授权的情况下进行，但必须遵循 Cross-Origin-Resource-Policy 头的规定。对于导航响应，其行为与 require-corp 模式相似，即需要 Cross-Origin-Resource-Policy 响应头。

要有效地实现 COEP 头，必须仔细考虑跨源资源的配置及其权限。遵循最佳实践并确保必要的策略正确设置，允许期望的跨源资源交互，同时阻止未授权的访问，这是至关重要的。

Cross-Origin-Resource-Policy

跨源资源策略（CORP）是一种通过 Cross-Origin-Resource-Policy HTTP 头启用的保护机制。它可以保护网站和应用免受来自其他源的特定请求，降低投机性旁路攻击（例如 Spectre）和跨站脚本包含攻击的风险。

CORP 头特别有效于缓解与跨源攻击相关的风险，其中攻击者试图利用不同源中的漏洞来获取未授权访问或提取敏感信息。通过限制仅信任的源可以包含资源，CORP 头防止恶意行为者在其上下文中执行恶意代码。

该头设置方法如下:

Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin

CORS 头部使用

• same-site：只有来自同一站点的请求才能访问该资源，这由跨源资源策略（CORP）强制执行。
• same-origin：该资源只能被来自同一源（协议 + 主机 + 端口）的请求访问，这由跨源资源策略（CORP）定义。
• cross-origin：来自任何源的请求，无论是同一站点还是跨站源，都可以根据跨源资源策略访问该资源。

正确配置 CORP 头可以确保只有经过授权和信任的源才能包含资源。通过实施这一头部，Web 应用可以显著降低潜在的攻击面，并增强整体安全性。

Cross-Origin-Opener-Policy

跨源开启者策略（COOP）HTTP 头使我们能够防止顶级文档与跨源文档共享浏览上下文组。

HTTP 跨源开启者策略（COOP）响应头的实施是一个重要的安全措施，确保顶级文档与跨源文档保持严格的隔离，从而阻止未经授权的浏览上下文组共享，防止抄袭或非法复制。它与跨源嵌入策略（COEP）和跨源资源策略（CORP）头一起工作，是一项重要的安全防护措施。

此头部在防止如 Spectre 等攻击中起着至关重要的作用，这些攻击可能突破同源策略（SOP）为同一浏览上下文组中的资源所建立的安全边界。

该头设置方法如下:

Cross-Origin-Opener-Policy: unsafe-none
Cross-Origin-Opener-Policy: same-origin-allow-popups
Cross-Origin-Opener-Policy: same-origin

图片

COOP 头部指令解释

• unsafe-none：这是默认行为，文档可以被添加到其开启者的浏览上下文组，除非它有一个 same-origin 或 same-origin-allow-popups 的 COOP 头。
• same-origin-allow-popups：保留对新打开的窗口或标签页的引用，这些窗口或标签页要么不设置 COOP，要么通过设置 COOP 头为 unsafe-none 来选择退出隔离。
• same-origin：这将浏览上下文仅限于同源文档，防止跨源文档在同一上下文中加载。

跨源开启者策略（COOP）头通过防止跨源文档与顶级文档共享浏览上下文组来提供保护。它与相关的头部一起工作，增强 Web 浏览安全性，并减轻与跨源攻击相关的风险。

Set-Cookie

Set-Cookie HTTP 响应头用于将 cookie 从服务器发送到用户的浏览器，从而允许服务器在未来的请求中存储信息。通过在响应中包含多个 Set-Cookie 头，可以发送多个 cookie。

虽然 Set-Cookie 头本身并不被归类为安全头部，但其安全属性/标志对于确保安全的会话管理和防止潜在的漏洞至关重要。

该头设置方法如下:

Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>
Set-Cookie: <cookie-name>=<cookie-value>; Partitioned
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
Set-Cookie: <cookie-name>=<cookie-value>; Secure

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure
// Multiple attributes are also possible, for example:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

Set-Cookie 头部属性解释

• max-age=<number>Max-Age 属性指定 cookie 在多少秒后过期。值为零或负数会立即使 cookie 过期。如果同时设置了 Expires 和 Max-Age，则以 Max-Age 为准。
• HttpOnlyHttpOnly 属性限制 JavaScript 通过 Document.cookie 属性访问 cookie。然而，它并不阻止通过 JavaScript 发起的请求（如 XMLHttpRequest 或 fetch）发送该 cookie。此属性有助于减轻跨站脚本（XSS）攻击的风险。
• SecureSecure 属性确保 cookie 只有在通过 HTTPS 协议的请求中才会被发送（除非是本地服务器）。这样可以有效防止中间人攻击。
• SameSite

Strict：当 SameSite 属性设置为 "Strict" 时，cookie 仅会在请求来源于设置该 cookie 的相同站点时发送。来自第三方网站的跨站请求不会携带该 cookie。这有效地避免了 CSRF 攻击，攻击者无法利用用户的浏览器在其他站点上执行未经授权的操作。

Lax：当 SameSite 属性设置为 "Lax" 时，cookie 可以在跨站请求中发送，但仅限于顶级导航（例如点击链接）。然而，由第三方资源（如图片或脚本）发起的跨站请求将不会携带该 cookie。这样在安全性和可用性之间达到了良好的平衡。

None：将 SameSite 属性设置为 "None" 允许 cookie 在所有跨站请求中发送，通常在需要跨源身份验证或其他功能的场景下使用。Web 管理员应谨慎使用该属性，因为它可能会导致安全漏洞，尤其是当 cookie 包含敏感数据时。

• PartitionedSameSite 属性可以设置为 "None"，表示 cookie 应使用分区存储进行存储。

持久性 Cookie（永久性 Cookie）

持久性 Cookie 在客户端关闭时不会被删除。它们会在 Expires 属性定义的具体日期或在 Max-Age 属性指定的时间后被删除。

示例:

// 两个请求都来自安全来源（HTTPS）
Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
Set-Cookie: __Host-ID=123; Secure; Path=/

// 因为缺少 Secure 属性而被拒绝
Set-Cookie: __Secure-id=1

// 因为缺少 Path=/ 属性而被拒绝
Set-Cookie: __Host-id=1; Secure

// 因为设置了 Domain 而被拒绝
Set-Cookie: __Host-id=1; Secure; Path=/; Domain=example.com

以 __Secure- 或 __Host- 为前缀的 cookie 有特殊的安全限制。只有当它们通过安全（HTTPS）源设置并且具有 secure 属性时，才能使用。

此外，带有 __Host- 前缀的 cookie 必须具有路径 /（即主机下的任何路径），且不能包含 Domain 属性。这些额外的约束有助于防止某些类型的安全漏洞。

图片

Strict-Transport-Security (HSTS)

HTTP 严格传输安全（HSTS）响应头指示浏览器仅通过 HTTPS 访问网站，自动将任何 HTTP 请求转换为 HTTPS，从而提高安全性。

网站使用 HTTP 严格传输安全（HSTS）响应头强制执行安全通信，指示浏览器通过 HTTPS 而非 HTTP 访问网站。这通过为 HSTS 设置较长的有效期、包括子域名以及启用预加载来确保安全的浏览体验。

该头设置方法如下:

Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload

图片

HSTS 头部指令解释

• max-age=<expire-time>指定的时长（以秒为单位）决定浏览器应该记住该站点只能通过 HTTPS 访问的时间。
• includeSubDomains通过提供此可选参数，该规则也扩展到包括所有网站子域名。
• Preload使用 preload 时，必须将 max-age 指令设置为至少 31536000（1 年），并包括 includeSubDomains 指令。所有当前和未来的子域名将强制启用 HTTPS，且该配置有效期为一年（max-age=31536000）。这可以防止只能通过 HTTP 提供的页面或子域的访问。

设置参考:

Strict-Transport-Security: max-age=31536000; includeSubDomains

所有当前和未来的子域名将强制启用 HTTPS，且该配置有效期为一年（max-age=31536000）。这可以防止只能通过 HTTP 提供的页面或子域的访问。

另一个设置参考:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

在此示例中，max-age 设置为 2 年，并附加了 "preload" 后缀。包括 "preload" 对于将站点添加到主要浏览器（如 Chromium、Edge 和 Firefox）的 HSTS 预加载列表中是必需的。

然而，在实施 HSTS 之前，必须彻底了解该头部的工作原理。不当的配置或 SSL/TLS 证书问题可能会导致合法用户无法访问网站。例如，如果 HSTS 头部设置了较长的有效期，并且 SSL/TLS 证书过期或被撤销，用户可能会被锁定，直到 HSTS 过期。这就是为什么在启用 HSTS 时需要确保 SSL/TLS 证书始终有效，并且没有中断服务的原因。

如图:

图片

Referrer-Policy

Referrer-Policy HTTP 头部控制通过 Referer 头部指定的请求中包含的引用信息的范围。除了通过 HTTP 头部设置此策略外，它还可以在 HTML 中进行配置。

Referrer-Policy HTTP 头部管理通过 Referer 头部包含的引用信息的级别。该头部允许控制披露的详细程度，如来源、路径和查询字符串。

该头设置方法如下:

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

Referrer-Policy 头部指令解释

• No-referrer实施此配置将排除 Referer 头部，确保发送的请求不包含任何引用信息。
• No-referrer-when-downgrade当协议安全级别保持不变或提高时（例如，HTTP 到 HTTP、HTTP 到 HTTPS、HTTPS 到 HTTPS），Referer 头部包含来源、路径和查询字符串。然而，当请求到达较不安全的目标时（例如，HTTPS 到 HTTP、HTTPS 到 file），将省略 Referer 头部。
• Origin在这种情况下，Referer 头部只发送来源。例如，如果文档位于 https://example.com/page.html，发送的引用信息将是 https://example.com/。
• Origin-when-cross-origin对于同源请求和相同协议级别的请求（例如，HTTP 到 HTTP、HTTPS 到 HTTPS），Referer 头部将包括来源、路径和查询字符串。对于跨域请求和请求到较不安全的目标（例如，HTTPS 到 HTTP），只会发送来源。
• Same-origin对于同源请求，Referer 头部包括来源、路径和查询字符串。然而，对于跨域请求，不会发送 Referer 头部。
• Strict-origin在协议安全级别保持不变的情况下（例如，HTTPS 到 HTTPS），Referer 头部仅发送来源。然而，当访问较不安全的目标时（例如，HTTPS 到 HTTP），Referer 头部不会被包含。
• Strict-origin-cross-when-origin当发起同源请求时，Referer 头部包括来源、路径和查询字符串。对于跨域请求，只有在协议安全级别不变时（例如，HTTPS 到 HTTPS），Referer 头部才会仅包含来源。然而，Referer 头部不会发送到较不安全的目标（例如，HTTPS 到 HTTP）。
• Unsafe-URL在所有类型的请求中，无论安全性如何，Referer 头部都包括来源、路径和查询字符串。

举例:

Referrer-Policy: no-referrer, strict-origin-when-cross-origin

在上述场景中，仅在浏览器不支持 strict-origin-when-cross-origin 策略时，才会使用 no-referrer 策略。

Referrer-Policy 头部使网站所有者能够管理在请求中共享的引用信息的级别。为了确保不同浏览器版本的一致和安全行为，建议在所有请求中都包含此头部，以强制执行所需的引用策略。

X-Content-Type-Options

Web 服务器使用 X-Content-Type-Options 头部来指定声明的 Content-Type 应该被遵循而不是更改。它有助于防止 MIME 类型嗅探，表明指定的 MIME 类型是故意设置的，应该不被覆盖。

在响应 HTTP 中包括 X-Content-Type-Options 头部，是服务器用来向 web 浏览器传达关于如何处理 Content-Type 头部中指定的 MIME 类型的特定指令的一个关键安全措施。这是针对一种潜在的安全漏洞——MIME 类型混淆攻击的预防措施。

Microsoft 在 IE 8 中引入了 X-Content-Type-Options 头部，以防止内容嗅探并将非可执行的 MIME 类型转换为可执行的 MIME 类型。其他浏览器也已采纳此头部，尽管它们的 MIME 嗅探算法可能不那么激进。

该头用法如下:

X-Content-Type-Options: nosniff

X-Content-Type-Options 头部指令解释

nosniffX-Content-Type-Options 头部会阻止请求，如果目标是样式或脚本文件，并且声明的 MIME 类型与预期的类型不匹配（样式文件应为 text/css，脚本文件应为 JavaScript MIME 类型）。

实施 X-Content-Type-Options 头部作为全面安全策略的一部分，能够为 web 应用提供一层保护，防止浏览器对 MIME 类型的误用或误解。

X-Frame-Options

X-Frame-Options HTTP 响应头部控制网页是否可以在 frame 或 iframe 中显示。它确保内容不会被嵌入到其他站点，帮助防止点击劫持攻击（click-jacking）。

X-Frame-Options 响应头部作为一种安全措施，允许网站指定浏览器是否可以在 frame 或 iframe 中呈现其页面。通过使用该头部，网站可以防止点击劫持攻击，确保它们的内容不会未经授权地嵌入到其他网站中。

该头设置方法如下:

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

X-Frame-Options 头部指令解释

• DENY: 无论该站点是否尝试将页面嵌入，都禁止页面在任何框架中显示。
• SAMEORIGIN: 如果 X-Frame-Options 头部设置为 SAMEORIGIN，则只有在所有父框架具有与页面相同的源时，页面才可以在框架中显示。
• ALLOW-FROM origin: 该指令已过时，现代浏览器不再支持。如果使用该指令，将与未包括该头部的效果相同。建议使用 Content-Security-Policy HTTP 头部中的 frame-ancestors 指令代替。

配置 Apache 发送 X-Frame-Options

要配置 Apache 实例以便为所有页面发送 X-Frame-Options 头部，可以将以下代码添加到站点的配置中：

Header always sets X-Frame-Options "SAMEORIGIN"

此值确保 X-Frame-Options 头部包含在所有页面的响应中。

要配置 Apache 为所有页面设置 X-Frame-Options 为 DENY，可以将以下代码添加到站点的配置中：

Header set X-Frame-Options "DENY"

此配置确保 X-Frame-Options 头部包含在所有页面的响应中，指示浏览器在任何情况下都不在 HTML 框架中显示页面。

配置 Nginx 发送 X-Frame-Options

要配置 Nginx 发送 X-Frame-Options 头部，可以将以下代码添加到 Nginx 配置中的 http、server 或 location 块中：

add_header X-Frame-Options SAMEORIGIN always;

此配置确保 X-Frame-Options 头部包含在响应中，指示浏览器仅在源与页面的源匹配时，允许页面在框架中显示。

配置 HAProxy 发送 X-Frame-Options

要配置 HAProxy 以便它发送 X-Frame-Options 头部，可以将以下行添加到 HAProxy 配置中的 front-end、listen 或 backend 部分：

http-response set-header X-Frame-Options SAMEORIGIN

这会将 X-Frame-Options 头部设置为 SAMEORIGIN，表示页面只有在源与页面源匹配时才可以显示在框架中。

X-XSS-Protection

X-XSS-Protection 头部是一个由 Internet Explorer、Chrome 和 Safari 浏览器支持的安全功能，旨在防止反射型跨站脚本（XSS）攻击。然而，在现代浏览器中，如果已启用强大的内容安全策略（CSP）以禁用不安全的内联 JavaScript，通常就不再需要使用该头部。

HTTP X-XSS-Protection 响应头是 Internet Explorer、Chrome 和 Safari 浏览器中的一项安全功能。当网页被识别为易受反射型跨站脚本（XSS）攻击时，该功能会阻止网页的加载。

该头的使用方法如下:

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>

X-XSS-Protection 头部常见值解释

• 0: 禁用 XSS 过滤器。
• 1: 启用浏览器内置的 XSS 过滤器。如果检测到 XSS 攻击，浏览器会尝试通过移除不安全的部分来净化页面。
• 1; mode=block: 启用浏览器的 XSS 过滤器。如果检测到 XSS 攻击，浏览器会阻止页面渲染，而不是尝试净化页面。
• 1; report=<reporting-URI>（仅限 Chromium）: 启用浏览器的 XSS 过滤器。如果检测到 XSS 攻击，浏览器会净化页面并使用 Content-Security-Policy（CSP）中的 report-uri 指令报告违规情况。

虽然 X-XSS-Protection 头部可以保护尚不支持内容安全策略（CSP）的较旧浏览器的用户，但需要注意的是，在某些情况下，该头部可能会在本应安全的网站中引入 XSS 漏洞。因此，不能仅依赖此头部作为唯一的防护措施。必须谨慎使用，因为单靠该头部可能不会提供全面的保护，且在某些情况下可能会无意中引入 XSS 漏洞。

图片

X-Permitted-Cross-Domain-Policies

X-Permitted-Cross-Domain-Policies（XPCDP）头是一个与安全相关的 HTTP 响应头，允许网站管理员定义跨域通信的策略。它用于控制浏览器如何处理跨域请求，如加载资源或在不同域之间发起请求。

XPCDP 头指定了一个策略文件的位置，该文件定义了跨域请求的权限。该策略文件通常是一个 XML 文档，列出了跨域通信的规则和权限。该头的值可以设置为以下选项之一：

X-Permitted-Cross-Domain-Policies: none

None：表示不允许任何跨域访问，任何尝试都会被阻止。

Master-only：允许访问同一域上定义的主策略文件。

By-content-type：根据请求的资源的内容类型，允许访问其他域。

By-FTP filename：根据请求资源的文件名，允许访问其他域。

All：当头设置为“all”时，网站允许跨域交互，包括跨源请求和脚本包含。

通过实现带有适当策略文件的 X-Permitted-Cross-Domain-Policies 头，网站管理员可以控制和限制网站与其他域的交互，从而帮助减少潜在的安全风险，如跨站脚本（XSS）攻击或跨域数据泄露。

需要注意的是，并非所有浏览器都广泛支持 XPCDP 头，因此其有效性可能会在不同的客户端环境中有所不同。不过，它为兼容的浏览器提供了一个额外的跨域通信安全控制层。

图片

Cache-Control

Cache-Control 头用于 HTTP 响应中，指定缓存指令，告诉客户端（如网页浏览器）及中间缓存如何处理和缓存响应。它允许网站管理员控制资源在客户端的缓存行为，从而提高网站性能。

Cache-Control: public, max-age=3600

此头告知客户端和中间缓存实体，响应可以公开缓存，并在 3600 秒（1 小时）内从缓存中提供，而不需要重新验证。Cache-Control 头可以包含多种指令，定义缓存规则。

解释 Cache-Control 头的指令：

• Public：表示客户端和中间缓存都可以缓存该响应。
• Private：指定响应仅针对特定用户，并且不应被中间缓存缓存。
• No-cache：表示响应应在第一次重新验证服务器后，才可以从缓存中提供。
• No-store：指示客户端和中间缓存在任何情况下都不应存储响应的缓存副本。
• Max-age=<seconds>：指定响应可以在缓存中保留的新鲜时间（以秒为单位），在此时间内无需重新验证。
• S-maxage=<seconds>：与 max-age 类似，但专门用于共享或中间缓存。
• Must-revalidate：客户端在再次使用缓存响应之前，必须先重新验证缓存。
• Proxy-revalidate：与 must-revalidate 相似，但专门适用于中间缓存。

通过正确配置 Cache-Control 头，网站管理员可以控制浏览器和缓存如何处理资源的缓存。这可以帮助提高网站性能、减少服务器负载，并确保用户获取到最新的内容。然而，如果 Cache-Control 头配置错误，可能会导致缓存欺骗攻击。

X-Powered-By

X-Powered-By 头揭示了网页服务器所使用的技术，这可能使其暴露于潜在的安全威胁中。攻击者可以利用这些信息来识别特定的技术，并可能利用与这些技术相关的已知漏洞。

需要注意的是，通过 X-Powered-By 头公开服务器信息，可能会使攻击者更容易定位并攻击服务器。通过移除或修改该头，网页应用程序可以减少攻击面，使潜在的攻击者更难识别并利用漏洞。

X-Powered-By: Nginx

为了增强网页应用的安全性，建议避免在 X-Powered-By 头中包含敏感信息，并遵循服务器配置和加固的最佳实践。

Public-Key-Pins(HPKP)

公钥固定扩展（HPKP）曾是一种安全机制，指示网页客户端将特定的加密公钥与特定的网页服务器关联，从而帮助减少利用伪造证书进行中间人攻击（MITM）的风险。然而，该头部已被弃用，不再推荐使用。

总结

安全头部对于保护网页应用程序免受各种漏洞的攻击至关重要，特别是在防范跨站脚本攻击（XSS）方面。

通过利用这些 HTTP 安全头部，如内容安全策略（CSP）、严格传输安全（HSTS）以及上述讨论的其他相关安全措施，我们可以加强网站防御，避免客户端脚本的恶意注入。通过优先考虑并正确配置这些头部，可以保护用户的敏感信息，并确保安全的浏览体验。