客户端校验不是安全边界：服务端必须重新验证一切
Dev.to 技术文章（作者 khg5293，2026 年 9 月 7 日）讲一个基础但常被忽略的安全原则：客户端校验（Client Side Validation）只改善用户体验，永远不能当作安全控制。浏览器里跑的任何东西都可以被绕过，服务端必须把每个重要值再验证一遍。本文基于该文章，梳理要点与落地方式。
为什么客户端校验不是安全控制
浏览器可以限制邮箱格式、用户名长度、阻止某些字符输入——这提升的是用户体验，但：
- 用户可以修改 HTML
- 可以禁用 JavaScript
- 可以在开发者工具里改请求
- 可以直接用 curl、Postman、Burp Suite 之类的工具发请求
也就是说，任何"只在浏览器里做的检查"都可以被绕过。服务端必须假设收到的数据是不可信的，无论浏览器是否已经检查过。
服务端要覆盖的输入面
不可信输入包括：表单字段、URL 参数、JSON 请求体、HTTP 头、Cookie、文件上传、API 请求。
举例：浏览器表单把用户名限制为 20 字符，正常请求是 username=khg5293；但攻击者根本不用浏览器表单，可以直接把完全不同的内容发给服务端。所以服务端必须执行自己的规则：
const userId = Number(request.body.userId);
if (!Number.isInteger(userId) || userId <= 0) {
throw new Error("Invalid user ID");
}
关键点：这个校验发生在请求到达服务端之后。浏览器可能已经查过，但服务端永远不能假设那个检查真的发生过。
客户端校验仍然有价值
客户端校验不是没用：它提供即时反馈，改善用户体验——注册表单在提交前提示"用户名不能为空"，对用户很友好。但它保护不了服务端：绕过 JS 手动发请求就能跳过。两者各司其职：客户端管体验，服务端管安全。
校验 vs 净化
两个概念要分清：
- 校验（Validation）：判断数据是否可接受——是整数吗？长度在预期内吗？属于允许集合吗？格式对吗？
- 净化（Sanitization）：修改或移除内容，让值"更安全"——例如只允许一小撮项目类型时，把不符合的输入清洗掉。
实践中两者常搭配：先校验格式，再对需要输出到特定上下文（如 HTML、SQL）的内容做对应的转义或净化。
总结
原则一句话：永远不要信任客户端。前端校验是体验层的便利设施，安全边界必须画在服务端——表单字段、URL 参数、JSON 体、头、Cookie、上传、API 请求全部在服务端重新校验，并且把校验和净化分开设计。对 Web 开发者来说，这是写任何接受用户输入的接口前就该内化的基线。
来源：https://dev.to/khg5293/client-side-validation-is-not-a-security-boundary-4fhl