安全 HTTP 响应头
默认安全头
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|
仅在 HTTPS 请求上添加 Strict-Transport-Security |
如果默认设置无法满足您的需求，您可以轻松地从这些默认值中移除、修改或添加标头。 有关每个标头的更多详细信息，请参阅相应的章节：
缓存控制
Spring Security 默认禁用缓存以保护用户的内容。
如果用户经过身份验证以查看敏感信息，然后注销，我们不希望恶意用户能够通过点击后退按钮来查看这些敏感信息。 默认发送的缓存控制头为：
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0为了默认情况下保证安全性，Spring Security 默认会添加这些响应头。 然而，如果你的应用程序自行提供了缓存控制（Cache-Control）响应头，Spring Security 则会自动退让。 这使得应用程序能够确保静态资源（例如 CSS 和 JavaScript 文件）可以被缓存。
内容类型选项
历史上，包括 Internet Explorer 在内的浏览器会通过内容嗅探（content sniffing）来尝试猜测请求的内容类型。 这种机制允许浏览器在遇到未指定内容类型的资源时，通过猜测其内容类型来改善用户体验。 例如，如果浏览器遇到一个未指定内容类型的 JavaScript 文件，它能够猜测出该文件的内容类型并加以执行。
|
在允许用户上传内容时，还应采取许多额外措施（例如仅在独立的域名中显示文档、确保设置 Content-Type 响应头、对文档进行清理等）。 然而，这些措施超出了 Spring Security 所提供的功能范围。 此外还需特别指出的是，在禁用内容嗅探（content sniffing）时，必须明确指定内容类型，才能确保功能正常运行。 |
内容嗅探（content sniffing）的问题在于，它允许恶意用户利用多义文件（polyglots，即同时符合多种内容类型的文件）来实施 XSS 攻击。 例如，某些网站可能允许用户向网站提交有效的 PostScript 文档并进行查看。 恶意用户可能会创建一个既是有效 PostScript 文档又是有效 JavaScript 文件的文件，并利用它执行 XSS 攻击。
默认情况下，Spring Security 通过向 HTTP 响应中添加以下标头来禁用内容嗅探：
X-Content-Type-Options: nosniffHTTP 严格传输安全 (HSTS)
当你输入银行网站地址时，你是输入 mybank.example.com，还是输入 https://mybank.example.com？
如果你省略了 https 协议，就可能会遭受中间人攻击。
即使该网站会将你重定向到 https://mybank.example.com，恶意用户仍可能拦截最初的 HTTP 请求并篡改响应（例如，将其重定向到 https://mibank.example.com，从而窃取用户的凭证）。
许多用户会省略 https 协议，这也是为什么创建了HTTP 严格传输安全（HSTS）。
一旦将 mybank.example.com 添加为HSTS 主机，浏览器就能提前知道，任何对 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 预加载的更多详情，请参见 hstspreload.org。
HTTP 公钥固定 (HPKP)
|
为了保持被动性，Spring Security 仍然在 Servlet 环境中提供对 HPKP 的支持。 然而，基于前述原因，Spring Security 团队不再推荐使用 HPKP。 |
HTTP 公钥固定（HPKP） 向 Web 客户端指明应使用哪个公钥与特定的 Web 服务器通信，以防止攻击者利用伪造证书实施中间人（MITM）攻击。 如果正确使用，HPKP 可以为防范被攻破的证书提供额外的保护层。 然而，由于 HPKP 的复杂性，许多专家已不再建议使用它，甚至 Chrome 浏览器也已移除了对其的支持。
有关为何不再推荐使用 HPKP 的更多详情，请阅读 HTTP 公钥固定（HPKP）已死？ 和 我放弃 HPKP 了。
X-Frame-Options
允许您的网站被嵌入到框架（frame）中可能会带来安全问题。 例如，攻击者可通过巧妙的 CSS 样式诱导用户点击他们原本无意点击的内容。 举例来说，一名已登录其银行账户的用户，可能会被诱骗点击一个按钮，从而将访问权限授予其他用户。 此类攻击被称为点击劫持（Clickjacking）。
|
应对点击劫持的另一种现代方法是使用内容安全策略（CSP）。 |
有多种方法可以缓解点击劫持（clickjacking）攻击。 例如，为了保护旧版浏览器免受点击劫持攻击，您可以使用frame 破解代码。 尽管这种方法并不完美，但对于旧版浏览器来说，这已是最佳方案。
一种更现代的防范点击劫持（clickjacking）的方法是使用 X-Frame-Options 响应头。 默认情况下，Spring Security 通过以下响应头禁止页面在 iframe 中渲染：
X-Frame-Options: DENYX-XSS-Protection
某些浏览器内置支持过滤反射型 XSS 攻击。 该过滤器已在主流浏览器中被弃用，当前 OWASP 的建议是显式将该头部设置为 0。
默认情况下，Spring Security 会使用以下头部信息来阻止内容：
X-XSS-Protection: 0内容安全策略 (CSP)
内容安全策略（CSP） 是 Web 应用程序可用于缓解内容注入漏洞（例如跨站脚本攻击（XSS））的一种机制。 CSP 是一种声明式策略，为 Web 应用程序开发者提供了一种能力，用以声明并最终告知客户端（用户代理）该 Web 应用程序预期从哪些来源加载资源。
|
内容安全策略（Content Security Policy）并非旨在解决所有内容注入漏洞。 相反，您可以使用 CSP 来帮助减轻内容注入攻击所造成的危害。 作为第一道防线，Web 应用程序开发者应验证其输入并对输出进行编码。 |
Web 应用程序可以通过在响应中包含以下 HTTP 头之一来使用 CSP（内容安全策略）：
-
Content-Security-Policy -
Content-Security-Policy-Report-Only
这些头部字段均被用作向客户端传递安全策略的机制。 安全策略包含一组安全策略指令，每条指令负责声明对特定资源表示形式的限制。
例如，Web 应用程序可以通过在响应中包含以下头部信息，声明其预期仅从特定的可信来源加载脚本：
Content-Security-Policy: script-src https://trustedscripts.example.com尝试加载来自除 script-src 指令所声明来源之外的脚本时，会被用户代理阻止。
此外，如果安全策略中声明了 report-uri 指令，用户代理会将该违规行为报告到所声明的 URL。
例如，如果某个 Web 应用程序违反了声明的安全策略，以下响应头会指示用户代理将违规报告发送到该策略中 report-uri 指令所指定的 URL。
Content-Security-Policy: script-src https://trustedscripts.example.com; report-uri /csp-report-endpoint/违规报告是标准的 JSON 结构，可由 Web 应用程序自身的 API 捕获，也可由公开托管的内容安全策略（CSP）违规报告服务（例如 report-uri.io/）捕获。
Content-Security-Policy-Report-Only 头部为 Web 应用程序的开发者和管理员提供了监控安全策略的能力，而不是强制执行这些策略。
该头部通常在为站点试验或制定安全策略时使用。
当某个策略被证明有效后，可以通过改用 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 发送违规报告，但仍允许加载该违规资源。
为 Web 应用程序应用内容安全策略（Content Security Policy）通常并非一件简单的事情。 以下资源可帮助您为自己的网站制定有效的安全策略：
引用来源策略
Referrer Policy（引用来源策略） 是 Web 应用程序用来管理引用来源（referrer）字段的一种机制，该字段包含用户上一个访问的页面。
Spring Security 的方法是使用 Referrer Policy（来源策略） 头部，该头部提供了不同的 策略：
Referrer-Policy: same-originReferrer-Policy 响应头指示浏览器将用户先前所在的来源告知目标站点。
功能策略
功能策略（Feature Policy） 是一种机制，允许 Web 开发者有选择地启用、禁用和修改浏览器中某些 API 和 Web 功能的行为。
Feature-Policy: geolocation 'self'通过功能策略（Feature Policy），开发者可以选择加入一组由浏览器在您网站所使用的特定功能上强制执行的“策略”。 这些策略会限制网站可访问的 API，或修改浏览器对某些功能的默认行为。
权限策略
权限策略（Permissions Policy） 是一种机制，允许 Web 开发者在浏览器中选择性地启用、禁用和修改某些 API 和 Web 功能的行为。
Permissions-Policy: geolocation=(self)通过权限策略（Permissions Policy），开发者可以选择加入一组由浏览器在您网站所使用的特定功能上强制执行的“策略”。 这些策略会限制网站可访问的 API，或修改浏览器对某些功能的默认行为。
自定义请求头
|
请参阅相关章节，了解如何配置基于Servlet的应用程序。 |
Spring Security 提供了多种机制，便于为您的应用程序添加更常见的安全头。 然而，它也提供了钩子（hooks），以支持添加自定义头。