Astro 7.3.6 / 7.3.7 连续两个版本都在收紧请求安全

Astro 在 7.3.6 和 7.3.7 两个版本里集中做了请求安全方面的加固，值得一看的是它处理问题的思路。

改了什么

• CSRF 加固。
• Node 适配器的 Host 头校验。
• 修复 security.checkOrigin 相关问题。

为什么要校验 Host 头 Host 头是客户端可以任意伪造的。如果应用拿 Host 头去拼绝对 URL——生成密码重置链接、拼接回调地址、写 canonical 标签——攻击者就可以构造一个带恶意 Host 的请求，让系统发出去一封指向攻击者域名的重置邮件。

这类漏洞叫 Host 头注入，属于「看起来不可能但实际很常见」的那类。加了校验之后，不在白名单里的 Host 会被拒绝。

CSRF 加固的实际影响 CSRF 防护收紧通常意味着：跨站发起的状态变更请求（POST/PUT/DELETE）会被更严格地拦截。

如果你有外部系统回调你的 Astro 站点（支付回调、Webhook、第三方集成），升级后要专门测一遍。这类回调本质上是跨站请求，很容易被新的 CSRF 策略挡住。

checkOrigin 修的是什么 security.checkOrigin 用来校验请求来源。修掉的问题通常表现为：该拦的没拦，或者不该拦的拦了。升级后两种方向都要测。

升级后必测的三件事

1. 所有外部回调和 Webhook 端点，确认没有被 CSRF 策略误伤。
2. 所有生成绝对 URL 的地方（邮件链接、canonical、sitemap），确认 Host 头校验通过后能正常生成。
3. 有反向代理或 CDN 的场景，确认转发的 Host 头是预期值。这是最常见的误伤点——代理把 Host 改了，校验就通不过。

反向代理场景要特别注意 如果你的部署结构是 CDN → Nginx → Astro，Host 头在每一跳都可能被改写。升级前先打印一下应用实际收到的 Host 值，确认它和你在配置里写的一致，别升完之后才发现全站 403。

值得借鉴的一点 Astro 把安全加固放在补丁版本里连续做，而不是攒到大版本。这种做法对使用者更友好——改动面小、影响可控、容易定位问题。相比一次性甩一个巨大的安全变更，这种节奏更值得提倡。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

连续两个版本都在收紧请求安全，说明前一版的边界设计有问题。用了表单或服务端动作的项目要重点测跨站提交，本地拿命令行模拟一遍比只在浏览器点要靠谱。

Host 头校验这点很多自建脚手架都没做。我们之前生成重置密码链接时直接取请求里的 Host，被安全同事用一条伪造头复现了钓鱼邮件。后来改成从配置读站点域名，顺手把页面里的规范链接标签也一起修了，成本很低。

Host 头校验这条必做。我们之前用 Host 拼密码重置链接，直到安全测试给了一个伪造 Host 的请求才意识到邮件里的域名可以被控制。改法是配白名单而不是校验格式，格式校验挡不住一个合法域名。CSRF 加固同理，别只靠 SameSite。