本文详解 CSRF防御的三层方案及常见误区：第一层使用 SameSite Cookie 结合 Secure/HttpOnly 属性阻止跨站携带，但防范同一主域下的恶意子域名攻击。第二层通过前后端双验证 CSRF Token， Neither 与 Session 绑定依赖 Token随机性，需配合强校验（Timing Safe Equal）。第三层基于可信 Origin 或 Referer 的白名单校验，要求精确匹配而非模糊判断。防御中需避免单独依赖某层，强调 Token 更新与密钥签名的结合，并指出需匹配 HTTP Methods(POST/PUT/PATCH/DELETE)进行校验。重点提醒 XSS 攻击可能绕过 CSRF 防护，因此必须同时实施输入过滤和 Content Security Policy。常见误区包括频繁更换 Token 增加复杂度、错误使用 Referer 字符串前缀、将 CORS 白名单等同于 Origin 校验。最终推荐采用 Cookie 属性限制+前后端 Token 校验+精确 Origin 或 Referer 匹配的三重防护方案。

浏览器通过协议、主机名、端口判断同源（如`https://api.example.com:443`与`https://api.example.com:443`同源），而SameSite基于协议和公共后缀判断站点归属（如`www.example.com`与`api.example.com`可能同站）。同源策略主要限制脚本跨域读取敏感数据（如DOM或localStorage），但不禁止跨源提交表单、加载图片或脚本，因此攻击者可通过CSRF绕过数据读取限制。Origin请求头需精确匹配（如`Set-Cookie`需严格匹配）且不包含路径参数，服务端验证时应使用集合进行交集比对。误区包括认为跨源即跨站（不同子域名或端口可能仍属同站），以及后端服务也受同源策略限制（仅浏览器层面生效）。总结：同源检查协议+主机+端口，SameSite依赖公共后缀；二者的核心边界在于前者限制数据读取安全，后者控制Cookie跨站发送。