如何用 cookie 的 SameSite 属性防范跨站请求伪造 CSRF 攻击-js教程-PHP中文网

samesite属性是防范csrf的补充手段，非替代方案；其strict、lax、none三值分别控制跨站cookie发送，推荐lax；须服务端设置，无法js控制；但不防xss，且同站点间仍共享cookie。

如何用 cookie 的 samesite 属性防范跨站请求伪造 csrf 攻击

Cookie 的 SameSite 属性是防范 CSRF 攻击的一道重要防线，但它不能单独替代传统 CSRF 防护机制（如 token 验证），而是作为纵深防御的补充手段。

SameSite 控制浏览器在何种跨站上下文中自动携带 Cookie。它通过限制 Cookie 在第三方站点发起的请求中是否被发送，来削弱攻击者利用用户已登录身份发起恶意请求的能力。

该属性有三个可选值：

Strict：完全禁止跨站请求携带 Cookie。例如从邮件链接、外部网站跳转到你的站点时，不会附带 Cookie。安全性最高，但易导致正常功能中断（如 OAuth 回调、支付跳转）。
Lax（推荐默认值）：允许安全的跨站 GET 请求（如点击链接、重定向）携带 Cookie，但阻止跨站 POST、PUT 等非安全方法的请求携带 Cookie。能兼顾安全与可用性，覆盖绝大多数 CSRF 场景（如表单提交、AJAX POST）。
None：允许跨站请求携带 Cookie，但必须配合 Secure 标志（即仅通过 HTTPS 传输）。不设防，仅用于明确需要跨域共享认证状态的场景（如嵌入式子域名 SSO）。

设置方式取决于你使用的后端框架或服务器配置，核心是确保响应头或 Set-Cookie 指令中包含 SameSite=Lax 或 SameSite=Strict。

常见示例：

Node.js（Express）：res.cookie('sessionid', 'abc123', { sameSite: 'lax', httpOnly: true, secure: true });
Python（Django）：在 settings.py 中设置 SESSION_COOKIE_SAMESITE = 'Lax' 和 CSRF_COOKIE_SAMESITE = 'Lax'
Nginx：使用 add_header Set-Cookie "sessionid=abc; Path=/; HttpOnly; Secure; SameSite=Lax";（注意：不推荐用 add_header 设置 Set-Cookie，应由应用层生成更可靠）

⚠️ 注意：不要依赖前端 JavaScript 设置（如 document.cookie），因为 JS 无法指定 SameSite；必须由服务端在 Set-Cookie 响应头中声明。

SameSite=Lax 虽能拦截大部分传统 CSRF，但仍有绕过可能：

它不防护同站内的 XSS 漏洞——一旦页面存在 XSS，攻击者可直接读取 Cookie（若未设 HttpOnly）或伪造请求，SameSite 失效。
对“同站”（same-site）和“同源”（same-origin）的判断基于站点（registrable domain + scheme + port），不是简单看域名是否相同。例如 admin.example.com 和 blog.example.com 属于同一站点，Cookie 默认会互相发送。
旧版浏览器（如 Chrome
某些复杂交互（如通过 POST 表单跳转、iframe 提交）可能被 Lax 模式放行，需结合 Referer 检查或 token 验证加固。

SameSite 是防御层之一，不可替代以下措施：

CSRF Token：在表单或 API 请求头中校验一次性 token，服务端比对 session 中存储的值。这是最成熟可靠的方案。
Referer / Origin 校验：检查请求头中的 Origin 或 Referer 是否来自可信域名（注意：Referer 可被客户端删除，不可单独依赖）。
敏感操作二次确认：如转账、密码修改等关键动作，要求重新输入密码或短信验证。
Cookie 安全标志：始终启用 HttpOnly（防 XSS 窃取）、Secure（仅 HTTPS 传输）、Path（限定路径范围）。

不复杂但容易忽略：把 SameSite 当成唯一防护，反而会带来虚假安全感。真正安全的系统，是让攻击者即使触发了跨站请求，也无法完成有效操作。