表单验证绕过漏洞的本质是后端未校验，识别方法为：用开发者工具查required/pattern/type等html5属性、constraint api调用及校验事件；禁用js提交非法数据测后端是否放行；再用burp拦截篡改请求，观察响应是否接受脏数据。
表单验证绕过漏洞不是“有没有”，而是“服务器是否真校验了”——只要前端有验证逻辑，你就该默认它已被绕过，直接去测后端是否接住了所有脏数据。
怎么快速识别哪些字段被前端验证了
别猜，打开开发者工具（F12）看三处：
-
input或textarea元素上是否有required、pattern、minlength、type="email"等 HTML5 属性 - 页面源码或
Sources面板里是否存在checkValidity()、reportValidity()、setCustomValidity()等 Constraint Validation API 调用 - 监听了哪些事件：比如
onsubmit、onblur、input里是否调用了自定义校验函数（搜validate、check、form.check等关键词）
发现任意一项，就说明这个字段存在客户端约束——而约束本身，就是你下一步要绕过的靶子。
禁用 JS 后还能提交成功？那后端大概率没校验
这是最省力的初步判断方式。操作很简单：
- 浏览器设置里临时禁用 JavaScript（或用 NoScript 扩展）
- 填入明显非法数据：比如邮箱框输
admin' OR 1=1--，数字框输abc，必填项留空 - 直接点提交，观察是否跳转/返回成功响应
如果页面没报错、没拦住、还收到了 200 响应或跳转到成功页，基本可以断定：后端没做类型、非空、格式等基础校验。这时候再抓包改个 price=9999999 或 role=admin，成功率极高。
用 Burp Suite 拦截并篡改请求才是核心手段
禁用 JS 只能暴露“最裸”的漏洞，真正可靠的检测必须走代理拦截：
- 配置浏览器代理指向 Burp，正常提交一次表单，让 Burp 拦住
POST请求 - 在
Raw或Params标签页里，批量修改参数值：
– 把email改成<script>alert(1)</script>
– 把age改成-1或999999
– 把status（下拉选项）改成admin或deleted
– 若有文件上传，把filename="avatar.jpg"改成filename="shell.php"，同时改Content-Type: image/jpeg为text/plain或删掉 - 转发请求，重点看响应状态码、响应体是否含错误提示、是否写入数据库、是否触发 XSS/SQLi 行为
关键信号：200 OK + 响应里出现你刚提交的恶意字符串（比如页面回显了 <script></script>），或数据库里真存进了 admin' OR 1=1-- —— 这就是漏洞确认。
绕过时最容易忽略的两个细节
很多测试卡在“明明改了却没生效”，其实是栽在这两个地方：
- 表单带
CSRF token？改完参数后，token 很可能已失效。得先重放一次原始请求拿到新 token，再带着新 token 提交篡改后的数据 - 后端做了长度截断或自动 trim？比如你传
username=aaaaa%20%20（带空格），后端trim()后变aaaaa，看起来“绕过失败”。这时得换思路：试试username=aaaaa<script></script>（不加空格但拼接标签），或用超长字符串触发缓冲区异常
真正的风险从来不在前端怎么拦，而在于后端是否对每个字段都独立、严格、上下文适配地做了校验——哪怕只漏一个 id 参数，也可能导致 IDOR 或越权修改。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
