html表单必须防csrf，因浏览器允许跨域自动带cookie提交，服务端仅校验cookie时，攻击者可用隐藏表单静默发起转账等操作；samesite=lax不能完全替代token，asp.net需前后端配对使用@html.antiforgerytoken()与[validateantiforgerytoken]。
HTML 表单提交必须防 CSRF，不是“可选”，而是“不加就等于裸奔”。浏览器天然允许跨域 <form></form> 提交并自动携带 Cookie，服务端若只校验 Cookie 有效性，攻击者用一个隐藏表单就能完成转账、删库、改邮箱——用户点都没点，钱就没了。
为什么 <form></form> 是 CSRF 的高危入口
表单提交绕过同源策略限制，是唯一能“盲发”带 Cookie 的跨域 POST 请求的方式。AJAX 被 CORS 拦着，<img> 只能 GET，唯独 <form></form>：不触发预检、不需服务端配 CORS、自动带 Cookie、JS 可静默提交。
- 攻击者只需在自己域名下放一段 HTML，诱导已登录目标站的用户访问，
onload一触发，请求就发出去了 - 服务端收到请求时，Cookie 合法、参数固定、HTTP 方法是 POST——和用户自己点提交一模一样
- SameSite=Lax 在 Chrome 80+ 后能挡掉大部分跨站表单 POST，但 Safari 旧版、安卓 WebView、某些 iframe 场景仍可能失效
Html.AntiForgeryToken() 在 ASP.NET MVC 中怎么配才不漏
这个辅助方法本身不危险，危险的是前后端没对齐：前端写了但后端没加特性，或 AJAX 没手动传 token，或 token 存储方式和验证逻辑不匹配。
- 前端必须在每个需要防护的表单内调用
@Html.AntiForgeryToken()，它会生成<input name="__RequestVerificationToken" value="..."> - 后端对应 Action 必须加
[ValidateAntiForgeryToken]，否则 token 完全不校验 - AJAX 请求不能靠表单自动带 token，得手动取值：
$('input[name=__RequestVerificationToken]').val()，再塞进headers: { 'RequestVerificationToken': token } - 若用 Web API 或前后端分离架构，
[ValidateAntiForgeryToken]默认不生效（它只认 form post + cookie），得换[AutoValidateAntiforgeryToken]或自定义过滤器
Spring Security 的 CookieCsrfTokenRepository 怎么设才安全
默认配置容易翻车：比如把 token 存进 HttpOnly Cookie 却又想用 JS 读取，或者没配 requireCsrfProtectionMatcher 导致部分接口漏保护。
- 用
CookieCsrfTokenRepository.withHttpOnlyFalse()才能让前端 JS 读到 token；设成true就没法用于 AJAX - 必须显式声明哪些路径要防护，例如
requireCsrfProtectionMatcher(request -> request.getMethod().equals("POST"))，否则 DELETE/PUT 可能被跳过 - 公开接口如
/api/public要用ignoringAntMatchers()显式排除，别指望“没写就默认不校验” - CSRF Token 默认 4 小时过期，如果用户页面长期不刷新，AJAX 请求会突然 403——得配合前端做 token 过期重拉逻辑
真正难防的不是技术实现，而是边界场景：子域名间调用、iframe 嵌套、PWA 离线缓存下的 token 陈旧、以及开发时本地环境关了 CSRF 却忘了上线打开。Token 机制本身很稳，崩掉的永远是“以为配好了”的那一环。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
