表单安全需前后端协同：校验action/method可信性、密码字段用type="password"+autocomplete、嵌入并验证CSRF Token、按钮防重提交+后端幂等控制。
表单提交前必须校验 action 和 method 是否可信
很多同行容易陷入一个误区，认为前端校验仅仅是“防君子不防小人”的体验优化。实则不然，这里一个疏忽，就可能把后端服务完全暴露在恶意请求的枪口之下。试想，如果表单的 action 地址是动态拼接而来，甚至依赖于用户输入，攻击者完全有可能将数据直接导流到自己的服务器。更隐蔽的风险在 method 上，一旦被篡改为 GET，那些本该藏在请求体里的敏感参数，就会像明信片一样，公然展示在浏览器历史、服务器日志和各种网络设备里。
具体该怎么落地呢？有这么几个关键点：
- 第一原则是硬编码行动地址。如果业务上确实需要动态设定，务必建立严格的白名单机制，比如只允许指向
/api/login、/api/register这几个预设的端点。 - 别偷懒依赖浏览器的默认行为，在标签里就明确写上
method="POST"。 - 服务端必须守好最后一道关，对每个接口的HTTP方法进行校验。比如登录接口，除了
POST，其他任何方法的请求都应直接拒绝。
敏感字段必须用 type="password" 且禁用自动填充
给密码框加上 type="password"，这几乎是入门操作。它的作用不止于显示为星号，更关键的是会触发浏览器的一套特殊保护机制，比如避免缓存明文。但时代在变，浏览器的“热心肠”有时也会帮倒忙。如今自动填充功能相当积极，很可能把你其他网站保存的密码，填进了当前页面的邮箱输入框里，造成信息错乱甚至无意间泄露。
要治标又治本，得组合出拳：
- 密码字段，老老实实用
，别为了自定义样式而用普通文本框加CSS遮盖，那样会绕开浏览器的安全处理。 - 巧用
autocomplete属性给浏览器明确的指令：注册或改密场景用"new-password"，登录场景用"current-password"。 - 对于邮箱、手机号这类不希望被自动填充的非密码字段，可以尝试设置
autocomplete="off"，不过要知道部分现代浏览器可能不理会这个。更彻底的方案是使用随机的name属性值，后端再做一次映射解析。
CSRF Token 必须嵌入表单并由后端验证
缺少CSRF防护的表单，等同于给跨站请求伪造大开方便之门。攻击者完全可以构造一个恶意页面或链接，利用用户已经在你的站点登录的状态，悄无声息地以用户名义提交表单——无论是转账还是修改账号信息，用户可能全程毫无察觉。
因此，嵌入并校验Token不是可选项，而是必选项。具体操作上要注意几个细节：
- 后端负责生成一个足够随机的一次性Token，存入用户会话，并输出到表单的一个隐藏域中。
- 这里有个关键纪律：前端Ja vaScript绝对不要去读取或修改这个Token值，以防被XSS攻击窃取。
- 后端在收到请求时，必须严格比对提交上来的Token和会话中存储的是否一致，任何不匹配都应立即以
403 Forbidden拒绝。 - 这个Token需要和用户会话绑定，并且设置一个合理的较短有效期，比如30分钟，避免一个Token用到底。
提交按钮需防重复点击，但不能仅靠前端禁用
用户网络卡顿时的连续点击，或是程序化攻击的快速重放，都可能导致“重复下单”、“重复注册”这类业务逻辑故障。只在前端用 disabled 属性把按钮变灰，这个防护太容易被绕过了——禁用浏览器JS、或者直接用工具模拟请求，防线瞬间就垮了。
所以，正确的思路是前后端分层防御：
- 前端要做好用户体验，点击后立即将按钮置为禁用状态，并给出“提交中…”这样的视觉反馈，这是最基本的一层。
- 真正的保险丝在后端幂等控制。对于支付、注册等关键操作，必须利用业务上的唯一标识去防重，比如用“订单号”或“邮箱+时间戳哈希”作为幂等键，在数据库层设置唯一索引，或通过Redis的setnx命令判断。这样，即便重复请求穿透到了后端，系统也只会处理一次，后续请求直接返回已有的成功结果。
- 切记，不要用简单的时间戳或数据库自增ID作为幂等依据，它们在业务上并不具备唯一性。
说到底，表单安全的难点，往往不在于加上某个属性或写几行校验代码。真正的挑战在于，前后端开发人员对同一个安全目标的认知是否对齐。比如，CSRF Token过期后，前端是静默刷新还是跳转登录？防重提交的幂等键，业务上如何定义其唯一性？这些边界情况如果没有共识，安全链条就会在最意想不到的地方断裂。功夫，往往在这些细节之外。
