本文目录导读:

- 核心原则:将小程序前端视为“不可信客户端”
- 维度一:身份与权限校验(最重要的防线)
- 维度二:数据合法性校验(防注入与脏数据)
- 维度三:业务逻辑与数据归属校验(用户隔离)
- 维度四:防重放与频率控制
- 维度五:数据传输安全
- 实战检查步骤(如何动手做)
- 总结:接口安全的“三把锁”
小程序安全检查接口通常涉及多个层面,核心目的是防止数据泄露、业务逻辑篡改以及未授权访问,由于小程序代码包可被反编译(特别是Android端),前端完全不可信,因此安全重心在后端。
以下是针对小程序接口检查的实用清单和最佳实践:
核心原则:将小程序前端视为“不可信客户端”
永远不要在代码中硬编码后端地址外的敏感信息(如数据库密码),建议从以下4个维度检查接口:
身份与权限校验(最重要的防线)
必须检查每一个接口是否验证了用户身份和操作权限,不能依赖前端传参(如 userId: 1001)来区分用户。
- [必须] Token合法性校验与绑定
- 检查点:前端每次请求是否都携带了
wx.login()获取,并通过后端自定义逻辑生成的session_key/token? - 安全建议:后端必须验证token的有效性、是否过期,以及token绑定的用户ID是否与操作的数据ID一致。不要直接用微信官方的
session_key作为业务token,建议用jwt或uuid生成业务token。
- 检查点:前端每次请求是否都携带了
- [必须] 权限等级划分
- 检查点:普通用户是否能访问管理员接口(如“删除用户”、“修改商品价格”)?
- 安全建议:后端接口必须通过注解或中间件进行角色/权限控制。
数据合法性校验(防注入与脏数据)
由于前端可以被绕过,所有数据校验必须后端再做一遍。
- [必须] 参数校验与类型检查
- 检查点:是否对接口的
GET/POST参数进行了长度、类型、枚举值校验? - 风险:用户A通过修改请求参数,传入
userId=999999查看他人订单,后端需要校验“当前登录用户=请求中的用户ID”。
- 检查点:是否对接口的
- [必须] SQL注入与命令注入防护
- 检查点:所有数据库查询是否使用了参数化查询或ORM框架,而非字符串拼接?
- 风险:
name=xxx' OR '1'='1导致数据泄露。
- [必须] 敏感数据过滤
- 检查点:返回数据是否包含手机号、身份证号、支付密码等敏感字段?是否进行了脱敏(如
138****1234)?
- 检查点:返回数据是否包含手机号、身份证号、支付密码等敏感字段?是否进行了脱敏(如
业务逻辑与数据归属校验(用户隔离)
这是小程序接口最常出问题的点。
- [必须] 水平越权检查
- 检查点:用户A是否能通过修改订单ID、商品ID来查看或操作用户B的数据?
- 测试方法:登录A账号,抓包修改请求中的订单编号(如
/order/detail?orderId=123456),尝试查看用户B的订单信息。
- [必须] 垂直越权检查
- 检查点:普通用户能否使用“管理员”或“商家”的接口?
- 测试方法:小程序前端隐藏了后台按钮,但尝试直接访问后台API地址。
- [必须] 关键操作幂等性
- 检查点:重复点击“下单”、“提现”按钮,是否会生成多个订单或重复扣款?
- 安全建议:后端使用唯一流水号(如订单号)加数据库唯一索引防止重复插入。
防重放与频率控制
- [必须] 接口防刷与限流
- 检查点:是否存在未做任何限流的接口?如“发送验证码”、“用户注册”?
- 风险:短信轰炸、撞库。
- 安全建议:按用户ID或IP进行单位时间内的请求次数限制(如60秒内只能发1次短信)。
数据传输安全
- [必须] HTTPS强制
- 检查点:小程序后台配置的
request合法域名是否全部为https://? - 风险:http明文传输会在中间人攻击下泄露 token 和通信内容。
- 检查点:小程序后台配置的
- [建议] 关键数据签名
- 检查点:对于支付、修改余额等敏感接口,是否进行了参数签名(如HmacSHA256)?
- 作用:防止请求参数在传输过程中被篡改(如将
price=100改为price=1)。
实战检查步骤(如何动手做)
如果你需要检查一个小程序的接口安全,可以按以下流程操作:
- 抓包分析:使用抓包工具(如 Charles、Fiddler、Whistle,或手机连接代理 + Proxyman)拦截小程序的所有请求。
- 看什么:请求是否都有
Authorization头?Payload 里有没有直接传user_id?
- 看什么:请求是否都有
- 黑白盒测试:
- 修改参数:拦截下单请求,将
price改成01或-1,看是否能通过。 - 修改ID:将订单详情接口中的
orderId改为另一个已知的订单号,看能否看到别人的地址、手机号。 - 重复请求:复制下单请求(Repeater),快速重放多次,看是否会生成多个订单。
- 修改参数:拦截下单请求,将
- 代码审计(如有源码):
- 搜索关键词:搜索
@RequestMapping或路由配置,看哪些接口没有权限注解。 - 搜索拼接SQL:搜索
String sql = "SELECT * FROM user WHERE id = " +这种写法。 - 搜索敏感日志:搜索
log.info("用户信息: " + user.getPhone())是否记录了完整手机号。
- 搜索关键词:搜索
接口安全的“三把锁”
| 检查维度 | 核心问题 | 一句话规则 |
|---|---|---|
| 你是谁 | Token是否有效?是否过期? | 后端必须校验Token |
| 你只能看到自己的 | 用户A能不能看用户B的订单? | 后端必须关联Session用户ID与业务ID |
| 你只能做能做的事 | 小白用户能不能点管理员按钮? | 后端必须做角色/权限检验 |
特别提醒:小程序安全很大程度依赖后端,如果后端接口没有做好权限校验,前端代码写得再漂亮也没用,建议使用自动化工具(如Burp Suite)批量扫描弱口令、未授权访问、SQL注入等常见漏洞。