实际项目中，大家还做 csrf 的防御吗？

是什么理由让你不做？在以前你说的这两个难道就做不出来？

1.你理解错了，仿站能拿到 cookie 还要玩 csrf ？？？
2.模仿请求头很难么？
3.这么多网站都做 csrf 他们的程序员闲的没事干？？

Talk is cheap, show me your code: 你浏览器里模仿个请求头试试，不受同源策略限制的那种。。。

Auth Token 设置在 header 里的却是不需要做 CSRF 防御

做好幂等性保护，这个不只是针对 CSRF

https://owasp.org/www-community/attacks/csrf

并不需要确切的拿到 cookie，当你发送请求的时候 cookie 是会被自动带上的，无论源站是哪个。你可以试一下直接在这个帖子里打开开发者工具，console 里输入

$.ajax({method: 'get', xhrFields: {withCredentials: true}, crossDomain: true, url: 'https://www.baidu.com', success: console.log})

然后到 network 标签页下去看你发出到百度的请求带不带 cookie。假如你用的是 Chrome 80，它会提示你未来 Chrome 只会将标记为`SameSite=None` 和 `Secure`的 cookie 附加到跨站请求上。这一方面是避免你的 cookie 在 http 请求中被中间拦截泄漏，一方面通过给 Cookie 添加新的属性 SameSite 来在客户端限制 CSRF 攻击。考虑到未来相当长一段时间内，用户都不可能全部迁移到支持这个属性的浏览器（ Chrome 80 也还只是提示开发者）。你服务端在未来相当长的时间里也还是需要做 CSRF 防御的。

https://web.dev/samesite-cookies-explained/
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2

1 和 2 都有根本性的理解错误，楼主 HTTP 协议和 web 基础都不行啊

楼主补补基础啊 不过 cookie 倒是有个 samesite 的属性，chrome 最近几个月才开始支持

1. cookie 和 token 不就是防止 csrf 攻击的一部分吗？
2. csrf 不在乎你怎么发起请求，http 是超文本传输协议，其本质就是文本，伪造文本是很简单的。
现在 BS 主流框架都自带 csrf 防护了吧，基本不用自己操很多心了。另外所有的安全措施都是提高攻击门槛，而不是一劳永逸保护。这种基本不影响用户体验的防护措施是很可贵的。
顺便现在 SSRF 也越来越多了。

@340244120w Chrome 计划将 samesite 的 Lax 值变为默认设置，意味着 post 表单、ajax、iframe 这些都不会携带 cookie，相比于 strict 温和了很多

你对 csrf 的理解不太对，不过 samesite 普及了之后，csrf 可玩性就会低很多

你说的这两点，只要你能搞一个钓鱼网站让用户去点，这一切就都很简单。

但是，现在许多浏览器支持了 samesite 属性，导致 cookies 更安全了。