HTML表单本身不提供安全能力，所有防护必须依赖后端校验；前端type="email"、required等仅作体验优化，可被curl或开发者工具轻易绕过。
HTML 表单本身不提供任何安全能力，所有「表单安全」都取决于后端是否做了正确处理；前端能做的只是减少误操作、配合防护机制，而不是替代防护。
为什么 type="email" 和 required 挡不住攻击
这些是浏览器原生校验，仅用于提示用户格式错误，完全可被绕过：禁用 JavaScript、用 curl 直接发请求、或用开发者工具删掉 required 属性——数据照常提交。攻击者根本不会点你的提交按钮，而是构造原始 HTTP 请求。
-
type="email"只影响输入框 UI 和键盘类型（移动端），后端收到的仍是原始字符串，比如"admin@example.com<script>alert(1)</script>" -
pattern正则只在浏览器端运行，服务端若没做同样校验，恶意字符串会直接入库或回显 -
minlength/maxlength可被跳过，且对多字节字符（如中文、emoji）长度计算不一致，容易漏判
CSRF token 必须动态生成并绑定 session
没有 csrf_token 的表单，等于允许任意网站诱导用户静默提交。常见错误是把 token 硬编码进 HTML、存在 localStorage、或用时间戳代替随机值。
- 后端应在每次渲染表单时，调用安全随机函数（如 Node.js 的
crypto.randomBytes(32)）生成 token，并存入当前 session - 前端只负责将
<input type="hidden" name="csrf_token" value="...">嵌入表单，不得用 JS 读取、修改或缓存该值 - 提交后，后端必须比对请求中的
csrf_token与 session 中存储的值，失败立即返回403 Forbidden，不执行后续逻辑 - token 过期时间建议设为 15–30 分钟，且每次新页面加载都刷新，避免长期有效
文件上传必须重验 MIME 类型和文件头
accept=".pdf,.docx" 只是 UI 提示，浏览器不强制执行；攻击者可改扩展名、伪造 Content-Type 头，上传 PHP 脚本或 WebShell。
立即学习“前端免费学习笔记（深入）”；
- 前端可用
File.type和File.name做初步禁用（如禁用上传按钮），但纯属体验优化 - 后端必须读取文件前几百字节（magic bytes），调用
file -i（Linux）或mmmagic（Node）、python-magic（Python）等库判断真实类型 - 保存时必须重命名文件（去掉原始名），并使用
path.join()前先清理路径：拒绝含..、%2e%2e、\0的文件名 - 上传目录不能是 Web 可直接访问路径；若需下载，应通过后端代理脚本输出，而非直链
敏感字段 autocomplete 设置要分场景
autocomplete="off" 在现代浏览器中基本失效，尤其对 type="password" 字段；盲目使用反而干扰密码管理器，降低实际安全性。
- 登录页密码字段：用
autocomplete="current-password"，帮助浏览器识别并填充已保存的密码 - 注册/改密页密码字段：用
autocomplete="new-password"，避免填入旧密码 - 短信验证码字段：用
autocomplete="one-time-code"，触发系统级自动填充 - 非密码字段（如银行卡号）若需防 autofill，更可靠的是用随机
name（如name="card_8f3a"）+ 后端映射，而非依赖autocomplete
最容易被忽略的是部署层：Nginx 若未开启 underscores_in_headers on，自定义 header（如 X-Csrf-Token）会被直接丢弃；CDN 缓存了带 Set-Cookie 的响应，会导致 session 污染；HTTP 表单哪怕 action 是 HTTPS，也因页面本身不安全而可能被篡改。
