前端校验不可靠，关键在后端是否对每个字段做独立严格校验；常见漏点包括邮箱格式、价格范围、富文本、隐藏字段及下拉值等；用burp修改字段测响应可快速识别缺失。
前端数据校验缺失不是“有没有写 JS”的问题，而是“写了但没用”或“根本没覆盖关键路径”的问题。这类漏洞的实质风险在于：浏览器端的任何验证都可被绕过，一旦后端未做等价校验，攻击者就能直接提交恶意、越界、畸形或业务非法的数据。
怎么快速识别哪些表单字段缺乏服务端校验
重点不是看前端有没有 required 或 pattern，而是确认后端是否对每个字段做了独立、严格的校验逻辑。常见漏点包括：
- 仅依赖前端
type="email"，但后端只做字符串非空判断，不校验邮箱格式 - 价格字段前端用
input type="number" min="0" max="999"，后端却直接接收并存入数据库，未做范围检查或类型转换 - 富文本编辑器提交的 HTML 内容，前端有简单过滤，后端直接
innerHTML渲染或存入模板，未做白名单净化 - 隐藏字段（如
<input type="hidden" name="role" value="user">）前端设值，后端未校验该值是否属于当前用户合法角色
实操建议：用 Burp Suite 拦截一次正常提交，手动修改任意字段为异常值（如负数、超长字符串、<script></script>），转发后观察响应——返回 200 + 成功提示，或仅前端报错而数据已入库，即确认存在校验缺失。
HTML5 原生属性（required/pattern/min/max）为什么不能当安全防线
这些属性只是浏览器 UI 层的便利功能，它们的校验逻辑完全运行在客户端，且极易被绕过：
- 禁用 JavaScript 后，所有依赖 JS 的自定义校验失效；
required和pattern在部分老浏览器中也不生效 - 用开发者工具直接删掉
required属性，或把type="email"改成type="text"，即可绕过所有 HTML5 校验 -
min/max对 number 类型有效，但对字符串类型无效；maxlength可被移除，pattern正则可被注释或篡改 - 它们不防重放、不防代理篡改、不防 curl 直接发包——只要请求结构合法，服务器照收
真正起作用的只有服务端收到请求后，对 req.body 或 req.query 的每一项做独立校验和清洗。
哪些字段最容易被忽略服务端校验
不是输入框最显眼的地方，反而是那些“看起来很安全”的字段：
-
select下拉菜单的value：前端只展示几个选项，但攻击者可构造任意value提交，后端必须白名单校验 -
radio/checkbox的name值：常被用于状态切换（如status=active），但后端若只信任该值，就可能被篡改为status=admin - 文件上传的
accept属性：仅限制浏览器选择界面，实际提交任意 MIME 类型文件均可成功，后端必须检查文件头、扩展名、内容特征 - URL 参数中的 ID（如
/order?id=123）：前端渲染时用它取数据，但后端必须校验该id是否归属当前用户，否则就是 IDOR 漏洞
这些字段往往没有明显提示，也容易被测试人员跳过，但恰恰是越权、提权、信息泄露的高发入口。
如何用最小成本建立校验覆盖自查清单
不需要重写整个系统，从一次提交请求出发，逐字段问三个问题：
- 这个字段的值，是否可能被用户控制？（包括 URL、body、header、cookie、上传文件）
- 这个字段的值，是否在服务端被解析、拼接、执行或渲染？（如 SQL 查询、模板渲染、命令调用、DOM 插入）
- 服务端是否对该字段做了独立校验？（类型、长度、范围、格式、白名单、上下文编码）
只要任一字段对这三个问题的回答是“是/是/否”，就立刻标记为高危项。复杂点在于：同一个字段在不同接口中可能承担不同语义（比如 id 在 GET 中是查询，在 POST 中是创建关联），必须按接口粒度逐个确认，不能想当然复用校验逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
