密保问题安全逻辑必须由服务端实现，前端仅负责语义化表单结构与基础交互；问题需动态生成、答案经HTTPS提交并哈希存储，禁用localStorage明文保存，修改前须二次验证。
HTML里没法单独实现密保问题的安全逻辑
浏览器端的 HTML 本身不处理验证、不加密存储、也不防重放——密保问题属于后端鉴权环节，前端只负责表单结构和基础交互。硬要在 HTML 里“模拟”安全设置，反而会误导用户以为输入是被保护的。
常见错误现象：type="password" 用在密保答案输入框上；把问题和答案全写死在 HTML 源码里；用 localStorage 存答案明文；提交时没走 HTTPS。
- 密保问题必须由服务端动态生成（比如从题库随机选3题），不能靠 HTML
select静态列出全部选项 - 用户答案必须经 HTTPS 提交，且服务端做哈希比对（不是明文比对）
- 前端可做基础校验（如答案长度、非空），但绝不能替代服务端校验
- 避免在 HTML 注释或
data-属性里泄露题干映射关系（例如data-question-id="q7"对应“你小学班主任名字”，等于白送信息）
怎么写一个合规的密保设置表单结构
核心是语义清晰、无障碍可用、不暴露逻辑，同时为后续 JS 和后端留好接口。
使用场景：用户首次设置或重置密保，在「账号安全」页中嵌入。
立即学习“前端免费学习笔记（深入）”；
示例结构（仅 HTML）：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
<form id="security-questions-form" action="/api/v1/user/security-questions" method="POST">
<fieldset>
<legend>请设置3个密保问题</legend>
<div class="question-group">
<label for="q1">问题 1</label>
<select id="q1" name="q1_id" required><option value="">请选择</option></select>
<input type="text" id="a1" name="a1" placeholder="请输入答案" autocomplete="off" required />
</div>
<div class="question-group">
<label for="q2">问题 2</label>
<select id="q2" name="q2_id" required><option value="">请选择</option></select>
<input type="text" id="a2" name="a2" placeholder="请输入答案" autocomplete="off" required />
</div>
<div class="question-group">
<label for="q3">问题 3</label>
<select id="q3" name="q3_id" required><option value="">请选择</option></select>
<input type="text" id="a3" name="a3" placeholder="请输入答案" autocomplete="off" required />
</div>
</fieldset>
<button type="submit">保存密保设置</button>
</form>
-
name值要和服务端约定一致（如q1_id+a1），避免用中文或空格 - 禁用
autocomplete防止浏览器填充历史答案（密保答案不该被记住） - 不用
type="password"——答案可能是生日、地名等非敏感格式，掩码反而影响输入准确率 - 每个
select必须由 JS 动态加载题干（服务端返回 JSON 列表），禁止写死在 HTML 中
为什么不能用 localStorage 存密保答案
因为 localStorage 是纯前端、无加密、同源即读取——只要页面能执行 JS，就能 localStorage.getItem('security_answer') 直接拿到明文。
性能/兼容性影响：无性能问题，但安全等级归零；所有现代浏览器都支持，正因如此才更危险。
- 哪怕加了简单 base64 或 xor，也算“明文等价”，工具几行代码就能还原
- 扩展程序、恶意脚本、甚至同一域名下的 XSS 漏洞，都能瞬间窃取
- 真正该存的是服务端下发的临时 token（如
setup_token），用于提交时校验本次操作合法性 - 如果非要前端缓存中间状态（比如用户填了一半关了页面），可用
sessionStorage，且关闭标签页即销毁
提交后服务端必须做的三件事
前端表单只是入口，真正的安全防线全在服务端响应逻辑里。
常见错误现象：200 OK 返回后前端就显示“设置成功”，但服务端其实没校验答案长度、没去重、没哈希存储。
- 拒绝空答案、纯空格答案、少于2字符的答案（
a1、a2、a3全部检查） - 三个答案不能完全相同（防止用户填三个“123”应付）
- 答案必须用带 salt 的哈希（如
bcrypt或scrypt）存储，绝不可明文或简单 md5 - 返回响应中不要暴露题干与 ID 的对应关系（例如别返回
{"q1_id": 7, "question": "你小学班主任名字"}）
最容易被忽略的一点：密保问题修改必须要求当前登录态二次验证（比如输密码或短信验证码），不能仅凭 session 就允许改。否则一旦账号被短期劫持，攻击者可直接覆盖密保，彻底锁死用户。
