小程序安全维护：别等出事才后悔

上周一个做电商的朋友半夜给我打电话，说他小程序被刷了几千单，全是0.01元的测试商品，库存被清空，客服电话被打爆。我问他接口有没有做频率限制，他愣了两秒说：“啥叫频率限制？”

这种事我见过太多次了。大家把精力都放在功能开发和UI上，上线之后就觉得万事大吉，安全维护这件事永远排在待办列表的最后一条。今天就把我这些年踩过的坑和实际做法整理一下，不聊虚的，都是能直接落地的。

先说最容易被忽略的：接口裸奔

小程序的前端代码是公开的，任何人下载包解压就能看到你所有请求地址和参数结构。所以“前端做了校验”这件事等于没做。我见过不少项目，删除订单、修改价格这种操作直接传个id过去，后端连归属校验都不做，改个数字就能操作别人的数据。

最基本的做法：每个涉及用户数据的接口，后端必须从登录态里拿openid，而不是信任前端传的用户标识。下面这种代码我 review 时见到就想打人：

// 错误示范：前端传什么就用什么
app.post('/api/order/delete', async (req, res) => {
  const { orderId, userId } = req.body
  await db.order.delete({ where: { id: orderId, userId } })
})

正确姿势是从服务端会话里取身份：

// 正确：身份来自服务端
app.post('/api/order/delete', async (req, res) => {
  const { orderId } = req.body
  const openid = req.session.openid
  if (!openid) return res.status(401).json({ error: 'unauthorized' })
  const result = await db.order.deleteMany({
    where: { id: orderId, openid }
  })
  if (result.count === 0) return res.status(404).json({ error: 'not found' })
  res.json({ ok: true })
})

频率限制和防刷，上线前必须加

前面说的那个朋友，问题就出在没有限流。短信验证码接口、下单接口、登录接口，这三个是重灾区。我的习惯是在网关层做统一限流，按 openid + IP 双维度计数，用 Redis 的 incr 加过期时间，几十行代码的事：

async function checkRate(key, limit, windowSec) {
  const n = await redis.incr(key)
  if (n === 1) await redis.expire(key, windowSec)
  return n <= limit
}

// 下单接口：同一用户 10 秒内最多 5 次
const ok = await checkRate(`order:${openid}`, 5, 10)
if (!ok) throw new Error('操作太频繁')

另外微信侧还有云开发的防刷能力，如果用的是云开发，记得在控制台把安全规则配好，别默认全开。

敏感数据别往包里塞

小程序包体是能被反编译的，AppSecret、数据库密码这类东西绝对不能出现在前端代码里。我见过有人把第三方地图的 key 直接写死在 js 里，结果被人盗刷配额。正确做法是前端只拿临时凭证，敏感调用全部走后端中转，或者用云函数代理。

还有 storage 里的数据，用户信息、token 都存在本地，退出登录时要清干净。别小看这个，共享设备或者换手机的场景下，残留数据是实打实的泄露风险。

依赖库和基础库的版本跟进

很多安全问题不是你自己写的代码，而是引用的第三方库爆了漏洞。我一般每个月花半小时做三件事：

• 看小程序基础库有没有安全相关的更新说明
• 跑一遍 npm audit，高危依赖及时升级
• 检查云开发控制台的告警日志，异常请求量突增要警觉

这个习惯坚持下来，能挡掉大部分低级风险。

日志和告警：出事时能救命的

安全维护不只是防，还包括出事后能不能快速定位。我的建议是后端关键接口都记操作日志，至少包含 openid、接口名、时间、结果状态。再配一个简单的告警：同一 openid 短时间内错误率超过阈值，或者单日请求量异常，就推送到自己的微信或者邮件。

别嫌麻烦，真出事的时候，能在一小时内定位到问题接口和受影响范围，和两眼一抹黑瞎猜，完全是两个体验。

说在最后

小程序安全维护这件事，投入产出比其实很高。上面这些措施加起来，一个中等规模的项目，前期多花两三天，后期每个月半小时巡检，就能把绝大多数常见风险挡住。真正难的不是技术，是把它当成开发流程的一部分，而不是等出了事再补。

如果你手上有个正在跑的小程序，不妨今天就打开后台看看接口日志，说不定能发现点惊喜。