签名字段最稳妥是放在每个需防篡改的表单内部，作为，由服务端生成并写入HTML，不可由前端参与密钥运算或动态拼接。
跨表单提交时签名字段放哪最稳妥
签名必须作为普通 <input type="hidden"> 字段，放在每个需要防篡改的表单内部，不能靠 JS 动态拼接 URL 或用全局变量传。浏览器原生表单提交（包括 target="_blank" 或 formaction 切换）只序列化当前表单内的控件值，签名若不在表单 DOM 内，必然丢失。
常见错误是把签名算好后塞进 localStorage，再在目标页读取校验——这等于没防篡改，攻击者删掉签名字段、清空 storage、甚至直接构造 POST 请求绕过前端，都能成功。
- 签名字段名建议统一用
signature，避免和业务字段混淆 - 签名值必须是服务端生成并写入 HTML 的，前端不可参与密钥运算
- 如果表单有多个提交按钮（如“保存”“提交审核”），每个按钮对应不同
formaction，需确保签名覆盖所有可能提交路径的参数组合
签名原文怎么拼接才不会被绕过
不能只拼接用户可见字段值，必须包含所有影响后端逻辑的输入：隐藏字段、disabled 但有默认值的字段、readonly 字段、甚至 method 和 enctype 类型。更关键的是，要按 HTML 表单实际提交顺序拼接，而不是 DOM 顺序或 JS 对象遍历顺序。
例如，当表单含 <input name="a" value="1"><input name="b" value="2">，后端收到的键值对顺序固定为 a=1&b=2；但如果前端 JS 把 b 值提前赋值、再调 form.submit()，某些老浏览器可能改变顺序，导致签名验不过。
立即学习“前端免费学习笔记（深入）”；
- 推荐做法：服务端渲染时，用相同逻辑生成签名原文字符串（如
"a=1&b=2&csrf=xxx"），再用 HMAC-SHA256 算出签名，一并注入到<input name="signature" value="..."> - 禁止使用 JSON.stringify() 拼接——对象属性顺序不保证，且引号、转义会引入歧义
- 如果表单含文件上传（
enctype="multipart/form-data"），签名原文不能包含文件内容，只取文件名、类型、大小等可稳定获取的元信息，并在后端做一致性检查
后端验签失败时该返回什么 HTTP 状态码
必须返回 400 Bad Request，而不是 403 Forbidden 或跳转登录页。403 容易被误判为权限问题，掩盖了签名失效的真实原因；跳转则可能让攻击者反复试探签名算法。
更重要的是，验签失败时不能泄露任何中间信息：不能告诉用户“时间戳过期”“字段缺失”“签名格式错误”，这些都属于侧信道泄漏。只要签名无效，统一返回模糊提示，比如日志记 invalid_signature: form_id=abc, ts=171…，响应体只含 {"error": "request_invalid"}。
- 签名有效期建议控制在 300 秒内，用
timestamp字段参与签名，并在后端比对服务器时间（非客户端时间） - 避免用 UUID 或随机字符串做 nonce——它无法防止重放，必须配合时间窗口或单次使用校验（如存 Redis 并设 TTL）
- 如果表单支持多次提交（如“重新发送验证码”），每次提交必须生成新签名，旧签名立即失效
为什么不能只靠 HTTPS 就省掉签名
HTTPS 防的是传输过程被窃听或篡改，但解决不了“合法用户提交了被自己恶意修改过的表单”这个问题。比如用户用浏览器开发者工具改掉金额字段、删掉限购标识、把 status=1 改成 status=99，HTTPS 照样把篡改后的数据加密发过去。
签名本质是服务端对“这个请求确实来自我刚刚下发的那个表单”的断言，它绑定的是表单初始状态，不是通信链路。没有签名，你永远分不清是用户主动改了，还是中间人劫持了，还是 XSS 注入脚本偷偷提交了。
真正容易被忽略的点是：签名密钥必须轮换，且不能硬编码在前端 JS 里。哪怕用了 Web Crypto API 在前端算签名，只要密钥可提取，攻击者就能批量伪造。所以密钥必须由服务端保管，签名生成必须发生在服务端模板渲染阶段，或通过短期有效的 token 从后端 API 获取。
