一文讲清HTTP Header安全

简介

HTTP Header是超文本传输协议 (HTTP) 的一个组成部分，是万维网上数据通信的基础。HTTP Header是 HTTP 请求（又称 HTTP 请求Header）或响应（又称 HTTP 响应Header）中包含的附加信息行。它们提供有关请求或响应的基本详细信息，使客户端和服务器能够有效地通信。

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

Content-Length ：此Header定义消息正文的大小（以字节为单位）。

User-Agent ：标识请求 HTTP 的软件（例如，Web 浏览器）。

Accept ：指定客户端在响应中可以理解和接受的媒体类型。

Location：用于 HTTP 重定向，向客户端提供新的 URL。

Server：表示处理请求的软件或服务器名称。

HTTP 请求和响应Header支持各种功能，例如内容协商、缓存、身份验证和会话管理。它们在促进客户端和服务器之间的通信、确保高效信息交换以及正确处理请求和响应方面发挥着关键作用。采用适当的 HTTP 响应Header可以减轻潜在的安全风险，例如跨站点脚本 (XSS)、点击劫持、信息泄露和许多其他漏洞。本文将详细描述 Web 域或页面安全性相关的所有 HTTP 请求和响应Header

Access-Control-Allow-Origin 

“Access-Control-Allow-Origin”响应Header指示服务器是否允许与来自特定来源的代码共享响应， 通过控制跨源资源共享（CORS）来强制安全性 。

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

例如，当站点 A 向站点 B 请求资源时，站点 B 的响应包含 Access-Control-Allow-Origin Header，以指示站点 A 是否可以访问和检索资源。如果此Header拒绝访问，同源策略 (SOP) 将阻止该请求。

默认情况下，网站受同源策略 (SOP) 保护，该策略限制不同来源之间的资源共享。但是，Access-Control-Allow-Origin Header允许在特定情况下放宽此控制。

“Access-Control-Allow-Origin”响应Header允许来自任何来源的代码访问特定资源，从而增强跨来源可访问性和灵活性。响应中包含该Header表示访问不受限制。在上面的示例中，将 Access-Control-Allow-Origin Header值设置为“*”似乎很方便，但这就像向所有人敞开网站的大门。就像我们不会将家门钥匙交给陌生人一样，我们也不应该授予对网络资源的无限制访问权限。

通过使用 “*”作为值，我们允许任何网站向我们的服务器发出请求， 从而为跨站点请求伪造 ( CSRF ) 和跨站点脚本包含 ( XSSI ) 等潜在安全漏洞打开大门。为了保持安全性，必须有选择性地验证Header中的来源 。这样做将使我们能够控制哪些网站可以安全访问我们的资源。

Java                  Access-Control-Allow-Origin: https://a.sec.com

响应包含“Access-Control-Allow-Origin”Header，允许浏览器允许来自特定来源"a.sec.com"的代码访问请求的资源，从而实现安全的跨源访问。 

服务器将“Origin”请求Header与允许的来源列表进行比较。假设在列表中找到了“Origin”值。在这种情况下，服务器将设置“Access-Control-Allow-Origin”值以匹配“Origin”值，从而限制允许的来源以进行安全的跨来源通信。

Content-Type

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

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

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

解释Content-TypeHeader的指令

Media-type

“Content-Type”Header提供有关使用 MIME（多用途互联网邮件扩展）类型发送或接收的特定数据类型或资源的信息。有关 MIME 类型的更多信息，请参阅 此处 。

Charset

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

boundary

“boundary”指令对于多部分实体是必需的。它由 1 到 70 个健壮字符（不包括空格）组成，并包围消息部分的边界，通常以两个破折号作为前缀和后缀。

在处理客户端要呈现的不受信任的资源时，必须注意 Content-Type Header 。通过设置适当的 Content-Type，开发人员可以 减轻 XSS 攻击的可能性 并维护其 Web 应用程序的安全性和可靠性。

内容安全策略 (CSP) 

内容安全策略 (CSP) 是一种安全措施，可检测和缓解跨站点脚本 (XSS) 和数据注入等攻击。它通过对网站上资源的加载和执行方式实施严格的规则来防止数据盗窃、网站篡改和恶意软件传播。

内容安全策略（CSP）的值指定由策略指令组成的字符串定义了网站的安全策略规则：

Java                  Content-Security-Policy: policy

详细举例

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

目的是将内容限制为 仅来自网站来源 ， 而不包括子域 

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

允许 来自受信任域及其所有子域的内容 ，无论它是否是设置了 CSP Header的同一域。

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

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

Java                  Content-Security-Policy: default-src https://sec.com

旨在强制使用 TLS（传输层安全性）来加载所有内容，通过阻止未经授权的访问请求来防止窃听攻击。

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

允许包含 HTML 和图像 ，但出于安全原因限制包含 JavaScript 或其他潜在有害内容。在此示例中，CSP 未明确指定“script-src”指令。因此， 使用“default-src”指令 ，限制脚本仅从源服务器加载。

使用“application/csp-report”内容类型发送的报告 JSON 对象包含基本数据，其中包括：

• blocked URI

• disposition

• document URI

• effective directive

• original policy

• referrer (弃用)

• script sample

• status code

• violated directive (弃用). 

它提供了对内容安全策略块的资源、执行细节和相关上下文信息的解释。

值得注意的是，实现 CSP Header 对于可以加载和解释脚本和代码的页面最为重要。但是， 对于仅返回内容而不渲染内容的 REST API 的响应， 它可能意义不大 。 

Cross-Origin-Embedder-Policy 

Cross-Origin-Embedder-Policy (COEP) 响应Header 控制文档中跨源资源的嵌入。 

需要注意的是，启用 COEP 标头可能会阻止未充分配置以授予权限的跨源资源。此机制是一种安全措施，可防止与未经授权的资源加载和跨源攻击相关的潜在风险。

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

解释 COEP 指令

Unsafe-none ：此默认值允许文档获取跨域资源，而无需通过 CORS 协议或 Cross-Origin-Resource-Policy Header获得明确的许可。 

Require-corp ：此值规范确保文档只能加载来自同一来源的资源或 明确标记 为可从其他来源加载的资源。如果跨源资源支持 CORS，则跨源属性或 Cross-Origin-Resource-Policy Header必须加载它，而不会被 COEP 阻止。 

Credentialless： 在发出 no-cors 跨源请求时，请求中不包含 Cookie 等凭据，并在响应中被忽略。响应无需明确许可即可进行，但必须遵守 Cross-Origin-Resource-Policy Header。对于导航响应，它们的行为类似于 require-corp 模式，后者需要 Cross-Origin-Resource-Policy 响应Header。

为了有效实施 COEP Header，必须仔细考虑跨源资源及其权限的配置。遵循最佳实践并确保正确设置必要的策略以允许所需的跨源资源交互，同时阻止未经授权的访问至关重要。

跨域资源策略 (CORP) 

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

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

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

CORP Header用法

Same-site:根据跨源资源策略强制要求，只有同一站点的请求才能访问资源。

Same-origin:只有来自同一来源（方案 + 主机 + 端口）的请求才能访问该资源，如跨源资源策略所定义。

Cross-origin:来自任何来源的请求，无论是来自同一站点还是跨站点，都可以根据跨域资源策略读取资源。

配置 CORP Header（正确）可确保只有经过授权和受信任的来源才能包含资源。通过实现此Header，Web 应用程序可以显著减少潜在的攻击面并增强其整体安全性。

Cross-Origin-Opener-Policy 

HTTP 中的 Cross-Origin-Opener-Policy (COOP) Header允许我们阻止顶级文档与跨源文档共享浏览上下文组 。

HTTP Cross-Origin-Opener-Policy (COOP) 响应Header的实施是一项重要的保障措施，可确保顶级文档与跨源文档保持严格隔离，从而阻止任何未经授权的浏览上下文组共享，并防止抄袭或非法复制。它是一项重要的安全措施，可与 Cross-Origin-Embedder-Policy (COEP) 和 Cross-Origin-Resource-Policy (CORP) Header配合使用。

此Header在防范 Spectre 等攻击方面起着至关重要的作用，这些攻击可能会破坏由同源策略 (SOP) 为同一浏览上下文组内的资源建立的安全边界。

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

解释 COOP Header

unsafe-none： 这是默认行为，除非文档具有相同来源或相同来源允许弹出窗口的 COOP，否则可以将文档添加到其打开器的浏览上下文组中。

Same-origin-allow-popups： 保留对新打开的窗口或选项卡的引用，这些窗口或选项卡未设置 COOP，或者通过设置值为“unsafe-none”的 COOP Header来选择退出隔离。

same-origin： 将浏览上下文专门隔离到同源文档，防止在同一上下文中加载跨源文档。

Cross-Origin-Opener-Policy (COOP) Header通过阻止跨源文档与顶级文档共享浏览上下文组来提供保护。它与相关Header配合使用，可增强 Web 浏览安全性并降低与跨源攻击相关的风险。

Set-Cookie 

Set-Cookie HTTP 响应Header 会从服务器向用户浏览器发送一个 cookie ，允许服务器存储信息以供将来的请求使用。通过在响应中包含多个 Set-Cookie Header，可以发送多个 cookie。

虽然 Set-Cookie Header不属于安全Header ，但其安全属性/标志 对于确保安全会话管理和防范潜在漏洞 至关重要。 

Java                  Set-Cookie:=Set-Cookie:=; Domain=Set-Cookie:=; Expires=Set-Cookie:=; HttpOnly                   Set-Cookie:=; Max-Age=Set-Cookie:=; Partitioned                        Set-Cookie:=; Path=Set-Cookie:=; Secure                             Set-Cookie:=; SameSite=Strict                               Set-Cookie:=; SameSite=Lax                                 Set-Cookie:=; SameSite=None; Secure                                   // Multiple attributes are also possible, for example:                                   Set-Cookie:=; Domain=; Secure; HttpOnly

解释 Set-Cookie Header的属性

max-age=<数字>：Max-Age 属性指定 Cookie 过期前的秒数。值为零或负数将使 Cookie 立即过期。如果同时设置了 Expires 和 Max-Age，则 Max-Age 优先。

Httponly：通过 Document.cookie 属性访问 Cookie，从而限制 JavaScript 对 Cookie 的访问。但是，它不会阻止通过 JavaScript 发起的请求（如 XMLHttpRequest 或 fetch）发送 Cookie。此属性有助于缓解跨站点脚本 (XSS) 攻击。

Secure：可帮助我们确保仅当通过 HTTPS 方案发出请求时（本地主机除外）才会向服务器显示 cookie，从而使其更安全地抵御中间人攻击。 

Same-site：

Strict ：当 SameSite 属性设置为“Strict”时，如果请求来自与设置 cookie 的位置相同的位置，则 cookie 只会在请求中发送。跨站点请求（例如来自第三方网站的请求）不会包含 cookie。这可以有效避免 CSRF 攻击，攻击者会诱骗用户的浏览器在另一个站点上进行未经授权的活动。

Lax ：如果将 SameSite 属性设置为“Lax”，则 cookie 可以在跨站点请求中发送，但仅限于顶级导航（例如，单击链接）。但是，通过其他方式发起的跨站点请求（例如由第三方资源（如图像或脚本）发起的请求）将不包含 cookie。这在安全性和可用性之间提供了良好的平衡。

None ：将 SameSite 属性设置为“None”允许在所有跨站点请求中发送 cookie，通常在需要验证或跨源设置中的其他功能的情况下，Web 应用程序必须返回时使用。Web 管理员应明智地使用此Header，因为它可能会带来安全漏洞，尤其是当 cookie 包含敏感数据时。

Partitioned：

SameSite 属性可以更改为“None”值，以指示应使用分区存储来存储 cookie。

持久性 Cookie，在客户端关闭时不会被删除。它们要么在 Expires 属性定义的特定日期被删除，要么在 Max-Age 属性指定的特定时间长度后被删除。 

Java                  // Both accepted when from a secure origin (HTTPS)                  Set-Cookie: __Secure-ID=123; Secure; Domain=example.com                  Set-Cookie: __Host-ID=123; Secure; Path=/                  // Rejected due to missing Secure attribute                  Set-Cookie: __Secure-id=1                  // Rejected due to the missing Path=/ attribute                  Set-Cookie: __Host-id=1; Secure                  // Rejected due to setting a Domain                  Set-Cookie: __Host-id=1; Secure; Path=/; Domain=example.com

名称以“__Secure-”或“__Host-”为前缀的 Cookie 具有特殊限制，以增强安全性。这些 Cookie 仅在使用安全 (HTTPS) 来源的“secure”属性设置后才可使用。

此外，带有“__Host-”前缀的 Cookie 必须具有“/”路径（即主机上的任何路径），并且不得包含域属性。这些额外的限制有助于防止某些类型的安全漏洞。

建议参考 会话管理备忘单 以确保安全处理 Cookie，其中提供了配置 Cookie 设置的详细说明和最佳实践。通过遵循这些指南，您可以建立适当的 Cookie 管理并增强 Web 应用程序的安全性。 

严格传输安全 (HSTS) 

HTTP 严格传输安全 (HSTS) 响应Header指示浏览器仅通过 HTTPS 访问网站，自动 将任何 HTTP 尝试转换为 HTTPS 以增强安全性。

网站使用 HTTP 严格传输安全 (HSTS) 响应Header来强制执行安全通信，方法是 指示浏览器通过 HTTPS 而不是 HTTP 访问网站 。通过为 HSTS 设置较长的持续时间（包括子域）并启用预加载，可以确保安全的浏览体验。

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

解释 HSTS Header的指令

max-age：指定的持续时间（以秒为单位），决定浏览器应记住该站点只能使用 HTTPS 访问的时间。

includeSubDomains： 通过提供这个可选参数，规则还可以扩展为包含所有站点子域。

Preload:当我们使用预加载时，我们必须将 max-age 指令设置为最小 31536000（1 年），并包含includeSubDomains 指令。

但是，在实施 HSTS Header之前，彻底了解其工作原理至关重要。配置错误或 SSL/TLS 证书出现问题可能会导致合法用户无法访问网站。例如，如果 HSTS Header的有效期过长，而 SSL/TLS 证书已过期或被撤销，则用户可能会被锁定，直到 HSTS 有效期到期。 

Referrer-Policy

Referrer-Policy HTTP Header控制着Referer Header指定的请求中包含的引荐来源信息的范围。除了通过 HTTP Header设置此策略外，还可以在 HTML 中配置。

Referrer-Policy HTTP Header通过 Referer Header管理请求中包含的引荐来源信息级别。此Header允许控制应披露多少详细信息，例如来源、路径和查询字符串。

Java                  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 Header 的指令

No-referrer：实施此配置将排除 Referer Header，确保发送的请求不包含任何 referrer 信息。

No-referrer-when-downgrade：当协议安全级别保持不变或提高时（例如，HTTP 到 HTTP、HTTP 到 HTTPS、HTTPS 到 HTTPS），Referer Header会包含来源、路径和查询字符串。但是，对于发往安全性较低的目标的请求（例如，HTTPS 到 HTTP、HTTPS 到文件），它会省略 Referer Header。

Origin：在这种情况下，Referer Header中仅发送来源。例如，如果文档位于 https://example.com/page.html，则发送的 referrer 将是 https://example.com/。

Origin-when-cross-origin：源、路径和查询字符串包含在对同一协议级别的同源请求中（例如，HTTP 到 HTTP、HTTPS 到 HTTPS）。对于跨源请求和对不太安全的目的地的请求（例如，HTTPS 到 HTTP），仅发送源。

Same-origin：对于同源请求，Referer Header包含来源、路径和查询字符串。但是，对于跨源请求，不会发送 Referer Header。

Strict-origin：在协议安全级别保持不变的情况下（例如，HTTPS 到 HTTPS），Referer Header中只会发送来源。但是，在访问安全性较低的目标时（例如，HTTPS 到 HTTP），不会包含 Referer Header。

Strict-origin-cross-when-origin：发出同源请求时，Referer Header包含源、路径和查询字符串。对于跨源请求，如果协议安全级别保持不变（例如，从 HTTPS 到 HTTPS），Referer Header仅包含源。但是，Referer Header不会发送到安全性较低的目标（例如，从 HTTPS 到 HTTP）。

Unsafe-URL：在所有类型的请求中，无论安全性如何，Referer Header都包含来源、路径和查询字符串。

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

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

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

X-Content-Type-Options 

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

包括 X-Content-Type-Options 响应 HTTP Header是服务器采用的一项关键安全措施，用于向 Web 浏览器传达有关处理 Content-Type Header中指定的 MIME 类型的特定指令。这是针对 MIME 混淆攻击的潜在安全漏洞的预防措施。

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

Java                  X-Content-Type-Options: nosniff

解释 X-Content-Type-Options Header的指令

nosniff

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

作为全面安全策略的一部分，实施 X-Content-Type-Options Header可为 Web 应用程序提供一层保护，防止浏览器滥用或 误解 MIME 类型 。

X-Frame-Options 

X-Frame-Options HTTP 响应Header控制网页是否可以在 frame 或 iframe 内显示 。它确保内容不会嵌入到其他网站，有助于防止点击劫持攻击 。

X-Frame-Options HTTP 响应Header是一种安全措施，允许网站指定是否应允许浏览器在框架或 iframe 内呈现其页面。通过利用此Header，网站可以确保其内容不会未经授权嵌入到其他网站，从而防止点击劫持攻击。 

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

解释 X-Frame-Options Header的指令

DENY: 无论网站是否尝试这样做，都会阻止该页面在框架内显示。

SAMEORIGIN ：如果 X-Frame-Options Header设置为 SAMEORIGIN，则只有当所有祖先框架与页面本身具有相同的来源时，我们才能显示网页。

ALLOW-FROM origin ：此指令已过时，现代浏览器不再支持。使用它与不包括Header具有相同的效果。建议改为使用 Content-Security-Policy HTTP Header中的 frame-ancestors 指令。 

此外，值得一提的是，X-Frame-Options Header仅在 HTTP 响应包含链接或按钮等交互元素时才适用。 如果 HTTP 上的响应是重定向，或者它返回 API 的 JSON 数据，则 X-Frame-Options Header不会提供任何安全优势 。

X-XSS-Protection

Internet Explorer、Chrome 和 Safari 支持的 X-XSS-Protection Header有助于 防止反射式跨站点脚本 (XSS) 攻击。不过， 在现代浏览器中，如果实施了强大的 Content-Security-Policy 来禁用不安全的内联 JavaScript，则通常不需要该Header。 

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

Java                  X-XSS-Protection: 0                  X-XSS-Protection: 1                  X-XSS-Protection: 1; mode=block                  X-XSS-Protection: 1; report=

X-XSS-Protection Header 常用值解释

0 ：禁用 XSS 过滤器。

1 ：X-XSS-Protection Header可启用浏览器中的内置 XSS 过滤。如果检测到跨站点脚本攻击，浏览器将尝试通过删除不安全部分来清理页面。 

1; mode=block ：X-XSS-Protection Header可在浏览器中启用 XSS 过滤。如果检测到 XSS 攻击，浏览器将阻止页面呈现，而不是对其进行清理。 

1; report=（仅限 Chromium）：X-XSS-Protection Header可在浏览器中启用 XSS 过滤。如果检测到 XSS 攻击，浏览器将清理页面并使用内容安全策略 (CSP) 的 report-uri 指令报告违规行为。 

虽然 X-XSS-Protection Header可以保护可能尚不支持内容安全策略 (CSP) 的旧版 Web 浏览器的用户，但必须注意的是，在特定情况下，此Header可能会将 XSS 漏洞引入原本被视为安全的网站。但是，必须谨慎行事，因为 仅依赖此Header可能无法提供全面的保护 ，并且在某些情况下可能会无意中引入 XSS 漏洞。 

X-Permitted-Cross-Domain-Policies

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

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

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

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

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

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

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

通过使用适当的策略文件实现 X-Permitted-Cross-Domain-Policies Header，网站管理员可以控制和限制其网站与其他域的交互方式 ，从而有助于 减轻潜在的安全风险，例如跨站点脚本 (XSS) 攻击或跨域数据泄露。 

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

缓存控制Cache-Control 

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

Java                  Cache-Control: public, max-age=3600

此Header指示客户端和中间缓存实体，在重新验证之前，响应可以公开缓存并从缓存中提供 最多 3600 秒（1 小时 ）的缓存。Cache-Control Header可以包含定义缓存规则的各种指令。

解释 Cache-Control Header的指令

Public：表示客户端和中间缓存都可以缓存响应。

Private ：指定响应仅针对特定用户，并且不应被中间缓存缓存。

No-cache ：表示只有在与服务器重新验证后才应从缓存中提供响应。

No-store ：指示客户端和中间缓存在任何情况下都不要存储响应的缓存副本。

Max-age=：此值指定响应可被视为新鲜并从缓存中提供而无需重新验证的最长时间（以秒为单位）。

S-maxage=：与 max-age 类似，但专门用于共享或中间缓存。

Must-revalidate ：客户端在再次使用缓存的响应之前必须与服务器重新验证该响应。

Proxy-revalidate ：与 must-revalidate 类似，但专门用于中间缓存。 

通过正确配置 Cache-Control Header，Web 管理员可以控制浏览器和缓存如何处理资源缓存。这有助于提高网站性能、减少服务器负载并确保用户收到最新的内容。但是，如果 Cache-Control Header配置错误，则可能会为 缓存欺骗攻击 打开大门。

X-Powered-By 

X-Powered-By Header揭示了 Web 服务器所采用的技术， 使其面临潜在的安全威胁 。攻击者可以利用此信息来识别特定技术，并可能利用 与这些技术相关的 已知漏洞。 

需要注意的是，通过 X-Powered-By Header泄露服务器信息可能会让攻击者更容易瞄准并破坏服务器。 通过删除或修改此Header，Web 应用程序可以减少攻击面，使潜在攻击者更难识别和利用漏洞。

Java                  X-Powered-By: Nginx

为了增强 Web 应用程序的安全态势， 建议避免在 X-Powered-By Header中包含敏感信息，并遵循服务器配置和强化的最佳实践。 

HPKP

公钥固定扩展 (HPKP) 是一种安全机制，用于指示 Web 客户端将特定的加密公钥与特定的 Web 服务器相关联，从而帮助降低利用伪造证书的中间人 (MITM) 攻击的风险。但是，此Header现已弃用 ，不推荐使用 。

原文始发于微信公众号（暴暴的皮卡丘）：一文讲清HTTP Header安全