网站上线检查清单：上线前必须完成的八项安全检查

1. 上线前检查清单总览

请检查你提供服务的每个公开名称，通常是裸域名和 www，并同时检查 http:// 和 https://。在切换 DNS 之前，可以用 curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ 在真实域名下测试新服务器，把示例 IP 换成新服务器的 IP 地址。

这八行对应免费的上线准备快照中的八项被动检查，该工具无需账户即可查看单个公开源站。下面的手动步骤比对单个源站的一次检查走得更远：它们涵盖每个主机名、两种协议、错误页面、DKIM 以及注册商设置。

2. DNS 解析：每个名称都指向新主机

为何重要。只迁移了一部分很容易被忽略：裸域名已在新服务器上，而 www 仍是指向旧平台的 CNAME。遗留记录同样是安全问题。OWASP 子域名接管指南说明了指向已删除云资源的 CNAME 如何让他人认领该子域名，以及悬空的 MX 记录如何让攻击者接收该子域名的邮件，甚至通过邮件验证获取证书。

检查方法。

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
dig +short NS example.com

为避免本地网络缓存了旧结果，请再用公共解析器重复查询（dig @1.1.1.1 …），然后逐条核对 DNS 服务商导出的完整区域文件。

良好结果。每个公开名称都解析到预期主机；只有主机确实通过 IPv6 提供网站时才存在 AAAA 记录；至少有两台名称服务器应答（这是 RFC 1034 规定的最低数量）；每条记录都有明确的用途和负责人。

常见修复。重新指向或删除过期记录。停用服务时，按 OWASP 建议的顺序操作：先更新或删除 DNS 记录，至少等待一个 TTL，然后再删除云资源。切换前，要提前调低 TTL，使旧的较长 TTL 在切换时已经过期，迁移稳定后再调回。

3. SPF、DMARC 和 CAA：代表你域名发声的记录

为何重要。任何人都可以把你的域名写进发件人（From）一栏。SPF 列出允许代表该域名发信的服务器，DKIM 对邮件签名，DMARC 则告诉收件方：当 SPF 和 DKIM 都无法与可见的 From 域名对齐通过时该如何处理。Gmail、Yahoo 和 Outlook.com 都要求批量发件人同时具备这三项。CAA 指定允许为你的域名签发证书的证书颁发机构，公共 CA 在签发前必须检查它。

检查方法。查询发件地址所用的域名，通常是注册域名而不是 www：

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CAA example.com

良好结果。

• SPF：恰好一条 v=spf1 记录，触发 DNS 查询的机制不超过 RFC 7208 规定的 10 个（嵌套 include 也计入），以 ~all 或 -all 结尾，绝不使用 +all。
• DMARC：类似 v=DMARC1; p=none; rua=mailto:dmarc@example.com 的记录，这样在收紧策略之前就能先收到报告。现行标准 RFC 9989（2026 年 5 月）指出，用户可能向邮件列表发信的域名不应发布 p=reject；仍希望使用的域名，应先在 p=none 下运行至少一个月，再在 quarantine 下运行同样长的时间，并对比报告。
• DKIM：每个代你发信的服务都用你的域名签名。公钥位于 selector._domainkey.example.com，因此查询时需要每个 selector；它出现在该服务所发邮件的 DKIM-Signature 头的 s= 标签中。
• CAA：为你使用的每个 CA（包括 CDN 使用的那个）设置类似 0 issue "letsencrypt.org" 的记录。没有 CAA 记录是允许的，而且 CAA 无法阻止已获授权的 CA 错误签发。

常见修复。合并重复的 SPF 记录，删除已停用服务的 include，并从 p=none 加报告开始部署 DMARC。硬失败并不一定更安全：RFC 9989 提醒，使用 -all 时，邮件可能在 DMARC 运行之前就因 SPF 结果被拒收，即使对齐的 DKIM 签名本可以通过，而这些拒收不会出现在 DMARC 报告中。收件方在子域名上找不到 DMARC 记录时，会沿 DNS 树向上使用父域名的策略；CA 则使用签发对象名称及其上级中最近的 CAA 记录，详见 Let's Encrypt 的 CAA 页面。因此 www 上缺少 _dmarc 或 CAA 记录本身并不构成缺口。SPF 与 DMARC 检查指南讲解如何读取和修复这些记录，免费的 SPF 和 DMARC 检测工具会查询你输入的主机名的 SPF、DMARC、MTA-STS 和 CAA 记录。

4. TLS 证书：有效、匹配，并且有人负责续期

为何重要。证书过期或与域名不匹配，访客会被浏览器警告拦住；在使用 HSTS 的主机上，他们甚至无法点击继续访问。续期也越来越频繁：根据 CA/Browser Forum 投票 SC081v3，2026 年 3 月 15 日起签发的公开信任证书有效期最长 200 天，2027 年 3 月起降至 100 天，2029 年 3 月起降至 47 天。Let's Encrypt 已于 2025 年 6 月 4 日停止发送到期提醒邮件。

检查方法。对每个主机名执行：

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -ext subjectAltName

也要单独运行 s_client：输出应包含 Verify return code: 0 (ok)，并显示协商出的协议。

良好结果。证书链可用服务器发送的中间证书验证通过，证书覆盖你提供服务的每个名称，连接使用 TLS 1.3 或 1.2，续期已自动化，运维手册写明了负责人。同时存在不依赖证书颁发机构的到期告警。

常见修复。用 ACME 自动续期。Let's Encrypt 建议使用 ACME 续期信息（ARI），或在证书生命周期约三分之二时续期，并警告：当证书有效期为 45 天时，固定 60 天的续期间隔将不再够用。迁移之后，要确认新平台确实在续期。一次握手只显示协商出的协议，所以请使用能列出所有受支持版本的扫描工具，确认 TLS 1.0 和 1.1 已关闭。

关于 HTTPS 访问过程中证书、HSTS 与浏览器其他保护如何协同，请参阅 HTTPS 工作原理指南。

5. HTTPS 跳转：一跳到 HTTPS，一个规范主机，然后启用 HSTS

为何重要。旧链接、书签、脚本和较旧的客户端仍会请求 http:// 地址。跳转会把它们带到 HTTPS，但正如 hstspreload.org 指出的，处于传输路径上的攻击者可以拦截并改写该跳转。HSTS 能为首次安全访问之后的每一次访问弥补这个缺口。

检查方法。

curl -sI http://example.com/
curl -sI http://www.example.com/
curl -sIL "http://example.com/page?x=1" | grep -iE '^(HTTP|location)'

良好结果。

• 按 MDN 的 TLS 指南建议，永久跳转（301，或为保留请求方法而使用 308）到同一主机上相同路径的 HTTPS 地址，之后最多再跳一次到规范主机。路径和查询字符串得以保留。
• HTTPS 响应发送 Strict-Transport-Security。浏览器会忽略明文 HTTP 上的该响应头，所以跳转本身不需要它。
• 没有混合内容：浏览器会拦截 HTTPS 页面中通过 http:// 加载的脚本。

常见修复。在服务器或 CDN 中做跳转，而不是用 JavaScript。分阶段把 HSTS 的 max-age 提高到较长的值，例如 31536000（一年），只有在每个子域名都提供 HTTPS 时才添加 includeSubDomains。hstspreload.org 目前推荐使用 HSTS，但不推荐预加载。如果证书使用 ACME 的 HTTP-01 验证，请保持 80 端口可访问。若要用上线准备快照测试此项，请输入 http:// 地址；输入裸域名或 https:// 地址时，它会改为检查 HSTS max-age 和混合内容。

6. 安全响应头：检查最终响应和错误页面

为何重要。安全响应头告诉浏览器页面可以加载什么、谁可以嵌套它以及如何处理内容类型。它们通常写在服务器或 CDN 的配置里，所以更换托管可能让它们丢失。它们能限制跨站脚本等漏洞造成的损害，但不能修复这些漏洞。

检查方法。

curl -sIL https://example.com/
curl -sI https://example.com/no-such-page

也要检查错误页面：正如 OWASP HTTP 响应头指南所指出的，不加 always 参数时，nginx 只会在特定状态码下发送 add_header 的值。

良好结果。简单网站合理的起步配置如下：

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

• 先以 Content-Security-Policy-Report-Only 的形式部署 CSP。它必须允许页面合法加载的所有内容，而 'unsafe-inline' 会使其大部分作用失效。
• frame-ancestors 不会从 default-src 继承，且在 <meta> 标签中会被忽略；X-Frame-Options: DENY 是较早的备用方案。
• 会话 Cookie 带有 Secure、HttpOnly 和明确的 SameSite（参见 MDN 的 Set-Cookie 说明）。HttpOnly 能阻止页面上的脚本读取该 Cookie（例如通过 document.cookie），但浏览器仍会在匹配的请求中发送它，因此它限制的是通过 XSS 窃取 Cookie，而不能阻止 XSS 本身。
• 不要使用 X-XSS-Protection 头，或将其设为 0。

常见修复。在同一层（服务器、应用或 CDN）设置响应头，使每个响应（包括错误页面）都恰好获得每个头一次。安全响应头检查指南详细解释了每个响应头，免费的 HTTP 安全响应头检测工具会对公开网站首页的八个关键响应头评级；错误页面请按上文所示用 curl 检查。

7. 技术信息暴露、缓存与压缩

技术信息暴露

为何重要。Server、X-Powered-By 和 generator 标签会让任何人知道你运行的软件，MDN 指出，详细的版本号会让已知漏洞更容易被找到。隐藏它们只是良好的卫生习惯，而不是真正的防护：OWASP 测试指南称之为靠隐匿求安全，MDN 则认为打补丁才是更可靠的做法。

检查方法。运行 curl -sI https://example.com/ | grep -iE '^(server|x-powered-by):'，然后在页面源码中搜索 generator，以及带有版本号的脚本文件名。

良好结果。Server: nginx 不带版本号，且没有 X-Powered-By。

常见修复。nginx 中使用 server_tokens off;，php.ini 中使用 expose_php = Off，Express 中使用 app.disable('x-powered-by')。如果页面暴露了过时的库，应当更新它，而不是隐藏它。

缓存、压缩与 CDN

为何重要。缓存规则决定谁能获得响应的存储副本。被 CDN 缓存的个人页面可能被提供给下一位访客，这正是 MDN 说个性化响应需要 Cache-Control: private 的原因。

检查方法。运行 curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/，然后登录，打开账户页面，在浏览器开发者工具中查看其响应头。

良好结果。HTML 以 Content-Encoding: br 或 gzip 提供；每个响应都有明确的 Cache-Control；只有带版本号的静态文件才使用较长的 max-age 加 immutable；含用户数据的页面使用 private 或 no-store（no-cache 仍允许存储）。

常见修复。按路由类型分别设置 Cache-Control，让登录后的路径不进入 CDN 缓存，并在服务器或 CDN 压缩文本。没有 CDN 本身并不是风险；速度方面请参阅网站性能指南。

8. 域名注册：到期时间、锁定与联系人

为何重要。.com 等通用顶级域名到期后，ICANN 的过期注册恢复政策要求注册商在一段时间内中断其 DNS 解析，于是网站和邮件会同时失效。续费提醒会发给登记的联系人，而对方可能是已离职的员工，或是即将到期的域名本身的邮箱。

检查方法。使用 ICANN 查询工具。自 2025 年 1 月 28 日起，RDAP 已成为通用顶级域名注册数据的权威来源；WHOIS 现在只对 .com、.name 和 .post 仍有强制要求。国家和地区代码域名请使用注册局或注册商自己的查询。然后登录注册商账户检查其设置。

良好结果。

• 距到期还有数月，已开启自动续费，并且付款方式在续费日仍然有效。
• 已设置 clientTransferProhibited，并在注册商提供时设置更新和删除锁；没有 clientHold 或 serverHold，它们会让域名从 DNS 中消失。
• 联系人能联系到不止一个人，至少有一个地址不在该域名本身下，并且注册商账户启用了多因素登录。

常见修复。开启自动续费，一次续费数年，请注册商设置锁定状态（ICANN 的 EPP 状态码指南解释了每一种），并更新联系人。

9. 本清单没有涵盖什么

这八项描述的是网站周围的公开配置。一个网站可以通过全部检查，却依然很容易被入侵，因为它们都没有检查应用本身及其运行方式。请另行审查以下内容：

• 应用漏洞：注入、模板中的跨站脚本、不安全的上传、账户之间的访问。
• 认证与会话：登录、密码重置、多因素认证、管理后台。
• 依赖与服务器：CMS 插件、软件包、操作系统补丁。
• 密钥与访问：存放在代码仓库或前端打包文件中的密钥，以及谁能访问生产环境、DNS 服务商和注册商。
• 备份：一次你真正测试过的恢复。

网站安全审计指南介绍登录、权限及其他应用侧检查，OWASP Web 安全测试指南则给出详细的测试用例。

对单个源站做一次快速初查。免费的上线准备快照无需账户。对一个公开源站，它读取公开 DNS、邮件 DNS 记录、域名注册数据、TLS 握手和首页的 HTTP 响应，不会发送漏洞利用、端口扫描、登录尝试或负载。你会得到一个评分、一个加固等级、风险信号和通过检查的数量，以及最多三个需要优先查看的信号。它不是渗透测试：好成绩只表示这些公开信号在当时看起来是健康的。Free 套餐只包含安全检查；Free 工作区可以用审计积分在其他领域单独运行审计（每个新的 Free 工作区在每个领域各有 1 个积分）。六个审计领域（安全、技术 SEO、AI 可见性、无障碍、性能、集成）从 Starter 套餐起全部包含，每月 $49。

想了解应用中的完整流程，可以参考 Stepthrough 在 learn.ynteractive.com 上发布的带真实界面的分步教程。教程涵盖验证网站所有权，运行安全、技术 SEO、AI 可见性、无障碍和性能审计，以及为发现的问题排定优先级。