表单安全需前后端协同：校验action/method可信性、密码字段用type="password"+autocomplete、嵌入并验证CSRF Token、按钮防重提交+后端幂等控制。
表单提交前必须校验 action 和 method 是否可信
很多开发者以为前端校验只是“防呆”，其实它直接影响后端是否暴露在恶意请求下。如果 action 是拼接的 URL 或来自用户输入（比如从 URL 参数读取），攻击者可能把表单提交到任意地址；method 若被篡改成 GET，敏感参数会直接泄露在日志和浏览器历史中。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 硬编码
action，避免动态拼接；若必须动态，用白名单校验（例如只允许/api/login、/api/register） - 显式声明
method="POST"，不要依赖默认值 - 服务端必须校验 HTTP 方法，拒绝非预期 method 的请求（如对登录接口只接受
POST）
敏感字段必须用 type="password" 且禁用自动填充
type="password" 不仅隐藏字符，还触发浏览器对密码字段的特殊处理（如不缓存、不参与自动填充逻辑）。但仅靠这个不够——现代浏览器会主动尝试 autofill，可能把其他网站的密码填进你的邮箱或手机号字段，造成信息错位甚至泄露。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 密码字段始终用
<input type="password" name="password">，不要用text+ CSS 遮盖 - 添加
autocomplete="new-password"（注册/修改密码场景）或autocomplete="current-password"（登录场景），明确告知浏览器意图 - 对非密码字段（如邮箱、手机号），若不希望被 autofill 填充，可设
autocomplete="off"，但注意部分浏览器已忽略该值；更可靠的是用随机name（如name="email_123abc"）配合后端映射
CSRF Token 必须嵌入表单并由后端验证
没有 CSRF Token 的表单，等于给跨站请求大开绿灯。攻击者可以诱导用户点击恶意链接或加载伪造页面，利用用户已登录的 Cookie 自动提交表单（比如转账、删账号），而用户毫无感知。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 后端生成一次性 Token（如使用
crypto.randomBytes(32)），存入 session 并输出到表单隐藏域：<input type="hidden" name="csrf_token" value="a1b2c3..."> - 前端不得通过 JS 修改或读取该值（避免 XSS 泄露）
- 后端收到请求时，必须比对提交的
csrf_token与 session 中存储的值，失败则立即拒绝，返回403 Forbidden - Token 应绑定用户 session，且设置较短有效期（如 30 分钟），避免长期有效
提交按钮需防重复点击，但不能仅靠前端禁用
用户手快连点两次，可能导致重复下单、重复注册等业务问题。仅用 disabled 属性禁用按钮看似简单，但绕过太容易（比如禁用 JS 后重发请求、用 curl 模拟多次提交）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 前端加一层防护：点击后立即
button.disabled = true，并改变文字（如 “提交中…”），提升用户体验 - 后端必须做幂等控制：对关键操作（如支付、注册），用唯一业务 ID（如订单号、邮箱+时间戳哈希）做数据库唯一索引或 Redis setnx 校验，重复请求直接返回成功响应，而非报错
- 避免用时间戳或自增 ID 作为幂等键，它们不具备业务唯一性
真正难的不是加几个属性或写几行 JS，而是前后端对同一安全目标的理解是否一致——比如 Token 过期了前端要不要自动刷新，CSRF 失败是跳登录页还是弹提示，这些边界情况一旦没对齐，安全就断在中间了。
