Security HTTP Response Headers
可以在很多方面使用 HTTP response headers来提高 Web 应用程序的安全性。本部分专门介绍 Spring Security 为其提供明确支持的各种 HTTP 响应标头。如需，您还可将 Spring Security 配置为提供 custom headers。
Default Security Headers
Spring Security 提供了一组与安全性相关的 HTTP 响应头部的默认值以提供安全默认值。
Spring Security 的默认设置包括以下头部：
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 0|
Strict-Transport-Security 仅添加到 HTTPS 请求 |
如果默认值不符合您的需要，您可以轻松删除、修改或向这些默认值添加标题。有关每个标题的更多详细信息，请参阅相应的章节：
Cache Control
Spring Security 的默认值为禁用缓存，以保护用户的内容。
如果用户经过身份验证以查看敏感信息，然后注销，我们不希望恶意用户能够单击后退按钮查看敏感信息。默认情况下发送的缓存控制标题是：
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0为了从默认设置起就是安全的，Spring Security 默认添加这些标头。然而，如果您的应用程序有自己的缓存控制器，Spring Security 就会退出。这样一来，应用程序就能确保静态资源（例如 CSS 和 JavaScript）能被缓存。
Content Type Options
从前，包括 Internet Explorer 在内的浏览器会尝试使用 content sniffing推测请求的内容类型。这允许浏览器通过推测未指定内容类型上的资源的内容类型来改善用户体验。例如，如果浏览器遇到一个未指定内容类型的 JavaScript 文件，它将能够推测内容类型然后运行它。
|
在允许上传内容时，应该执行许多其他操作（例如仅在特定域显示文档、确保 Content-Type 标头设置、清除文档和其他操作）。然而，这些措施超出了 Spring Security 所提供的范围。同样重要的是，在禁用内容嗅探时，您必须指定内容类型，以便一切都能正常运作。 |
内容嗅探的问题在于，这允许恶意用户使用多语言（即，一个文件有效作为多个内容类型）来执行 XSS 攻击。例如，一些网站可能允许用户向网站提交有效的后置脚本文档并查看它。恶意用户可能会创建 postscript document that is also a valid JavaScript file并用它执行 XSS 攻击。
默认情况下，Spring Security 通过将以下标头添加到 HTTP 响应来禁用内容嗅探：
X-Content-Type-Options: nosniffHTTP Strict Transport Security (HSTS)
当您输入银行网站时，您输入的是 mybank.example.com`还是 `\https://mybank.example.com？如果您省略 `https`协议，您可能会受到 Man-in-the-Middle attacks的攻击。即使网站执行对 `\https://mybank.example.com`的重定向，恶意用户也可能会截获初始 HTTP 请求并操纵响应（例如，重定向到 `\https://mibank.example.com`并窃取其凭据）。
许多用户省略 https`协议，这就是创建 HTTP Strict Transport Security (HSTS)的原因。一旦 `mybank.example.com`作为 HSTS host添加，浏览器可以提前知道对 mybank.example.com 的任何请求都应解释为 `\https://mybank.example.com。这极大地降低了发生中间人攻击的可能性。
|
根据 RFC6797, HSTS 标头仅注入到 HTTPS 响应中。要使浏览器确认标头，浏览器必须首先信任用于创建连接的 SSL 证书的 CA（而不仅仅是 SSL 证书）。 |
让站点被标记为 HSTS 主机的其中一种方式是将该主机预先加载到浏览器中。另一个方式是将 Strict-Transport-Security 标头添加到响应中。例如，Spring Security 的默认行为是添加以下标头，它指示浏览器将域视为 HSTS 主机一年（对于非闰年，一年有 31536000 秒）：
Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload可选的 includeSubDomains 指示浏览器子域名（例如 secure.mybank.example.com）也应视为 HSTS 域。
可选 `preload`指令指示浏览器该域名应预先加载到浏览器中，作为 HSTS 域名。有关 HSTS 预加载的更多详细信息，请参阅 [role="bare"][role="bare"]https://hstspreload.org.
HTTP Public Key Pinning (HPKP)
|
为了保持被动，Spring Security 仍然提供 support for HPKP in servlet environments。但是，由于前面列出的原因，Spring Security 团队不再推荐 HPKP。 |
HTTP Public Key Pinning (HPKP)向 Web 客户端指定要用于特定 Web 服务器的公钥，以防止使用伪造证书进行中间人 (MITM) 攻击。正确使用时，HPKP 可以为受损证书增加额外的保护层。但是，由于 HPKP 的复杂性，许多专家不再建议使用它及其 Chrome has even removed support.
有关不再建议使用 HPKP 的更多详细信息，请阅读 Is HTTP Public Key Pinning Dead?和 I’m giving up on HPKP.
X-Frame-Options
让你的网站被添加到框架中，这可能成为一个安全问题。例如，通过使用巧妙的 CSS 样式，用户可能会被诱骗点击他们本不想点击的东西。例如，已登录其银行的用户可能会单击授予其他用户访问权限的按钮。这种攻击称为 Clickjacking.
|
处理点击劫持的另一种现代方法是使用 Content Security Policy (CSP)。 |
有许多方法可以缓解点击劫持攻击。例如，要保护旧浏览器免受点击劫持攻击，可以使用 frame breaking code.虽然不完美，但是框架破坏代码是针对旧浏览器能做的最好的方法。
解决点击劫持的更现代方法是使用 X-Frame-Options标头。默认情况下，Spring Security 通过使用以下标头禁止在 iframe 中渲染页面：
X-Frame-Options: DENYX-XSS-Protection
某些浏览器具有内置支持功能，可以过滤掉 reflected XSS attacks.该过滤器已在主要浏览器中弃用，并且 current OWASP recommendation用于明确将标头设置为 0。
默认情况下，Spring Security 会使用以下头阻止内容：
X-XSS-Protection: 0Content Security Policy (CSP)
Content Security Policy (CSP)是 Web 应用程序可以用来缓解内容注入漏洞的机制，例如跨站点脚本 (XSS)。CSP 是一种声明性策略，为 Web 应用程序作者提供了一种声明和最终告知客户端（用户代理）有关 Web 应用程序预期从何处加载资源的信息的方法。
|
内容安全策略并非旨在解决所有内容注入漏洞。相反，您可以使用 CSP 来帮助减少内容注入攻击造成的危害。作为第一道防线，网络应用程序作者应验证其输入并对其输出进行编码。 |
网络应用程序可以通过在响应中包含以下 HTTP 头之一来使用 CSP：
-
Content-Security-Policy -
Content-Security-Policy-Report-Only
每个头都用作向客户端提供安全策略的机制。安全策略包含一组安全策略指令，每个指令负责声明特定资源表示的限制。
例如，网络应用程序可以通过在响应中包含以下头，声明它希望从特定的可信源加载脚本：
Content-Security-Policy: script-src https://trustedscripts.example.com用户代理阻止尝试从 `script-src`指令中声明的任何其他来源加载脚本。此外，如果安全策略中声明了 report-uri指令，用户代理将向声明的 URL 报告违规行为。
例如，如果网络应用程序违反了声明的安全策略，则以下响应头会指示用户代理将违规报告发送到策略 report-uri 指令中指定的 URL。
Content-Security-Policy: script-src https://trustedscripts.example.com; report-uri /csp-report-endpoint/Violation reports是标准 JSON 结构，可以由 Web 应用程序自己的 API 或公开托管的 CSP 违规报告服务（如 [role="bare"][role="bare"]https://report-uri.io/）捕获。
Content-Security-Policy-Report-Only 头为网络应用程序作者和管理员提供了监控安全策略而不是强制执行这些策略的功能。当尝试或开发网站的安全策略时，通常会使用此头。当策略被视为有效时，可以通过使用 Content-Security-Policy 头字段来强制执行它。
根据以下响应头，策略声明可以从两个可能的源之一加载脚本。
Content-Security-Policy-Report-Only: script-src 'self' https://trustedscripts.example.com; report-uri /csp-report-endpoint/如果网站违反此策略（即尝试从 evil.example.com 加载脚本），用户代理会将违规报告发送到 report-uri 指令指定的声明的 URL，但仍允许违规资源加载。
将内容安全策略应用于网络应用程序通常是一项非平凡的任务。以下资源可能为你的网站开发有效的安全策略提供进一步帮助：
Referrer Policy
Referrer Policy是一种让 Web 应用程序可以管理引用者字段的机制，该字段包含用户访问的上一页。
Spring Security 的方法是使用 Referrer Policy标头，它提供不同的 policies：
Referrer-Policy: same-originReferrer-Policy 响应头指示浏览器让目标服务器知道用户之前所在的位置。
Feature Policy
Feature Policy是一种允许 Web 开发人员有选择地启用、禁用和修改浏览器中某些 API 和 Web 功能的行为的机制。
Feature-Policy: geolocation 'self'通过功能策略，开发人员可以选择一组 “policies” 供浏览器针对您网站使用的特定功能强制执行。这些策略限制网站可以访问的 API，或修改浏览器针对某些功能的默认行为。
Permissions Policy
Permissions Policy是一种允许 Web 开发人员有选择地启用、禁用和修改浏览器中某些 API 和 Web 功能的行为的机制。
Permissions-Policy: geolocation=(self)通过权限策略，开发人员可以选择一组“策略”，供浏览器针对您网站使用的特定功能强制执行。这些策略限制网站可以访问的 API，或修改浏览器针对某些功能的默认行为。
Clear Site Data
Clear Site Data是一种机制，当 HTTP 响应包含此标头时，可以通过该机制删除所有浏览器端数据（例如，cookie、本地存储）。
Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"这是在注销时执行的一项非常好的清理操作。
Custom Headers
|
参阅相关章节，了解如何配置基于 servlet 的应用程序。 |
Spring Security 具有机制，便于将更常见的安全头添加到应用程序中。但是，它还提供钩子以启用添加自定义头。