同源请求发送Origin头的作用及GET/HEAD例外原因解析

Great question! Let's break this down clearly—these details often trip up even experienced developers.

一、同源请求中Origin头的核心作用 #

虽然同源请求已经受**同源策略(Same-Origin Policy)**保护，但Origin头依然有不可替代的价值：

• 强化CSRF防护：同源并不代表绝对安全。比如恶意站点可以诱导用户点击链接、提交表单，发起同源POST请求（比如修改用户资料、提交订单）。服务器通过验证Origin头是否与自身域名完全匹配，就能直接拒绝伪造的同源请求，这是比Cookie验证更可靠的一道防线。
• 精准的源标识：有些"同源"场景其实更复杂——比如用document.domain实现的跨子域名同源，或者blob:、data:这类特殊源的请求。Origin头能准确标识请求的真实来源，帮助服务器区分不同的同源子站点或特殊源，实现更精细的权限控制。
• 日志与统计优化：服务器可以通过Origin头统计同源下不同子域名或入口的请求分布，方便排查问题、优化资源分配，比Referer头更精准（毕竟Referer可能被浏览器屏蔽或截断路径）。

二、为什么GET/HEAD方法被排除在外？ #

这个例外主要是历史兼容性+性能考量的结果：

• 历史遗留问题：Origin头是伴随CORS出现的较新规范，而GET/HEAD请求在Web发展早期就被广泛使用。大量旧服务器、CDN和第三方服务依赖于"GET/HEAD请求不带Origin"的行为，如果强制添加，会导致这些服务报错或拒绝请求，破坏Web生态的兼容性。
• 性能与带宽优化：GET/HEAD是Web中最频繁的请求类型（比如加载图片、脚本、样式），每个请求都额外携带Origin头会增加字节开销，累积下来对全球范围内的带宽和服务器性能有不可忽视的影响。
• Referer的替代作用：对于GET/HEAD请求，浏览器通常会携带Referer头（虽然可能被用户设置或浏览器策略截断路径），服务器可以通过Referer判断来源，Origin的必要性在这类请求中被大大降低。

内容的提问来源于stack exchange，提问作者Max