浏览器带着凭据，不等于用户同意操作

在适用的Cookie和浏览器规则下，跨站发起的某些请求也可能带上目标站点会话凭据。若服务只据此认定请求合法，就可能把另一个页面引发的操作记在当前用户名下，即使攻击者从未知道该用户的密码。

这种攻击所能利用的是应用暴露的操作及用户本来拥有的权限。它与把脚本注入目标页面的XSS不同，虽然两种缺陷可以相互影响；不能只因没有在目标站插入脚本，就排除由外部页面触发未授权操作的可能。

参考：[1] [2]

防护值必须与请求和会话正确关联

同步令牌方案让服务端产生与会话关联、难以预测的值，页面提交时通过字段或自定义头带回，并由服务端核对。只检查浏览器自动附带的Cookie，或仅在页面里画出一个没有验证的隐藏字段，都没有建立这项关联。

OAuth回调也有相应问题。当前安全规范讨论把随机state与用户代理会话绑定，或在满足服务器支持与事务绑定条件时使用PKCE。它们保护的是具体协议关联，不能因为参数名存在就断言已阻止伪造。

参考：[1] [3]

浏览器策略与服务端验证共同起作用

SameSite可以限制某些跨站Cookie发送，来源检查和请求元数据也可帮助服务判断交互背景。但同站与同源不是同一概念，相关子域、导航方式及业务兼容要求都会影响策略；不能把一个浏览器属性视为所有部署的完整请求授权。

令牌也不是越频繁变化越没有代价。逐请求值可能使返回旧页面后提交失败，逐会话值则有不同有效窗口；方案要在明确绑定与可用性间作选择。同时，已能在可信页面上下文执行的XSS可能绕过这些请求防护，仍需修复其独立成因。

参考：[1]