Defaults.Exposed › 修复 › HSTS（严格传输安全）

如何修复 HSTS（严格传输安全）

HSTS 是你的网站给每一个浏览器下的一行指令：「以后永远通过安全、加密的连接来找我——绝不要走不安全的那条。」没有它，你的那把锁可以在共享 WiFi 上被悄悄剥掉，而对你网站的头一次访问就是暴露的。

对您业务的关键影响： 有 HTTPS（那把锁）不等于强制使用它。没有 HSTS，一个和你客户在同一 WiFi 上的攻击者可以悄悄把连接降级到普通、未加密的 HTTP——在客户察觉不到任何异常的情况下，捕获登录、卡号和表单数据。你那张可能还在花钱的 SSL 证书就被绕过了。修复免费，运营你网站的人约 15 分钟即可完成。

这会让您付出什么代价

在咖啡馆、酒店、机场或会议 WiFi 上的客户，可能在屏幕上没有任何警告的情况下，被悄悄降级连接、被读取数据。
你为 HTTPS 付了钱、有了那把锁，但没有 HSTS，攻击者干脆绕过去；证书给了一种虚假的安全感。
对你网站的头一次访问（在跳转到 HTTPS 之前）正是攻击者瞄准的薄弱点——HSTS 正是为每一次回访关上它的东西。
一份安全问卷、网络保险表单或企业买家的清单标记出「没有 HSTS」，让生意搁置，直到修好。
把值设错（太短），你就两头不讨好：看起来配好了，实际几乎没有真正的保护。

为什么它重要。 HTTPS 在连接已经加密后保护它——但它不强制浏览器使用加密。攻击者用「SSL 剥离」钻这个空子：在任何共享网络上，他们悄悄让访客停留在不安全的 HTTP 上，读取一切。HSTS 告诉浏览器对你的域名彻底拒绝普通 HTTP、并持续很长时间，于是这个缺口在第一次访问后就关上了。它是一个响应头，免费即可添加，而在我们的评分里它值实打实的分数，因为一个缺失或太短的值会让每一个公共 WiFi 上的访客暴露。

这是什么，大白话版

你几乎肯定有 HTTPS——浏览器栏里那把小锁。很好。但这里有几乎没人被告知的部分：有 HTTPS 不等于强制 HTTPS。

HTTPS 让连接在浏览器决定使用它之后变得加密。HSTS——是 **HTTP Strict Transport Security（HTTP 严格传输安全）**的缩写——是那句让浏览器始终使用它的指令。它是你网站发给每个访客的一行看不见的文字，实质上说：

「从现在起，对我的域名，只通过安全连接和我对话。绝不走不安全的。连试都别试。」

浏览器会记住它、并按你告诉它的时长服从——通常是一年。在访客第一次安全访问之后，他的浏览器就干脆拒绝通过普通、未加密的 HTTP 加载你的网站，哪怕有什么东西试图强制它。

没有 HSTS，那条「始终使用安全版本」的规则就不存在——而攻击者恰恰知道如何利用这个缺口。

这会让你付出什么代价

下面是现实、日常的情景。我们从不点名任何真实企业；这些是这个缺口如何被利用的例证。

咖啡馆里的结账。 一个客户在咖啡馆 WiFi 上打开你的店铺去结账。同一网络上的攻击者跑一个免费、广为人知的工具，让客户停留在普通 HTTP 而非 HTTPS 上。客户看到的是一个看起来正常的网站——没有警告，瞥一眼的那个位置也没有破损的锁——于是输入了卡号。攻击者读到每一次击键。你的 SSL 证书什么都没做，因为连接从一开始就没被允许变安全。
出差的员工。 一名员工从酒店或机场登录你的后台或网页邮箱。同样的降级把戏捕获了他的用户名和密码。现在攻击者有了进你公司的路——不是因为你的密码策略弱，而是因为登录页面可通过不安全的 HTTP 抵达。
搁浅的生意。 一个大客户在签约前给你发来他们的标准安全问卷。其中一行问：「你的网站是否通过 HSTS 强制 HTTPS？」你的 IT 联系人不得不答「否」，于是采购流程暂停，而你手忙脚乱地去修一个免费的、15 分钟的设置——它现在在一个买家面前看起来像一面红旗。
网络保险或合规检查。 一家保险公司的扫描，或一位审查你数据保护态势的审计师，标记出这个缺失的头。个人数据的加密在数据保护规则下是一项明确的期望（GDPR 第 32 条），而「我们有证书但不强制它」是个站不住脚的位置。
虚假的安全感。 你为 SSL 付着钱，锁显示着，所有人都以为网站安全。它大体上是安全的——直到一个客户处在共享网络上，而那恰恰是他最脆弱、又最不可能察觉异常的时候。

贯穿的主线：代价不抽象。它是一个真实客户的卡或登录，在最糟糕的时刻被捕获，而且没有任何警报响起。

它到底是什么

当浏览器向你的网站请求一个页面时，你的服务器送回页面外加一些看不见的「头」——浏览器读取、访客却从不会看到的额外指令。HSTS 就是其中之一：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

三个部分要紧：

max-age——浏览器应记住强制 HTTPS 多久（以秒计）。31536000 是一年。这是它的核心：太短就几乎没用。
includeSubDomains——把规则扩展到每一个子域名（shop.、app.、mail. 等），不只是你的主地址。
preload——把你的域名选入一个内置于浏览器的主列表，让保护哪怕在访客的第一个请求上也生效，在他们见过你的网站之前。

为什么「第一次访问」要紧

HSTS 有一个固有局限：浏览器只在至少见过这个头一次之后才服从规则。所以一个全新访客的第一次连接仍是一个微小的暴露窗口。两样东西收窄它：一个 HTTP 到 HTTPS 的跳转（迅速把他们送上安全版本）和 preload（彻底移除这个窗口）。这正是为什么一个完整的配置会把 HSTS 与一个正经的跳转配对。

「好」长什么样——以及它如何评分

我们的检查读取你的实时头，并给 max-age 评分：

max-age 值	它意味着什么	结果
一年或以上（≥ 31536000）	优秀——推荐的设置	满分
六个月或以上（≥ 15768000）	不错，但不到整年	部分分
一天或以上（≥ 86400）	弱——太短不可靠	低 / 部分分
不足一天，或根本没有头	实质上没有保护	失败（高严重度）

所以一个存在却被设成几分钟的头，被当作失败——它看起来配好了，实际没在干活。瞄准一年。检查还会注明 includeSubDomains 和 preload 是否存在。

如何修复（免费，约 15 分钟）

把这一节交给运营你网站的人——你的 IT 人员、网页开发者或主机商支持。修复免费。 它是一个头，或你主机平台里的一个开关。没什么要买的。

先来一条重要的顺序规则： HSTS 是黏的——一旦启用，浏览器会在整个 max-age 期间拒绝对你域名走普通 HTTP。所以在广泛打开它之前，确认 HTTPS 在你的主站以及每一个子域名上都正确工作。稳妥的路径是：用一个短值测试 → 确认没有东西坏掉 → 升到一年。

第 1 步——先确保 HTTPS 已经到处都能用

通过 https:// 访问你的网站和关键子域名，确认它们带着一张有效证书干净地加载。也确认普通 http:// 请求会跳转到 https://。（如果不跳，先修好 HTTP 到 HTTPS 的跳转——HSTS 假定它已就位。）

第 2 步——添加这个头（选你的平台）

Cloudflare（或类似 CDN）： 这最简单。前往 SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) 并启用它。把 Max-Age 设为 6 个月或 12 个月，并在你确定所有子域名都在 HTTPS 上之后，启用「Apply HSTS policy to subdomains」。

Nginx： 在你的 HTTPS server 块里加：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache： 确保 mod_headers 已启用，然后加到你的 HTTPS 虚拟主机：

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Microsoft IIS： 加到 web.config 的 <customHeaders> 内：

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

Google Workspace / Microsoft 365 说明： 这些驱动的是你的邮件，不是你的网站托管——HSTS 设在你公开网站实际所在的地方（你的 CDN、Web 服务器或建站工具），而不是 Workspace/365 管理后台。如果你的网站在 Squarespace、Wix 或 Shopify 这样的建站工具上，HSTS 通常已替你处理好；如果我们的检查标记了它，去看它们的 SSL/安全设置。

第 3 步——小步测试，再正式提交

从 max-age=300（5 分钟）起步。确认网站到处仍完美加载。然后把它升到 max-age=31536000（一年）。那是满分的设置。

第 4 步（可选，黄金标准）——preload

等你有把握、且已经跑了一段时间带 includeSubDomains 的一年头之后，你可以在 hstspreload.org 提交你的域名，把它烤进浏览器。这彻底关上第一次访问的窗口。把它当作一个深思熟虑的承诺——从列表里移除一个域名很慢。

常见错误

把 max-age 设得太短。 一个几分钟或几小时的值看起来配好了，却几乎没有保护——而我们的检查把任何不足一天的当作失败。用一年。
在子域名还没准备好 HTTPS 时就打开 includeSubDomains。 如果一个子域名没完全在 HTTPS 上，那条黏规则会让它对访客变得无法访问。先把每一个子域名搬上 HTTPS。
加了 HSTS 却没有 HTTP 到 HTTPS 的跳转。 HSTS 假定访客抵达安全版本；没有跳转，第一次访问就被白白暴露。两个一起修。
为「彻底」而直接跳到 preload。 preload 很难撤销。在一个稳定的一年头之后逐步赢得它——别急。
以为那把锁就代表你被覆盖了。 那把锁和 HSTS 是不同的东西。你可以有一张完美的证书，却仍未通过这项检查。

常见问题

我们已经有 HTTPS、那把锁也显示了。这还不够吗？

不够——而且这是迄今最常见的误解。那把锁意味着连接「能」被加密；它不强制浏览器使用加密版本。没有 HSTS，同一网络上的攻击者能让访客停留在普通 HTTP（叫做 SSL 剥离），读取他输入的一切，而客户看到的是一个看起来正常的网站。HSTS 是那句让「仅限加密」成为强制的指令。没有 HSTS 的 HTTPS，是一扇上了锁却没真正插上的门。

打开它贵不贵、有没有风险？

修复本身免费——它是你 Web 服务器里的一行、或你 CDN 里的一个开关——约 15 分钟。唯一要真正当心的：HSTS 是「黏」的。浏览器一旦见到它，就会按你指定的时长拒绝对你域名走普通 HTTP。所以在广泛启用前，你必须确信 HTTPS 在你的主站「以及」每一个子域名上都能用。先用一个短的测试值起步，确认没有东西坏掉，再把它升到一年。按这个顺序来，风险微乎其微。

「好」到底长什么样？

max-age 至少一年（31536000 秒）。我们的检查在一年或以上给满分，半年给部分分，一天给弱/部分分，并把任何不足一天的当作实质上不存在。最强的配置还会加上 includeSubDomains（覆盖 shop.yoursite.com、app.yoursite.com 等）和 preload（把保护烤进浏览器，让哪怕头一次访问也安全）。

什么是「preload」，我们需要它吗？

HSTS 只在浏览器至少见过这个头一次「之后」才保护访客——所以一个全新访客的第一个请求仍是一个小窗口。内置于 Chrome、Firefox、Safari 和 Edge 的 HSTS preload 列表，通过提前把你的域名装进浏览器来关上那个窗口。它是可选的、且是一个略大的承诺（移除很慢），但它是黄金标准。对多数小企业，一个带 includeSubDomains 的一年 max-age 已是一个强壮、稳妥的结果；preload 是你安顿下来后的额外一步。

我们用 Squarespace / Wix / Shopify——我们到底需不需要做什么？

多数全托管的建站工具（Squarespace、Wix、Shopify 等）强制 HTTPS，并常常自动为你设好 HSTS——所以你可能已经通过、无需做任何事。例外是当你在网站前面用了自定义域名或 CDN 时；那时这个设置可能从缝隙里漏掉。跑一下检查：通过就完事；标记了，修复就是你平台 SSL/安全设置里的那个开关，或你 CDN 里的一行。

如果我们不修，会拉低我们的评分吗？

会。HSTS 是一项计分的网站安全检查，不是参考性的——一个缺失或太短的头会扣分、且被评为高严重度，因为它直接在共享网络上暴露你访客的数据。它也是最便宜就能找回的分数之一：一个免费的头，约 15 分钟的活儿。