前端输入校验能保证安全吗？
简化版
前端输入校验不能保证安全，它主要提升用户体验，减少无效请求。真正的安全校验必须在服务端完成，因为前端代码和请求参数都可以被用户绕过或篡改。关键权限、金额、身份、资源归属必须由服务端校验。
详细版
前端校验适合：
- 必填项提示。
- 格式校验。
- 长度校验。
- 即时反馈。
- 减少无效请求。
但前端不可信：
- 用户可以禁用 JS。
- 可以直接调用接口。
- 可以修改请求参数。
- 可以篡改本地状态。
- 可以绕过页面限制。
因此服务端必须重复校验，并以服务端结果为准。
完整版教学
一、前端校验的价值
前端校验能让用户更快知道输入是否正确。例如邮箱格式错了，没必要等提交到服务端才提示。
它提升体验，也能降低服务器处理明显错误请求的压力。
但它不构成安全边界。
二、为什么前端不可信
前端代码运行在用户设备上。用户可以打开 DevTools 修改代码、改请求参数，也可以完全不通过页面，直接用脚本请求接口。
如果服务端相信前端传来的价格、角色、用户 ID，就会出现严重漏洞。
例如前端传 price=1，服务端如果直接按这个价格下单，就可能被薅羊毛。
三、哪些必须服务端校验
必须服务端校验的内容包括：
- 用户是否登录。
- 用户是否有权限。
- 资源是否属于当前用户。
- 订单金额是否正确。
- 优惠券是否可用。
- 库存是否充足。
- 操作是否幂等。
前端可以做展示和提示，最终裁决必须在服务端。
四、面试追问与工程落地
面试官可能问：“那前端校验还有必要吗？”
有必要。它能改善体验、减少错误提交、降低沟通成本。只是不能把它当安全措施。
工程中前后端应共享校验规则或生成规则，减少两边规则不一致，但服务端永远是最终可信来源。
五、语法、语义、权限要分层校验
输入合法不代表操作有权。服务端校验至少分三层：
| 层次 | 示例 | 失败处理 |
|---|---|---|
| 语法校验 | 年龄是 0–150 的整数 | 返回明确 4xx |
| 业务语义 | 优惠券未过期且适用于商品 | 按服务端当前状态裁决 |
| 授权校验 | 当前用户拥有订单 | 不泄露他人资源细节 |
| 完整性校验 | 金额由商品和优惠规则重算 | 忽略客户端派生值 |
假设商品真实单价 199 元、数量 2、合法优惠 20 元，服务端应计算 199 × 2 - 20 = 378，而不是相信请求中的 total=1。前端显示的 378 只用于体验，最终订单金额必须由可信数据重建。
信任边界判断法：凡是会影响钱、权限、资源归属和持久状态的值，都要假设客户端可任意修改。
六、白名单、规范化与竞态边界
优先使用允许列表：状态只能是 draft|published，而不是“过滤几个危险字符串后其余都接受”。字符串还要明确 Unicode 规范化、长度按字符还是字节、首尾空白如何处理；文件不能只信扩展名和浏览器 MIME。
不要把输入校验等同于输出编码。用户名通过长度校验后，放进 HTML、URL、SQL 或日志时仍需要对应上下文的安全处理；验证解决“值是否符合业务”，编码/参数化解决“值是否被解释为代码”。
校验与写入之间还存在竞态。例如库存校验时有 1 件，两个请求同时通过，若扣减不是原子操作就可能卖出 2 件。数据库约束、事务、乐观锁和幂等键必须在最终写入点兜底。
解析请求 → 结构校验 → 业务校验 → 授权 → 原子写入
↑ 数据状态可能变化七、常见误区与追问
- 误区：按钮置灰就能禁止非法操作。 用户可以修改 DOM 或直接调用接口，界面状态不是安全边界。
- 误区：前端和后端都用了同一 schema 就无需服务端授权。 共享 schema 只减少规则漂移，资源归属和权限仍由服务端判断。
- 误区：输入通过校验后可以安全拼进 HTML 或 SQL。 校验与上下文编码、参数化查询解决的是不同问题。
- 追问：为什么更推荐白名单？ 可接受集合通常有限且可审计，黑名单很难枚举所有编码和变体。
- 追问：价格为什么不能由前端提交最终值？ 前端数据可篡改，服务端应按商品、数量和优惠规则重新计算。
- 追问：重复校验会不会浪费性能？ 前端校验换体验，服务端校验守边界；两者目标不同，不能互相替代。
- 追问：校验通过后仍可能出错吗？ 会，状态可能在写入前变化，最终需事务、约束或原子更新保证。
八、加强记忆
- 前端职责：即时反馈、减少误操作和无效请求。
- 服务端职责：结构、语义、授权、完整性全部重新判断。
- 可信计算：金额、权限、库存和归属从服务端数据推导。
- 规则方法：优先白名单，明确规范化、长度和类型语义。
- 不要混淆：输入验证不替代输出编码、参数化和文件安全扫描。
- 最终一致性：写入点用事务、约束、锁和幂等抵抗竞态。