如何利用 SameSite=Strict/Lax/None 属性完美防御 CSRF（跨站请求伪造）攻击-js教程-PHP中文网

samesite不是csrf的完美防御，需与csrf token等组合使用；lax是推荐默认配置，strict限制过强，none需配secure且不防csrf；它不防xss、不限制请求发出、对同站不同源无效，旧浏览器也不支持。

如何利用 samesite=strict/lax/none 属性完美防御 csrf（跨站请求伪造）攻击

SameSite 属性不能“完美防御”CSRF 攻击——它是一项关键缓解措施，但不是银弹。真正安全的系统必须组合使用 SameSite 与传统防护机制（如 CSRF Token），才能覆盖各类绕过场景。

SameSite=Lax 是当前最实用、推荐默认启用的配置

它允许用户点击链接、地址栏输入、GET 表单提交等“顶级导航”行为携带 Cookie，保障登录态延续和正常跳转体验
同时阻止跨站 POST、PUT、DELETE 请求以及所有 fetch/XHR/AJAX 跨域调用自动发送 Cookie，恰好切断绝大多数 CSRF 攻击链（比如隐藏 form 提交转账）
浏览器兼容性好，Chrome、Firefox、Edge、Safari 均已全面支持，且从 Chrome 80 起将未声明 SameSite 的 Cookie 默认按 Lax 处理

SameSite=Strict 提供更强限制，但需谨慎评估业务影响

任何跨站来源（邮件链接、搜索引擎结果页、广告跳转）进入你的站点时，Cookie 都不会被带上 → 用户会看到“未登录”状态
对 OAuth 回调、支付平台跳回、第三方嵌入管理后台等场景会造成功能中断
仅建议用于极高安全要求、且用户几乎不通过外部链接访问的内部系统（如企业审计后台）

SameSite=None 不是防御手段，而是明确放弃跨站保护的例外配置

必须同时设置 Secure（仅 HTTPS）和 HttpOnly，否则现代浏览器（Chrome ≥80、Firefox ≥79、Safari ≥14）会直接拒绝该 Cookie
常见于需要跨子域名共享登录态的场景（如 app.example.com 与 api.example.com），或嵌入式小部件（如客服弹窗、支付 SDK）
此类 Cookie 仍可被 CSRF 利用，必须额外配合 CSRF Token 或 Origin/Referer 校验

服务端必须显式设置，前端无法干预

SameSite 只能由后端在 Set-Cookie 响应头中声明，JavaScript 的 document.cookie 无法设置该属性

Node.js（Express）示例：

res.cookie('session_id', 'abc', { sameSite: 'Lax', httpOnly: true, secure: true });

PHP 示例（setcookie）：

setcookie('session_id', 'value', [
  'expires' => time() + 3600,
  'path' => '/',
  'domain' => '.example.com',
  'secure' => true,
  'httponly' => true,
  'samesite' => 'Lax'
]);

Django 设置：在 settings.py 中添加

SESSION_COOKIE_SAMESITE = 'Lax'
CSRF_COOKIE_SAMESITE = 'Lax'

SameSite 的硬性局限，你必须知道

它不防 XSS：一旦页面存在 XSS 漏洞，攻击者可直接执行 JS 发起带凭证的请求（如 fetch('/api/transfer', { credentials: "include" })），SameSite 完全无效
它不限制请求发出：浏览器只是不发 Cookie，恶意请求本身仍能到达服务器；若后端仅依赖 Cookie 鉴权而无其他校验，攻击可能成功（尤其当接口接受 GET 敏感操作时）
它对“同站不同源”无防护：admin.example.com 和 blog.example.com 属于同一注册域名（same-site），Cookie 默认互通，SameSite=Lax/Strict 均不拦截
旧版浏览器（如 IE、部分 Android WebView）不支持 SameSite，需搭配其他防护兜底

真正有效的 CSRF 防御是分层组合