Web-Security · XB 现场笔记

CAA 记录应授权你实际使用的签发者

Sun, 23 Aug 2026 00:00:00 +0000

认证机构授权（CAA）记录让域名持有者声明，哪些证书颁发机构可以为该域名签发证书。只有当记录与真实续期路径一致、且操作者理解策略如何从父级名称继承时，它才有用。

检视当前策略

查询确切主机名及其父名称：

for name in www.example.test example.test test; do
 printf '== %s\n' "$name"
 dig +noall +answer CAA "$name"
done

叶子处空的应答不一定意味着没有适用策略。根据 DNS 规则，CAA 处理可能继续向上。诊断变更时使用权威应答，并与至少一个递归解析器比较。

匹配账户的签发者标识

记录使用如 issue 或 issuewild 等标签与一个签发者域值：

example.test. 3600 IN CAA 0 issue "letsencrypt.org"

该值是授权标识，不是证书里的显示名。在证书颁发机构的当前文档中确认它。通配符授权可能需要单独的 issuewild 策略。

在续期前编排 DNS 变更

在当前证书健康时添加或收紧 CAA。从整上一个 TTL 等待，查询权威与递归应答，并运行 ACME 客户端支持的暂存或续期测试。准备好回滚记录。

不要在过期事故期间添加限制性记录，除非签发者路径已验证。一条语法正确但错误的策略，会把自动续期变成硬失败。

观察签发失败

CAA 检查发生在签发时，而不是每次 HTTPS 请求。因此证书监控必须同时覆盖当前过期与续期尝试。把有效的 DNS 应答随 ACME 失败一起记录，而不是只记录一条笼统的授权错误。

来源

RFC 8659 — DNS Certification Authority Authorization，CAA 查询与属性语义，已核验 2026-08-23。
Let’s Encrypt: CAA，签发者标识与运维指引，已核验 2026-08-23。

Content-Type 应描述你实际发送的字节

Sun, 23 Aug 2026 00:00:00 +0000

静态服务器可能返回正确的字节，却带上错误的 Content-Type。某个浏览器里页面看起来或许还正常，但下载、样式表、订阅阅读器或安全策略会把同一响应理解成别的东西。公开响应头才是契约；文件名只是服务器配置的输入。

检查有代表性的格式

检查一份 HTML 文档、样式表、SVG、feed 与可下载脚本。包含响应头但丢弃正文：

for path in / /assets/site.css /favicon.svg /index.xml /downloads/check-http-headers.sh; do
 curl -sS -D - -o /dev/null "https://www.example.test$path" \
 | awk -v path="$path" '
 BEGIN { print "== " path }
 /^HTTP\// || tolower($1) == "content-type:" || tolower($1) == "x-content-type-options:" { print }
 '
done

期望的媒体类型因资源而异，但应该具体且稳定。HTML 通常应包含字符集。CSS 与 SVG 不应被当作泛型二进制数据提供服务。用于下载的 shell 脚本不应被声明为 HTML。

保持 nosniff 一致

X-Content-Type-Options: nosniff 请求支持它的浏览器在脚本与样式目标上尊重声明的类型，而不是猜测。它之所以有用，是因为不匹配会变成可见的失败，而不是因浏览器而异的解读。

该响应头并不能修复一个错误的类型。只有在同时有能证明声明值正确的资源清单时才启用它：

X-Content-Type-Options: nosniff

检查服务器映射

静态服务器通常根据扩展名推导类型。如果某个新扩展名被当作 application/octet-stream 提供服务，先判断这是否有意为之，再决定是否加入全局覆盖。一个窄映射比一条会改变所有响应的规则更容易复核。

在公开主机名上重复这些检查。CDN 或反向代理可能替换掉正确的源站响应头；而一个友好的错误页可能为后缀像 CSS 或 JavaScript 的路径返回 HTML。

来源

RFC 9110 — HTTP Semantics，表示元数据与 Content-Type，已核验 2026-08-23。
MDN: Content-Type，媒体类型与字符集示例，已核验 2026-08-23。
MDN: X-Content-Type-Options，nosniff 行为，已核验 2026-08-23。

Cookie 作用域应比应用边界更窄

Sun, 23 Aug 2026 00:00:00 +0000

Cookie 依据浏览器规则附加到请求，而不是依据最初设置它的服务器组件。宽泛的 Domain 或 Path 会把状态暴露给无关的路由或子域名，而缺失传输与脚本限制则会放大其他失败造成的损害。

当省略 Domain 时，Cookie 被限定在设置它的主机内。加上 Domain=example.test 则它也允许发给符合条件子域名。只有多个主机确实共享同一应用与信任边界时才使用更宽的形式。

检视响应而不把真实 Cookie 值打进日志：

curl -sS -D - -o /dev/null https://app.example.test/login \
 | awk '
 tolower($1) == "set-cookie:" {
 sub(/Set-Cookie: [^;]*/, "Set-Cookie: [value redacted]")
 print
 }
 '

一起复核这些属性

Secure 把传输限制在安全上下文中。
HttpOnly 通过 document.cookie 阻止 JavaScript 访问；它不会阻止浏览器发送该 Cookie。
SameSite 影响跨站请求，必须匹配应用的导航或嵌入需求。
Path 控制发送时机，但它不是同一主机上不同应用之间的授权边界。

在现代浏览器中，SameSite=None 的 Cookie 还需要 Secure。避免把这对组合复制进不需要跨站用途的应用。

在其约束契合时使用前缀

__Secure- 与 __Host- 等 Cookie 名称前缀，让支持的浏览器强制额外的要求。__Host- Cookie 必须使用 Secure、省略 Domain、并使用 Path=/，这使主机专用的意图变得显式。

用相同作用域测试删除

删除 Cookie 需要一条与存储它所用属性匹配的过期指令，尤其是名称、域名与路径。只清除一个变体的登出可能让另一个 Cookie 仍然有效。

一个真正静态的文档站点通常没有理由设置应用 Cookie。核验公共响应不含 Set-Cookie 响应头，而不是为站点并不需要的存储增加一个同意界面。

来源

RFC 6265 — HTTP State Management Mechanism，Cookie 存储与作用域，已核验 2026-08-23。
MDN: Set-Cookie，属性与名称前缀，已核验 2026-08-23。

HSTS 应带着恢复计划来灰度发布

Sun, 23 Aug 2026 00:00:00 +0000

HTTP Strict Transport Security 告诉支持的浏览器，在一个缓存周期内对该主机强制使用 HTTPS。这种持久性既是特性也是风险：移除响应头并不会立刻抹掉客户端已存储的策略。

先验证 HTTPS 路径

在发送 HSTS 之前，确认规范主机名提供有效证书，并且 HTTP 在不依赖用户输入的情况下重定向到预期的 HTTPS URL：

curl -sS -D - -o /dev/null --max-redirs 0 http://www.example.test/
curl -sS -D - -o /dev/null https://www.example.test/

检查有代表性的深层路由与错误页。HSTS 无法修复证书错误，因为浏览器在接受该策略之前要求有效的 HTTPS 连接。

从一个短的 max-age 开始

分阶段发布能在配置还新的时候限制恢复窗口：

Strict-Transport-Security: max-age=300

观察站点与续期路径之后，再有意识地提高时长。记录日期、所选值与回滚条件。最终策略可能用一年，但这个数字是一种承诺，而不是扫描器分数。

把 includeSubDomains 当作独立的决定

includeSubDomains 把策略扩展到每个子域名。先盘点名称，包括旧服务、委派区，以及只在内部网络使用的主机名。即使只有一个仅 HTTP 的后代，也足以让该选项对收到父级策略的客户端产生破坏。

预加载不是普通的响应头配置

浏览器预加载程序可以在正常响应周期之外分发策略，其要求与移除延迟比设置一个响应头更严格。不要仅仅因为扫描器推荐就申请预加载；请先确认对域名及所有被覆盖名称的长期所有权。

验证公共响应

curl -sS -D - -o /dev/null https://www.example.test/ \
 | awk 'tolower($1) == "strict-transport-security:" { print }'

测试规范的公共边缘，而不只是某个源站端口。代理可能添加、移除或重复该响应头。

来源

RFC 6797 — HTTP Strict Transport Security，策略处理与作用域，已核验 2026-08-23。
MDN: Strict-Transport-Security，指令与部署注意事项，已核验 2026-08-23。

安全响应头应描述实际页面

Sat, 22 Aug 2026 00:00:00 +0000

安全响应头不是安全代码的替代品，但它们让浏览器强制实施有用的边界。策略应描述实际被服务的页面，而不是从另一个项目复制来的泛型模板。

从资源图开始

如果站点只提供 HTML、本地样式表、一个 favicon、没有任何可执行 JavaScript，那么一条窄策略是可理解的：

Content-Security-Policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:

script-src 'none' 只有在站点不需要可执行脚本时才是正确的选择。加入搜索、评论或统计标签会改变资源图，并应触发一次有意识的策略复核。

增加传输与嵌套保护

对仅 HTTPS 的站点，下列响应头是常见起点：

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()

只有当每个子域名都准备好提供 HTTPS 时才启用带 includeSubDomains 的 HSTS。响应头是与未来部署的契约，而不只是扫描器里的一个分数。

检查行为，而不只是存在

请求一个正常页面、一个缺失页面与一个静态资源。错误响应应携带与成功响应同样重要的安全响应头。还要确认压缩与缓存不会改变内容类型，也不会暴露内部路径。

本站的Caddy 示例只是一个起点，不是普适策略。请根据你自己的部署调整主机名、证书处理与应用路由。

来源

MDN: Content Security Policy guide，CSP 指令名称与语法，已核验 2026-08-22。
MDN: Strict-Transport-Security，HSTS 指令与部署注意事项，已核验 2026-08-22。
Caddy header 指令，响应头操作指令，已核验 2026-08-22。

Web-Security · XB 现场笔记

CAA 记录应授权你实际使用的签发者

检视当前策略

匹配账户的签发者标识

在续期前编排 DNS 变更

观察签发失败

来源

Content-Type 应描述你实际发送的字节

检查有代表性的格式

保持 nosniff 一致

检查服务器映射

来源

Cookie 作用域应比应用边界更窄

偏好仅主机 Cookie

一起复核这些属性

在其约束契合时使用前缀

用相同作用域测试删除

让静态站点免 Cookie

来源

HSTS 应带着恢复计划来灰度发布

先验证 HTTPS 路径

从一个短的 max-age 开始

把 includeSubDomains 当作独立的决定

预加载不是普通的响应头配置

验证公共响应

来源

安全响应头应描述实际页面

从资源图开始

增加传输与嵌套保护

检查行为，而不只是存在

来源