统一身份认证的html登录页是信任链第一道闸口，须防篡改、禁autocomplete、设真实form action、嵌入一次性csrf token、返回模糊错误提示，确保凭证安全交付。
统一身份认证流程里的 HTML 页面，不是“做个登录框就行”，而是整个信任链的第一道闸口。它一旦被绕过或污染，后续所有 token、SSO、OAuth2 流程都可能失效。关键在于：表单本身必须防篡改、防注入、防劫持，且不能泄露任何服务端逻辑或敏感路径。
HTML 表单必须禁用 autocomplete 并显式声明 autocomplete="off"
浏览器自动填充会把历史账号密码塞进 <input type="password">，甚至在多租户环境里填错域——比如把 SSO 门户的密码填进子系统的登录框。这不是 UX 问题，是凭证泄漏风险。
- 对所有敏感字段（
username、password、otp）都加autocomplete="off"，哪怕现代浏览器部分忽略该属性，也要加； - 更稳妥的做法是给
name属性设为无意义值，比如name="u_7x2"、name="p_q9f"，避免浏览器按语义匹配历史记录； - 不要用
type="text"显示密码再切type="password"，这种切换可能触发 autocomplete 缓存残留。
form 标签必须包含 action 且指向明确后端端点
很多前端开发者习惯把 action 留空或写成 "#"，靠 JS 拦截提交——这直接废掉 CSRF Token 的基础防护机制。服务端无法验证请求是否来自合法表单，也无法绑定 session 上下文。
-
action必须是非空、绝对路径，例如/auth/login，不能是相对路径或 JS 字符串； - 如果走 AJAX 提交，
form仍需保留真实action，JS 应通过fetch()或XMLHttpRequest手动构造请求体，而非移除action； - 禁止在 HTML 中硬编码后端域名（如
https://sso.example.com/auth/login），应由构建时注入或从data-api-base属性读取，避免测试/生产环境混用。
CSRF Token 必须作为隐藏字段嵌入，且每次页面加载都刷新
Token 不放在 Cookie 里，也不藏在 JS 变量中——前者易受 SameSite 配置影响，后者易被 XSS 窃取。它必须是 HTML 渲染时一次性注入的 <input type="hidden" name="csrf_token" value="...">。
- Token 值应在服务端生成并绑定当前 session，有效期 ≤ 15 分钟；
- 页面加载时若检测到 Token 过期（如通过
data-expire属性），应立即重定向到新登录页，不弹窗、不续期； - 禁止在前端用 JS 重新生成或拼接 Token，哪怕只是 base64 或时间戳——这等于放弃校验。
错误提示不能暴露后端状态或字段含义
返回 “用户名不存在” 和 “密码错误” 是经典的信息泄露。攻击者可借此枚举有效账号，再集中爆破。统一身份认证页面的错误响应必须模糊且一致。
- 所有失败场景统一返回类似 “认证失败，请检查输入” 的文案，不区分账号、密码、OTP、MFA 环节；
- HTTP 状态码统一用
401 Unauthorized，不要因字段校验失败返回400 Bad Request； - 前端不解析后端返回的 error code（如
"INVALID_CREDENTIALS"）来切换提示语，服务端只返回泛化 message 字段。
真正难的不是加几个属性或埋个 token，而是让每个 HTML 片段都意识到自己处在认证信任链的最上游——它不处理业务，只负责把干净、不可篡改、无歧义的凭证交出去。任何“为了开发方便”绕开表单语义、依赖 JS 补位的做法，都在悄悄削弱整套统一身份体系的根基。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
