强化Web应用安全：关键HTTP安全头部配置指南
Acunetix | 2025年2月12日
什么是HTTP安全头部？
HTTP安全头部是一种响应头部，通过向浏览器提供关于如何安全处理网站内容的具体指令，帮助保护Web应用。这些头部在缓解各种网络威胁（如跨站脚本攻击[XSS]、点击劫持和数据注入攻击）方面发挥着关键作用。通过正确配置HTTP安全头部，组织可以强制执行更严格的安全策略，限制未经授权的资源加载，并降低恶意利用的风险。常见的HTTP安全头部包括用于防止注入攻击的内容安全策略[CSP]、用于强制实施安全HTTPS连接的严格传输安全[HSTS]，以及用于防止点击劫劫持的X-Frame-Options。实施这些头部是增强Web应用安全性的一种基本且有效的方法，为抵御网络威胁提供了额外的防御层。
通过HTTP安全头部增强Web应用安全性
在Web应用安全测试中，漏洞通常被视为应用代码中可被利用的弱点，必须在源代码层面解决。这通常导致修复特定应用中的单一缺陷，且通常局限于代码的某个区域。
然而，HTTP安全头部在运行时级别发挥作用，提供更广泛、更动态的保护层。通过在应用上线后定义浏览器与服务器交互的严格规则，这些头部有助于预防整类别的网络威胁，使其成为一种非常有效的安全措施。正确配置和实施这些头部是构建强大安全态势的关键组成部分。挑战在于选择最具影响力的头部，并确保其在应用环境中得到一致的应用和测试，以同时维护安全性和功能性。
通过动态应用安全测试[DAST]维持HTTP安全头部的有效性
与许多其他Web技术一样，HTTP协议头部随着时间的推移而演变，受到不断变化的规范和浏览器供应商支持的影响。安全研究的发展速度往往快于官方标准，导致了独立于正式规范的"事实上"安全实践的兴衰。曾经被广泛采用的头部可能会过时，被更新、更有效的替代方案所取代——这使得保持与时俱进变得具有挑战性。
此外，安全头部可以在服务器级别和应用本身内部进行配置。在由数百台服务器支撑数千个网站、应用和API的复杂环境中，手动管理和审计所有接触点的安全头部是不切实际的。这就是自动化漏洞扫描器发挥作用的地方。先进的工具，如Invicti的DAST解决方案，可以自动检测HTTP安全头部的存在和正确配置，并根据最新的安全最佳实践提供明确的建议。
必要的HTTP安全头部
首先，让我们看看两个最广泛认可的HTTP响应头部，每个现代Web应用都应实施它们。除了能显著降低整类基于Web的攻击风险外，这些头部已成为维持安全在线存在的基本必需品。
严格传输安全[HSTS]
HTTP严格传输安全[HSTS]头部是一项关键的安全措施，它确保Web应用仅使用加密的HTTPS连接，防止未加密的HTTP通信。在服务器级别配置，HSTS有助于防止中间人[MITM]攻击和协议降级尝试。
一个典型的HSTS头部可能如下所示：
|
|
此指令告诉Web浏览器，该站点及其所有子域在未来两年内（通过max-age值以秒指定）必须仅通过HTTPS访问。preload指令表示该站点已包含在全局HTTPS-only域名列表中，通过消除初始未加密连接的风险，进一步增强了安全性。此外，预加载通过确保浏览器即使在首次访问时也从不尝试通过HTTP连接，从而提高了性能。
内容安全策略[CSP]
内容安全策略[CSP]头部是最通用和最强大的HTTP安全头部之一，提供了对Web应用可以加载内容的来源的精细控制。通过定义允许内容来源的严格规则——包括脚本、样式、图像和其他资源——CSP是防御跨站脚本[XSS]攻击和其他代码注入威胁的有效手段。
一个将所有资源限制为同源的基本CSP头部如下所示：
|
|
除了此默认设置外，CSP允许更具体的指令，如script-src、style-src、object-src和img-src，分别用于定义JavaScript、CSS、嵌入对象和图像的受信任来源。例如，设置script-src 'self'可确保仅托管在同源上的脚本能够执行，同时仍允许其他资源从外部加载。正确实施CSP可显著降低未经授权的脚本执行风险，并增强Web应用的整体安全态势。
其他HTTP安全头部
虽然内容安全策略[CSP]和严格传输安全[HSTS]是最重要的安全头部，但还有其他几个HTTP头部可以以最小的努力进一步增强Web应用的防御。尽管它们可能没有那么关键，但这些头部提供了针对各种基于Web威胁的宝贵保护，通常实现的安全增强如果仅通过应用代码实现会复杂得多。
X-Content-Type-Options
X-Content-Type-Options头部通过防止Web浏览器"嗅探"MIME类型并将文件错误地解释为可执行脚本来增强安全性。当包含在服务器响应中时，此头部确保浏览器严格遵守Content-Type头部中声明的MIME类型，降低了利用MIME嗅探执行恶意代码的攻击风险。
为了强制执行此保护，该头部使用一个单一指令：
|
|
通过实施此头部，网站可以降低某些跨站脚本[XSS]和路过式下载攻击的风险，确保内容仅按照服务器的意图进行处理。
跨域资源共享[CORS]头部
现代Web应用通常需要与其自身域之外的外部资源交互，这要求对浏览器强制执行同源策略[SOP]进行受控的例外。几个HTTP头部允许开发者在保持强大安全措施的同时，选择性地放宽这些限制。
- Access-Control-Allow-Origin：定义允许哪些域跨源访问资源。该值可以是特定域、多个域，或
*以允许所有源（但应谨慎使用*）。 - Cross-Origin-Opener-Policy [COOP]：确定顶级文档是否可以与其跨源页面共享其浏览上下文。将其设置为
same-origin可防止未经授权的跨源访问。 - Cross-Origin-Resource-Policy [CORP]：指定哪些域可以加载特定资源。使用
same-site将访问限制在同一源，防止外部站点包含该资源。 - Cross-Origin-Embedder-Policy [COEP]：类似于CORP，但专门管理嵌入式内容。
require-corp指令确保只有来自允许源（由CORP头部定义）的资源可以被嵌入。
由于安全头部在功能上经常重叠，可能需要多种配置才能在保持必要跨源功能性的同时实现所需的安全态势。正确实施CORS头部可确保与第三方资源交互的Web应用在安全性和互操作性之间取得平衡。
获取元数据头部
获取元数据头部是一组较新的客户端HTTP头部，提供有关请求如何发起的额外上下文，允许服务器强制执行更严格的安全策略。这些头部帮助浏览器将特定于应用的请求属性传达给服务器，提高了对跨站请求伪造[CSRF]、跨源攻击和推测执行威胁的防护。
四个关键的获取元数据头部包括：
- Sec-Fetch-Site：指示请求发起者与目标源之间的关系（例如，同源、跨站、同站点）。
- Sec-Fetch-Mode：指定请求模式，如
cors、navigate或no-cors，帮助服务器确定请求是如何发出的。 - Sec-Fetch-User：标识请求是否由用户交互（如点击链接）触发。
- Sec-Fetch-Dest：定义预期的请求目标，如
document、image、script或style。
当浏览器和服务器都支持这些头部时，它们通过使服务器能够验证请求行为并阻止潜在的恶意活动，提供了额外的安全层。经过适当配置，获取元数据头部通过允许对资源的访问和使用方式进行更精细的控制，增强了Web应用的安全性。
用于隐私和安全的其他HTTP头部
虽然不严格归类为安全头部，但某些HTTP头部通过控制网页与服务器之间如何共享信息，在增强数据隐私和安全性方面发挥着关键作用。其中一个头部是Referrer-Policy，它有助于调节浏览器在进行HTTP请求时应包含多少引荐来源信息。
Referrer-Policy
此头部决定浏览器在向另一个Web服务器发出请求时应包含多少引荐URL。一个常用的指令是：
|
|
通过此设置，浏览器在同一源内导航时发送完整的引荐URL，但在进行跨源请求时将其限制为仅源[域名]。这种方法通过防止外部站点访问完整的浏览路径来帮助保护用户隐私，同时仍允许同一站点内有用的引荐数据。
通过实施Referrer-Policy，网站可以在维护分析功能和降低将敏感URL参数泄露给外部域的风险之间取得平衡。
Cache-Control：管理网页缓存
Cache-Control头部提供了对浏览器和中间服务器如何缓存网页和资源的精细控制。正确配置此头部对于性能优化和数据安全至关重要，确保敏感信息不会无意中存储或从缓存中检索。
用于防止缓存的常用指令是：
|
|
此设置确保响应永远不会存储在任何缓存中，这对于处理登录会话、金融交易或个人数据等机密数据的页面特别有用。
其他Cache-Control指令允许进一步的自定义，例如设置过期时间[max-age]、要求重新验证[must-revalidate]或为私有与共享缓存指定缓存行为。通过利用Cache-Control，网站可以在基于其特定需求优化内容交付的同时增强安全性。
Clear-Site-Data：确保注销后的用户隐私
Clear-Site-Data头部通过指示浏览器在用户注销或会话结束时清除特定类型的存储数据，有助于增强安全性和隐私性。这可以防止机密信息残留在浏览器中，降低未经授权访问的风险。
清除所有存储站点数据的常见实现是：
|
|
此指令擦除与该站点关联的所有缓存内容、cookie和存储的会话数据。或者，更具体的指令如cache、cookies和storage允许对要删除的数据类型进行更精细的控制。
虽然尚未在所有浏览器中得到普遍支持，但Clear-Site-Data是加强用户隐私的宝贵工具，特别是在处理金融服务、医疗保健或基于身份验证的平台等敏感信息的应用中。
Permissions-Policy：控制对浏览器功能的访问
前身为Feature-Policy，Permissions-Policy头部使开发人员能够限制或允许网页访问各种浏览器功能和API。虽然它可以用于控制应用功能，但其主要目的是通过限制对敏感资源（如麦克风、摄像头和地理位置）的访问来增强隐私和安全性。
要阻止所有这三个功能，可以使用：
|
|
此配置明确禁用对麦克风、摄像头和地理位置API的访问，防止脚本或嵌入式内容未经授权使用。其他指令允许进行更精细的控制，例如限制对特定域的访问或仅允许在某些上下文中使用功能。
通过实施Permissions-Policy，网站可以减少攻击面，降低隐私风险，并确保用户仅能使用必要的功能。
已弃用的HTTP安全头部：回顾过去
在Web安全的早期阶段，主流浏览器经常引入新的HTTP头部作为应对新兴威胁的临时解决方案。然而，随着Web安全标准的发展并变得更加结构化，许多这些头部被弃用——有时仅在几年内。虽然它们不再被推荐用于现代应用，但这些已弃用的头部为了解Web安全技术的快速演变提供了宝贵的见解。
[已弃用] X-Frame-Options
最初由Microsoft Internet Explorer在2008年引入，X-Frame-Options头部旨在防止涉及HTML iframe的跨站脚本[XSS]攻击。在引入更标准化的安全机制之前，此头部提供了一种控制网页是否可以嵌入到iframe中的方法，有助于缓解点击劫持攻击。
要完全阻止iframe嵌入，站点可以使用：
|
|
或者，将其设置为sameorigin允许仅在父框架来自同一源时才在iframe中加载页面：
|
|
还有一个allow-from指令，允许特定的受信任URL嵌入页面。然而，此头部最终被弃用，取而代之的是内容安全策略[CSP]标准中的frame-ancestors指令，该指令提供了对iframe嵌入的更精细和灵活的控制。
虽然已弃用，X-Frame-Options在现代Web安全实践的发展中发挥了关键作用，展示了安全策略必须多快地适应不断演变的威胁。
已弃用的HTTP安全头部：过去的教训
多年来，各种HTTP安全头部被引入作为应对不断演变的安全威胁的临时解决方案。然而，随着Web安全标准的改进和更好的解决方案出现，许多这些头部变得过时。以下是三个值得注意的已被弃用并被更有效替代方案取代的安全头部。
[已弃用] X-XSS-Protection
X-XSS-Protection头部最初旨在通过利用Web浏览器中内置的XSS过滤器来缓解跨站脚本[XSS]攻击。一个典型的实现如下所示：
|
|
此设置指示浏览器检测并阻止可疑的JavaScript注入攻击。然而，由于内容安全策略[CSP]的进步以及攻击者绕过XSS过滤器的能力不断增强，现代浏览器已移除了对此头部的支持。如今，CSP指令作为防御XSS攻击的主要手段，使得X-XSS-Protection过时。
[已弃用] 公钥固定[HPKP]
HTTP公钥固定[HPKP]的引入是为了防止证书欺骗，允许网站指定未来HTTPS连接中应信任哪些加密密钥。服务器会提供有效证书公钥的哈希值，如下例所示：
|
|
虽然HPKP旨在加强安全性，但它被证明过于复杂且有风险——配置错误可能导致用户在较长时间内[例如两个月，由max-age定义]被锁定在网站之外。由于这些挑战，HPKP被弃用，取而代之的是证书透明度[CT]日志和Expect-CT头部——尽管该解决方案也未持久。
[已弃用] Expect-CT
在HPKP被弃用后，引入了Expect-CT头部作为强制执行证书透明度[CT]合规性的一种方式。此头部指示浏览器仅接受记录在公共CT日志中的证书，防止证书欺骗。典型的配置如下所示：
|
|
enforce指令阻止不合规的证书，而report-uri允许记录故障以供进一步分析。然而，行业最终放弃了Expect-CT，Mozilla现在建议完全禁用它。现代浏览器现在依赖证书透明度的自动强制执行，而无需专用的安全头部。
关键要点
虽然X-XSS-Protection、HPKP和Expect-CT曾被视为有价值的安全措施，但它们最终被证明无效或被更强大的替代方案[如CSP和证书透明度日志]所取代。这些弃用凸显了Web安全的不断演变，强调了与时俱进、遵循现代安全最佳实践的重要性。
使用Invicti跟上HTTP安全头部的最新动态
实施HTTP安全头部是增强Web应用安全性最简单且最有效的方法之一，通常几乎不需要对应用本身进行更改。然而，跟上不断发展的安全最佳实践和浏览器支持变更可能具有挑战性——尤其是在管理大量网站时。
为了帮助组织保持强大的安全态势，Invicti提供了自动化的漏洞扫描，包括对HTTP安全头部和其他错误配置的彻底检查。Invicti不仅检测安全头部的存在，还验证其正确实施，提供明确的建议以确保您的Web应用保持完全抵御新兴威胁。通过整合Invicti的安全测试，企业可以毫不费力地保持最新状态并维护强大的安全框架。