系统组合 SameSite、同步 Token、双重 Cookie、Origin 和 Referer 校验，构建敏感接口的多层 CSRF 防御。

浏览器通过Origin和Site两个标准判断请求归属：Origin由协议、主机和端口组成（如https://api.example.com:443），仅路径不同也算同源；Site则基于协议和可注册域名（如github.com），不同端口或子域名可能同站。同源策略限制脚本跨源读取数据、Cookie、localStorage等敏感资源，但允许跨源图片、表单提交等非敏感请求。SameSite策略通过判断站点边界控制Cookie跨域发送，需结合Public Suffix List识别可注册域名（如www.example.com与example.com同站）。常见误区包括：跨源不一定跨站（如不同端口下同站）、同源策略不阻止跨源请求到达服务器（主要限制脚本读取）、Node.js等后端环境不受同源策略限制。正常逻辑流程：同源需协议、主机、端口一致；同站需协议+可注册域名相同。浏览器核心执行文档中需强调SameSite与同源策略的区分，避免混淆CORS防护边界和同站逻辑设计。

浏览器基于域名、路径和Cookie标记决定是否自动携带 Cookie，Session管理核心仍需依赖服务端。安全配置需组合使用Secure（强制HTTPS）、HttpOnly（阻止JS窃取）和SameSite（默认Lax即同源携带，跨源不跟随），其中SameSite=S glBegin不能替代CSRF Token。推荐使用__Host前缀配置，需同时满足Secure+Path=/+无Domain设置，这种模式兼具跨子域名限制和同源容错优势。与localStorage相比，Cookie虽能通过HttpOnly防御XSS直接读取，却仍需配合其他机制防范CSRF和漏洞利用。常见陷阱包括误认为HttpOnly可禁用Cookie发送、SameSite=Lax可替代认证Token、Path即可实现权限隔离，正确配置需严格遵循安全原则与服务端权限验证结合。