webappsec 升级不安全请求指南：如何用一条响应头快速完成全站 HTTPS 迁移

webappsec 升级不安全请求指南：如何用一条响应头快速完成全站 HTTPS 迁移

【免费下载链接】webappsecWeb Application Security Working Group repo项目地址: https://gitcode.com/gh_mirrors/we/webappsec

把整站从 HTTP 迁到 HTTPS，最怕的不是证书，而是页面上写死的http://资源链接。webappsec（W3C Web Application Security Working Group）工作组仓库中定义了一项名为upgrade-insecure-requests（升级不安全请求）的 CSP 指令规范，让你只需在响应头里加一行配置，浏览器就会自动把所有不安全资源请求升级为 HTTPS，无需改动一行源码即可快速完成全站 HTTPS 迁移。本文用最直白的方式，带你掌握这条"一条响应头"迁移大法。

为什么全站 HTTPS 迁移如此紧迫

先看三个现实压力，它们共同决定了"全站 HTTPS 迁移"这件事不能再拖：

• 明文传输风险：HTTP 下，密码、Cookie、表单数据都是明文在网络中裸奔，中间人攻击可以轻松窃取。上图中这类登录场景，一旦脱离 HTTPS 就毫无安全可言。
• 混合内容（Mixed Content）问题：页面升级到 HTTPS 后，如果里面还嵌着http://的图片、脚本、iframe，浏览器会直接拦截或降级安全指示，页面功能悄悄"坏掉"。
• 浏览器与搜索引擎的"不安全"标记：主流浏览器早已对非 HTTPS 站点显示"不安全"警告，影响用户信任与 SEO 排名。

所以迁移本身不难，难的是迁移后那些写死在数据库、老 CMS、历史文章里的http://链接怎么办——这就是升级不安全请求要解决的核心痛点。

什么是升级不安全请求（Upgrade-Insecure-Requests）

升级不安全请求是 webappsec 工作组制定的一项 W3C 规范，它的完整定义存放在仓库的specs/upgrade/index.html中，同时保留了多个历史发布版本（specs/upgrade/published/）。

它本质上是一条Content Security Policy（CSP）指令，作用一句话概括：让浏览器在发出请求之前，自动把页面中所有http://的资源请求改写为https://。改写发生在请求真正发出之前，意味着网络上根本不会出现明文请求，用户更安全，管理员也不用逐个改链接。

举个规范里的经典例子：老 CMS 里写死的图片链接

<img src="http://example.com/image.png">

在升级不安全请求生效后，浏览器会把它当作

<img src="https://example.com/image.png">

来处理，一切透明无感。

一条响应头完成全站 HTTPS 迁移：最快配置方法

整个迁移过程只需三步，核心就是那"一条响应头"。

第一步：准备证书与服务器 HTTPS 能力为域名申请证书、配置好 TLS，并确保你的资源在https://下可正常访问。这是升级的前提。

第二步：给所有 HTML 响应添加 CSP 响应头以 Nginx 为例，在 server 配置中加一行即可：

add_header Content-Security-Policy upgrade-insecure-requests;

也就是在响应头里输出：

Content-Security-Policy: upgrade-insecure-requests

第三步：验证效果打开浏览器开发者工具，在 Network 面板确认页面所有资源请求都以https://开头，且没有混合内容告警，迁移即告成功。

值得一提的是，规范特别强调：通过响应头下发策略，管理员可以不动任何源码，就把整组页面纳入升级机制——这对存量系统、历史归档内容尤其友好。

浏览器升级不安全请求的底层原理

理解升级范围，能帮你避开很多坑。根据specs/upgrade/index.html的定义，升级不安全请求的行为是分层的：

• 子资源请求全部升级：图片、脚本、样式、字体等所有http://子资源，统一改写为https://。
• 同源导航链接也会升级：页面里指向本站的<a href="http://...">链接，点击后会直接访问 HTTPS 地址，用户不会跑到"旧地址"上。
• 第三方站点的链接不会升级：指向其他站点的外链保持原样，避免误伤。
• 升级失败没有回退：如果某个域名实际不支持 HTTPS，升级后的请求会直接报网络错误，浏览器不会自动降级回 HTTP。

这也解释了为什么规范强烈建议：迁移前先确认所有第一方与第三方资源都能在 HTTPS 下访问。

全站 HTTPS 迁移常见的 3 个坑

坑一：第三方资源不支持 HTTPS比如老旧的 CDN、广告 SDK、统计脚本。升级后请求直接失败，页面资源缺失。对策是迁移前先与合作方确认 HTTPS 可用性，必要时先替换为支持 HTTPS 的服务。

坑二：升级失败无降级回退上面说过，升级是"硬"的，失败即失败。务必先做一轮资源可达性盘点，再开启响应头，避免线上事故。

坑三：重定向配置不当规范建议：对于携带升级意向的请求，服务器应返回307临时重定向到 HTTPS 地址。Nginx 中可以这样配合：

if ($http_upgrade_insecure_requests = "1") { add_header Vary Upgrade-Insecure-Requests; return 307 https://$host$request_uri; }

另外，上面的示意图来自仓库的 COOP 缓解指南（mitigation-guidance/COOP/），提醒我们：HTTPS 迁移往往还会牵扯重定向、弹窗、跨域隔离等一连串安全策略，建议按mitigation-guidance/目录下的分主题指南逐个排查。

upgrade-insecure-requests 与 HSTS 的关系

很多人会混淆这两个概念，其实它们分工明确：

• HSTS（HTTP Strict Transport Security）：强制浏览器"以后"必须用 HTTPS 访问本站，属于域名级别的长期策略。
• 升级不安全请求：针对"当前页面"的一次性内容升级，解决的是页面里残留的不安全资源请求。

规范明确指出，升级不安全请求并不打算替代 HSTS，两者是互补关系——升级不安全请求适合迁移过渡期，HSTS 负责巩固成果。webappsec 工作组还在admin/100_percent_https_roadmap.md中畅想了整个 Web 走向 100% HTTPS 的路线图，感兴趣可以一读。

迁移后还值得做的 3 件事

全站 HTTPS 迁移完成后，webappsec 仓库还提供了不少配套资料，建议顺手做齐：

1. 审查混合内容：参考specs/mixedcontent/规范，确保没有遗漏的明文资源。
2. 关注凭证与登录安全：登录、注册、第三方登录这类涉及账号密码的页面（仓库的usecases/credentialmanagement/里有完整的凭证管理用例），务必确认全程 HTTPS 加密传输。
3. 补全其他安全响应头：比如 CSP 全量策略（参考mitigation-guidance/CSP/的 FAQ 与specs/CSP2/）、Referrer-Policy 等，进一步加固站点。

小结

全站 HTTPS 迁移没有想象中可怕：一条Content-Security-Policy: upgrade-insecure-requests响应头，就能让浏览器自动升级不安全请求，帮你跳过"逐个改链接"的苦役。关键记住三件事：确保资源 HTTPS 可达、升级失败无回退、配合 307 重定向与 HSTS 巩固成果。如需查阅完整规范，可克隆 webappsec 仓库（git clone https://gitcode.com/gh_mirrors/we/webappsec）后重点阅读specs/upgrade/index.html、specs/mixedcontent/与admin/100_percent_https_roadmap.md，所有细节都在这份官方资料里。

【免费下载链接】webappsecWeb Application Security Working Group repo项目地址: https://gitcode.com/gh_mirrors/we/webappsec