前端验证绕过会导致严重安全漏洞，如邮箱校验失效、支付金额篡改、越权访问、恶意文件上传等；根本原因是服务端未做二次校验，仅依赖不可信的前端控制。
前端验证绕过会导致什么后果
关键业务逻辑只靠 required、pattern、minlength 这类 HTML5 属性，或 JS 的 onsubmit 校验，服务端不做二次检查——这等于把门锁换成贴纸。攻击者禁用 JS、直接发 POST 请求、用 curl 或 Burp 修改字段，就能绕过所有前端限制。常见后果包括：用户注册时跳过邮箱格式校验、支付金额被篡改为 0.01 元、越权访问他人订单 ID、上传任意后缀文件（如 .php）。
怎么快速确认是否仅依赖前端验证
打开浏览器 DevTools → Network 面板 → 提交一次表单 → 找到对应请求 → 点开 Headers 和 Payload。重点看两点：
- 请求体中是否包含明显应被拦截的数据（比如空邮箱、超长用户名、非数字的 price 字段）
- 响应内容是否直接返回成功（如
{"success":true}），而没做任何字段合法性判断
再手动构造一个非法请求测试：curl -X POST http://yoursite.com/api/order -d 'amount=0.01&user_id=123'。如果服务端没拒绝，就坐实了漏洞。
哪些前端验证最容易被忽略或误信
以下几种看似“很严格”的写法，实际毫无防护力：
立即学习“前端免费学习笔记（深入）”；
-
<input type="email" required>：只校验 DOM 层面，后端收到字符串照样能存 -
if (value.length > 20) { alert('太长'); return false; }：JS 可被禁用或 patch 掉 -
onblur触发的正则校验：绕过焦点事件即可跳过 - reCAPTCHA V2 的前端 token 获取后不传给后端验证，或后端只检查
g-recaptcha-response是否存在，而不调用 Google API 校验
尤其注意那些“隐藏字段”：比如 <input type="hidden" name="role" value="user">，攻击者会直接改成 admin 并提交。
修复时后端必须做的三件事
前端可以删掉所有验证逻辑，只留提示；后端才是唯一可信防线。必须做到：
- 对每个字段做类型 + 格式 + 范围校验：比如
amount字段，先转成 number，再判断是否为正数、是否在合理区间（如 1–9999）、是否为整数（若业务要求） - 对业务规则做原子性检查：比如“只有 VIP 用户才能提交订单”，不能只查前端传来的
is_vip=true，而要查数据库中该user_id对应的真实状态 - 敏感操作强制二次确认或 Token 绑定：如修改密码需原密码或短信验证码；删除资源需携带一次性
csrf_token，且该 token 必须与当前 session 绑定、单次有效
最常被漏掉的是“数据来源不可信”这个前提——哪怕前端 JS 是你写的、HTML 是你渲染的，只要数据经过用户浏览器，它就可能被篡改。别信任何客户端传来的 flag、role、price、id。
