大家好😁。

上个月 Code Review，我拦下了一个新人的代码。

他写了一个转账功能，前端做了极其严密的校验：

• 金额必须是数字。话说回来，
• 金额必须大于 0。
• 余额不足时提交按钮是 disabled 的。
• 甚至还写了复杂的正则表达式，防止输入负号。

他自信满满地跟我说："老大。放心吧，我前端卡得死死的，使用者绝对传不了非法数据。"

"我笑了笑🤣"

"没看他的后端代码。直接打开终端，敲了一行命令。"

"5秒后他的数据库里多了一笔"-1000"的转账记录，余额瞬间暴涨！"

"他看着屏幕，目瞪口呆："这…，你是怎么做到的？我按钮明明置灰了啊，""

为什么前端验证毫无意义？🤔

黑客视角的观点是，你根本不知道请求从哪来⚠️

• "Web 应用不是只能通过浏览器访问吗？" —— NO，任何能发送 HTTP 请求的工具都是攻击武器！💥
  👉 Chrome DevTools Network 捕获合法请求
  👉 右键请求 → "Copy as cURL" 获取完整请求模板 👉 在终端粘贴并修改关键参数： bash curl 'https://your-api.com/transfer' \ -H 'Cookie: session_id=xxx' \ -H 'Content-Type: application/json' \ --data-raw '{"amount": -9999}' # 改负数！

✅ 黑客成功绕过所有前端限制！

主要问题的观点是，你相信错了对象😖

错误认知❌	真实情况✅

认为使用者只能通过我的漂亮界面操作... HTTP协议天生公开 任何工具都可以直接调用API接口

依赖前端JS进行关键校验... JS运行在客户端 可以被禁用、篡改、绕过

以为提交按钮被disable就安全... 网络层面可以构造任意请求 UI状态和服务器逻辑完全独立

后台防御必备技巧🛡️

防御手段① Schema严格校验✅

typescript // TypeScript + Zod示例 import { z } from "zod";

// 越详细越好！ const TransferSchema = z.object({ // 强制要求必须为正整数 amount这方面。z.number.int.positive,// 不允许空字符串或特殊字符 accountId: z.string.regex });

// 自动抛出错误消息 try { const validatedData = TransferSchema.parse;} catch { return res.status.json;}

防御手段② 数据源单一性原则

javascript // ❌危险写法 - 全盲信任客户端数据 function handleTransfer { const { amount,recipient } = req.body;if { user.balance -= amount;recipient.balance += amount;} }

// ✅正确做法 - 数据来自唯一可信源 async function handleTransfer { const { recipientId } = req.body;// 注意没有amount!其实，const = await Promise.all();

// 全部从数据库获取真实值！if { await db.transaction;} }

至于高级威胁③，重放攻击与方法

:即使API接口参数正确。( 领券程序崩溃、支付重复扣款等)

:如何利用curl批量领取优惠券: bash

for i in {1..100};do curl ...，done

利用Redis计数器:

SET requestcount:${ip} ${count} EX ${expiretime}

当计数超过阈值时返回429 Too Many Requests错误。

对于关键操作要求: . 前端生成UUID作为request_id . 服务器处理完成后存储该ID到Redis/DDB中

if redis.exists: return "Duplicate request!" else:
redis.set

至于终极建议，永远假设所有输入有毒!

:所有外部输入都要经过以下三道防线:  

. Schema格式校验 . 数据源单一性原则 . 频率控制与幂等检查