hidden字段仅解决自动携带非敏感参数问题,不提供安全保护;敏感数据须由服务端校验、查库或签名验证,绝不可依赖其隐藏。

用 type="hidden" 在表单中传递关键业务参数,本质是让浏览器“悄悄带上值、不显示给用户”,但**它完全不提供安全保护**——值可被任意查看、修改。真正要保障参数安全,得靠服务端校验和权限控制,而不是依赖 hidden 字段“藏起来”。
hidden 字段的核心用途
它只解决“自动携带、无需用户输入”的问题,比如:
- 记录当前页面来源(如
<input type="hidden" name="from_page" value="order_list">) - 传递已生成的临时标识(如订单预提交时的
temp_order_id) - 维持流程状态(如多步表单中的
step=2)
这些值本身不敏感,或即使被改也不影响核心业务逻辑——改了也无妨,或服务端会重新校验。
千万别用 hidden 传真正敏感或关键参数
例如:用户 ID、权限等级、商品价格、折扣比例、库存余量、支付金额……这些一旦写在 hidden 里,用户打开开发者工具就能看到并篡改,提交后服务端若直接信任,就会出大问题。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面,使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力: - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面; - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”; - 提及位于 `apps/console/src/featur
正确做法是:
- 用户 ID、角色等身份信息,从 session 或 token 中获取,不要依赖表单字段
- 价格、库存等业务数据,在服务端查数据库实时确认,不采信前端传来的任何数值
- 需要“防篡改”的参数,可用服务端签名(如 HMAC)+ hidden 字段组合,提交时验证签名是否匹配
使用 hidden 的实用建议
如果确实要用,注意以下细节:
- name 属性要有明确语义(如
next_action),避免用模糊名(如data) - value 尽量用服务端生成的不可预测值(如 UUID、加密令牌),而非简单数字或明文字符串
- 配合 CSRF token 使用(
<input type="hidden" name="csrf_token" value="xxx">),防止跨站请求伪造 - 多个 hidden 字段可集中放在表单顶部或底部,保持 HTML 结构清晰
一个典型但安全的用法示例
用户在订单确认页点击“支付”,表单提交前,后端已生成唯一支付单号并存入 session。页面渲染时写入:
服务端收到后,只把 payment_no 当作查询键,去数据库查该单的真实状态、金额、归属用户——所有关键判断都在服务端完成,不信任任何 hidden 值。

















