在Web安全领域，跨站请求伪造(CSRF)一直是个难以根除的顽疾。开发者们不得不依赖各种防御策略，从CSRF token到SameSite Cookie，再到复杂的双重提交Cookie，每种方法都有其局限性和实现成本。即使实施了这些防御措施，攻击者依然可能找到绕过的方法，尤其是当攻击者能够控制页面内容时，传统的防御机制往往会失效。
随着浏览器安全模型的发展，一套由浏览器强制写入的请求头应运而生，为服务端提供了前所未有的可信信号基础。这套机制彻底改变了安全判断的底层逻辑，让我们能够构建出更可靠、更精确的安全防线。
Sec-Fetch-*系列的诞生背景
传统的跨站请求检测主要依赖Origin和Referer头，但这两种请求头存在明显的可信度缺陷。Origin头在某些场景下会缺失(如同源GET请求)，而Referer则可能被用户隐私设置或中间代理策略移除。更严重的是，这些头都可以被恶意脚本伪造，无法作为可靠的安全判断依据。
为了解决这一根本性问题，浏览器厂商引入了Sec-Fetch-*系列请求头。这套机制的革命性在于：这些头由浏览器在发送请求时强制添加，页面中的JavaScript代码无法修改或移除它们。这种"不可篡改性"使得服务端能够获得前所未有的可信来源信息，为构建更强大的安全防御体系提供了可能。
Sec-Fetch-Site：请求来源的核心标识
Sec-Fetch-Site是整个系列中最核心的请求头，它直接描述了请求发起方与目标资源之间的关系。这个头只能取四个值：same-origin、same-site、cross-site或none。每个值都有明确的语义：
- same-origin表示请求来自同一站点，即协议、域名和端口完全匹配
- same-site表示请求来自同一顶级域名，但子域名可能不同
- cross-site表示请求来自完全不同的站点
- none则表示浏览器无法确定关系，通常来自非浏览器请求或脚本发起的请求
一个典型的安全应用场景是：在处理敏感操作(如修改密码或删除数据)时，服务端可以要求Sec-Fetch-Site必须为same-origin或same-site，对于cross-site的请求直接拒绝响应。这种简单的检查就能有效阻止大多数浏览器发起的CSRF攻击，而不会影响正常用户操作。
Sec-Fetch-Mode和Sec-Fetch-Dest：请求上下文信息
除了Sec-Fetch-Site，Sec-Fetch-Mode和Sec-Fetch-Dest提供了额外的上下文信息，帮助服务端更全面地理解请求的性质。Sec-Fetch-Mode描述了请求的类型，常见的值包括：
- cors：跨域请求
- no-cors：不触发CORS的请求
- navigate：页面导航请求
- same-origin：同源请求
而Sec-Fetch-Dest则表明请求的目标资源类型，如document(完整文档)、script(脚本)、image(图片)或empty(无特定目标)。
这些信息的组合使用可以构建更精细的安全策略。例如，对于一个API接口，我们可以要求请求必须满足Sec-Fetch-Mode为cors且Sec-Fetch-Dest不为document，这样既能确保请求是通过浏览器正常发起的，又能排除可能是恶意页面加载的情况。
Sec-Fetch-User：用户交互的可信信号
Sec-Fetch-User是系列中相对简单但非常有价值的头，它只有一个可能的值"?1"，表示请求是由用户交互(如点击)触发的。没有这个值则意味着请求可能是脚本自动发起的。
这个头在区分用户直接操作和自动化请求时特别有用。例如，对于一个表单提交接口，可以要求必须包含Sec-Fetch-User头，这样就能有效阻止自动脚本提交的恶意请求，同时允许用户正常使用表单功能。
实施建议与最佳实践
将Sec-Fetch-*系列请求头整合到现有安全架构中，需要遵循一些最佳实践：
首先，不要单独依赖这些头进行安全判断，而应将其作为多层防御体系中的一环。例如，可以将Sec-Fetch-Site检查与CSRF token验证结合使用，对不同来源的请求实施不同级别的验证强度。
其次，考虑浏览器兼容性。虽然主流现代浏览器都支持这些头，但旧版浏览器和某些非浏览器环境可能不会发送它们。为这些情况准备降级方案，如使用传统CSRF防御机制。
最后，实施渐进式增强策略。先对非关键操作启用这些头作为补充验证，逐步扩展到敏感操作，同时密切监控误报率和漏报率。例如，可以先在管理后台接口上实施严格的Sec-Fetch-Site检查，收集数据后再推广到其他关键接口。
通过合理运用这些浏览器提供的可信信号，我们能够构建出更加精准、更加可靠的安全防御体系，有效抵御各种Web攻击，同时保持良好的用户体验。