攻击手法和原理
发送到同域名的请求，浏览器都会自动加上Cookie，利用这个特性来伪造请求，绕过登录态校验。
具体例子：https://springdoc.cn/spring-security/features/exploits/csrf.html#csrf
防范措施
csrf token令牌：Spring Security优先推荐的方式。在需要登录态校验的请求中（比如HEAD里）加上一个自定义token（在登录成功时由服务端生成给前端），服务端对这个token进行校验。
SameSite：也是Spring Security推荐的方式。限制只允许同一个域名下的页面的请求才携带Cookie，比如第一个tab页登录了a.com，第二个tab页面发起a.com的请求，如果第二个tab页面的域名不是a.com、那么是不携带Cookie的，也就不会绕过登录态校验了。
Http referer：服务端通过校验referer属性来判断请求是不是来自于同一个域名下的页面，如果不是则拒绝。
补充
如果接口设计比较规范，则为了用户体验在http的safe method可以不进行校验。
有些浏览器，比如新版的Edge、Chrome，会默认设置SameSite=Lax， 这样的话链接、GET这类请求会加Cookie，其他POST这些不加，保证了一定的安全性
参考：
https://springdoc.cn/spring-security/features/exploits/csrf.html#csrf Spring Security防范csrf的方法
https://springboot.io/t/topic/1253 SameSite讲解
https://stackoverflow.com/questions/1413930/is-checking-the-referrer-enough-to-protect-against-a-csrf-attack http referer是否可以作为防范csrf的手段
https://blog.csdn.net/neal1991/article/details/114609935 http referer由浏览器添加、js代码不能修改。Cookie的话如果加了HttpOnly也可以达到相同效果
你真的知道 Cookie 吗？ SameSite 、 Secure 、 HttpOnly - javascript-lNong - SegmentFault 思否
https://www.cnblogs.com/snowie/p/15044091.html 从CSRF攻击者视角出发,渗透过程中的CSRF漏洞利用
