HSTS 头配置实战：用 Strict-Transport-Security 根除 SSL Stripping 降级攻击（Front-End-Checklist 安全规则深度解析）

HSTS 头配置实战用 Strict-Transport-Security 根除 SSL Stripping 降级攻击Front-End-Checklist 安全规则深度解析【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-ChecklistHTTP Strict Transport SecurityHSTS是 Web 安全体系中一项关键的基础设施级防护仅凭一个响应头就能让浏览器在任何网络请求发出之前把 HTTP 强制升级为 HTTPS从而彻底封堵 HTTPS 站点在首次 HTTP 请求环节被中间人剥离 TLS 的经典漏洞。本文以 Front-End-Checklist 项目中的 hsts 安全规则文档为骨架结合仓库内规则源文件、技能定义与实际 Next.js 配置完整讲解 HSTS 的指令语义、Nginx/Apache/Next.js/Express 四种配置写法、Preload 提交的准入条件与风险以及可落地的验证与排查流程读完即可在你的站点上正确部署并验证 HSTS。规则速览这条规则在检查什么在 Front-End-Checklist 仓库中hsts 规则以两种形态存在供人类开发者与 AI Agent 共同使用结构化规则源文件packages/content/rules/en/security/hsts.mdx其中 frontmatter 声明了规则的元信息分类security、子分类headers、优先级high、难度intermediate、预估耗时 15 分钟技能定义与完整参考skills/hsts/SKILL.md 与 skills/hsts/references/rule.mdSKILL.md 明确其适用场景是审查任何通过 HTTPS 提供内容的站点的 HTTP 响应头。规则的核心检查点是服务器是否在所有 HTTPS 响应上发送Strict-Transport-Security头并且max-age、includeSubDomains、preload三个指令的组合是否恰当。这条规则与x-content-type、content-security-policy、x-frame-options、referrer-policy同属security/headers领域见 hsts.mdx 的relatedRules在实际安全审查中通常被一并评估。HSTS 是什么一个响应头消除首访降级窗口HSTS 由 [RFC 6797] 定义原文引用自 skills/hsts/references/rule.md此处不展开外部链接。它的作用机制很简单服务器在 HTTPS 响应中返回Strict-Transport-Security头浏览器收到后在max-age指定的时间段内对该域名始终强制使用 HTTPS——即使你手动在地址栏输入http://的 URL或者点击了一个未加密的旧链接浏览器也会在发起网络请求之前把地址内部升级为 HTTPS。其意义在于消除 HTTP-to-HTTPS 重定向链中天然存在的脆弱窗口在没有 HSTS 的情况下用户首次访问http://版本会触发一次 301 重定向到 HTTPS而恰恰是这第一次明文请求给了中间人可乘之机详见后文SSL Stripping 攻击剖析。核心配置示例Strict-Transport-Security: max-age31536000; includeSubDomains指令详解指令必填说明max-ageseconds是浏览器缓存该 HSTS 策略的时长秒。最低建议使用315360001 年HSTS Preload 提交也强制要求至少 1 年includeSubDomains推荐将 HSTS 策略应用到所有子域名。若计划提交 Preload 列表则为必填preload可选声明域名有意加入浏览器内置的 HSTS Preload 列表。加入前必须仔细阅读下文的风险警告需要特别强调HSTS 头只在 HTTPS 响应上生效通过 HTTP 明文发送的 HSTS 头会被浏览器忽略。为什么重要SSL Stripping 攻击剖析SSL StrippingTLS 剥离是经典的中间人MITM攻击手法规则文档skills/hsts/references/rule.md给出了清晰的攻击场景没有 HSTS 时用户首次访问站点的 HTTP 版本站点返回一个重定向到 HTTPS。攻击者若与用户处于同一网络如公共 Wi-Fi可以拦截这第一次 HTTP 请求并剥离 TLS把连接静默降级为明文——浏览器永远看不到那个重定向用户随后通过明文 HTTP 与站点交互会话 Cookie、表单数据全部暴露在网络上。这正是 OWASP 在 HSTS 防护指南中要解决的经典问题。HSTS 的价值在于它把是否使用 HTTPS的决定权从可被劫持的网络链路中抽离出来交给浏览器本地缓存的安全策略。工作原理浏览器端的强制升级三步流程HSTS 生效后浏览器行为如下依据 skills/hsts/references/rule.md 的三步流程浏览器在首次 HTTPS 响应中收到Strict-Transport-Security头浏览器将该 HSTS 策略缓存max-age秒含includeSubDomains时覆盖全部子域名此后所有对 HTTP 版本的导航都会在发出任何网络请求之前被浏览器内部升级为 HTTPS——攻击者根本看不到明文 HTTP 流量。关键在于第 3 步的时机升级发生在网络请求之前因此从源头切断了 SSL Stripping 的介入点。若没有 HSTS仅依赖 301 重定向则每次用户通过书签或手动输入 HTTP 地址访问时浏览器都会先发出明文请求再跟随重定向中间的每一跳都是攻击面。服务器配置实战Nginx在 HTTPS 的 server 块中加入add_header并带上always参数确保错误响应等场景也携带该头server { listen 443 ssl http2; server_name example.com; add_header Strict-Transport-Security max-age31536000; includeSubDomains always; }Apache使用mod_headers模块的Header always set指令完整写法参考规则源文件 packages/content/rules/en/security/hsts.mdx建议用IfModule包裹以保证模块未启用时配置不会报错IfModule mod_headers.c Header always set Strict-Transport-Security max-age31536000; includeSubDomains /IfModuleNext.jsnext.config.js在 Next.js 中通过async headers()为匹配路由注入安全头/** type {import(next).NextConfig} */ const nextConfig { async headers() { return [ { source: /(.*), headers: [ { key: Strict-Transport-Security, value: max-age31536000; includeSubDomains, }, ], }, ] }, } module.exports nextConfig仓库实例参考本仓库的 Web 应用 apps/web/next.config.js 正是采用这一模式通过async headers()对/:path*全路径注入集中定义的securityHeaders数组apps/web/next.config.js数组内包含Content-Security-Policy、Referrer-Policy、Permissions-Policy、X-Content-Type-Options、X-Frame-Options等头部并把 HSTS 同族的其他安全头统一管理便于维护与审计。此外该配置在生产环境还会在 CSP 中追加upgrade-insecure-requests指令apps/web/next.config.js强制浏览器将所有不安全的子资源请求升级为 HTTPS——它与 HSTS 的强制 HTTPS目标同向互补可以叠加使用。需要说明的是HSTS 头通常更适合由托管平台或 CDN 边缘层统一注入因为只应通过 HTTPS 发送团队可按部署拓扑选择注入层。Express.js使用 HelmetHelmet 内置了 HSTS 的封装helmet.hsts()通过对象参数映射三个指令import helmet from helmet app.use( helmet.hsts({ maxAge: 31536000, includeSubDomains: true, }) )其中maxAge对应max-age单位秒includeSubDomains: true对应追加includeSubDomains。若要添加preloadHelmet 还支持preload: true选项对应追加preload指令。HSTS Preloading把域名写进浏览器内核常规 HSTS 是渐进式防护用户必须至少成功访问过一次 HTTPS 并收到响应头策略才会在浏览器中生效首次访问仍然可能走明文 HTTP。Preload 则更进一步将你的域名硬编码进浏览器发行版的内置列表浏览器对该域名的请求永远不发起明文 HTTP 请求包括首次访问。Strict-Transport-Security: max-age31536000; includeSubDomains; preload要进入 Preload 列表规则文档列出的准入条件如下提供有效的 TLS 证书在同一主机上把 HTTP 重定向到 HTTPS以至少315360001 年的max-age提供 HSTS包含includeSubDomains包含preload所有子域名都必须可以通过 HTTPS 访问。高风险警告一旦域名进入 Preload 列表移除请求需要数周到数月才能传播到所有浏览器。因此在添加preload之前必须确认所有子域名都已正确提供 HTTPS——任何配置错误的子域名对 Preload 列表中的浏览器而言将直接变得不可访问。规则文档skills/hsts/references/rule.md与规则源文件中的Warning组件packages/content/rules/en/security/hsts.mdx都对此发出明确警示先充分测试再提交 Preload。常见错误与修复对照表错误影响修复通过 HTTP 发送 HSTS头被忽略任何已缓存该策略的浏览器将被锁死无法回退到 HTTP只在 HTTPS 上发送 HSTSmax-age过短如 300提供的保护极其有限使用315360001 年缺少includeSubDomains子域名仍易受降级攻击若所有子域名均提供 HTTPS则加上includeSubDomains未测试就启用preload子域名若缺乏 HTTPS 将变得不可达仅在确认所有子域名正常后再添加preload例外与权衡规则文档还给出了三条务实的例外原则skills/hsts/references/rule.md缺失或弱化的 HSTS 头应结合线上生产环境的实际响应路径来评估而非仅看框架或服务器配置的孤立片段——CDN、WAF、托管平台可能改写或覆盖响应头遗留系统集成或嵌入的第三方内容可能需要窄范围的例外但必须显式记录在案而不是默认保持宽松当多个安全头同时缺失时应优先修复能消除最高可利用性或浏览器能力风险的头部本规则属于传输层防护可与content-security-policy、x-frame-options等按此原则排序处理。支持范围与浏览器兼容矩阵规则文档声明该特性在当前项目的浏览器矩阵中受支持并给出基线兼容的最低版本Chrome 115Edge 115Firefox 116Safari 16.4Safari iOS 16.4若项目的目标环境落在上述范围之外规则建议补充回退方案或采用更窄的策略说明。验证与排查流程Check / Fix / Explain / Code Reviewhsts 技能在 skills/hsts/SKILL.md 中定义了四段式可执行流程AI Agent 或开发者可照此审查Check检查服务器是否在所有 HTTPS 响应上发送Strict-Transport-Security头并核对max-age、includeSubDomains、preload指令是否恰当Fix为所有 HTTPS 响应添加max-age31536000且含includeSubDomains的 HSTS 头在 Web 服务器或 CDN 层配置并用 curl 或安全头扫描工具验证Explain解释 HSTS 是什么、如何阻止 SSL Stripping、max-age与includeSubDomains的作用以及为何preload需要谨慎Code Review审查服务器配置、响应头、表单与集成点标记违反规则的精确响应、Cookie 或浏览器行为并对照真实的生产级响应进行核验。自动化检查用 curl 抓取代表性的线上响应并检查有效响应头例如curl -sI https://example.com | grep -i strict-transport-security也可使用安全头扫描器等工具对多条真实响应路径做批量检查。注意检查对象应是经过 CDN/负载均衡后的实际对外响应而非源站配置本身。手动检查在接近生产的环境中手动验证浏览器端行为确认不存在更强的冲突性安全信号例如代理改写或 WAF 移除头部导致策略未生效。与相邻安全规则的协同HSTS 通常不是孤立配置而是 HTTPS 传输链路中的一环。仓库中的 packages/content/rules/en/security/http-to-https.mdx优先级 critical与 hsts 规则互为补充它要求在服务器/CDN 层把http://永久重定向301到 HTTPS并强调在验证 HTTPS 与重定向稳定之后再添加 HSTS 以彻底消除后续的 HTTP 请求。其relatedRules同样把 hsts 列为协同规则并指出 HSTS 能让浏览器在看到策略后在发起任何网络请求之前内部升级连接从而让重定向对回访用户完全透明。实践中的推荐顺序是先完成 301 重定向并验证 HTTPS 全链路可用 → 添加Strict-Transport-Security: max-age31536000; includeSubDomains仅 HTTPS 响应→ 确认所有子域名 HTTPS 正常后再评估是否追加preload并提交 Preload 列表。这样既能立刻消除 SSL Stripping 窗口又能避免因未充分测试而把错误的子域名配置固化进浏览器内核。进一步阅读规则完整参考见 skills/hsts/references/rule.md结构化规则源文件与元数据见 packages/content/rules/en/security/hsts.mdx技能定义见 skills/hsts/SKILL.md仓库生产环境的安全头组织方式可参考 apps/web/next.config.js。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考