漏洞赏金计划中的 API 测试，小白也能学会的挖洞方法论

如今 API 驱动着 83% 的网络流量。然而大多数漏洞赏金猎人完全忽视了它们。

为什么？因为 API 看起来无形、复杂且令人望而生畏。没有可以测试的彩色登录表单。没有明显的搜索框可以注入攻击载荷。只有对初学者来说像乱码一样的神秘 JSON 响应和 HTTP 头。

但没人告诉你的是：API 才是赚钱的地方。

当数百名猎人为了同一个联系表单中的 XSS 漏洞而竞争时，API 就在那里——暴露在外、未经充分测试，充满了每个漏洞可支付 5,000 美元、15,000 美元，有时甚至 30,000 美元以上的严重漏洞。

没有理论。没有假设。只有 2026 年真正有效的技术。

什么是 API？（有史以来最简单的解释）

什么是 API？（有史以来最简单的解释）

忘记技术定义吧。让我用每个人都能理解的方式来解释 API：在餐厅点餐。

你坐在桌边，很饿。 你想要一个汉堡，但你不能直接走进厨房开始做饭。你需要有人把你的要求传达给厨房。

那个人就是服务员。

过程是这样的：

1. 1. 你告诉服务员：“我想要一个不加洋葱的芝士汉堡”

1. 1. 服务员记下来并把它带到厨房

1. 1. 厨房准备你的食物（你看不到这个过程）

1. 1. 服务员把食物送回你的餐桌

在这个类比中：

• • 你 = 移动应用或网站（前端）

• • 服务员 = API

• • 厨房 = 数据库/服务器（后端）

移动应用不能直接访问数据库（就像你不能走进厨房一样）。相反，它向 API 发出请求：

GET /api/users/1234/profile HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGc...

API 处理这个请求，从数据库获取数据，并发回一个响应：

{
  "user_id": 1234,
  "name": "John Doe",
  "email": "john@example.com",
  "account_balance": 5420.00
}

就是这样。这就是 API。

为什么 API 无处不在（以及为什么这很重要）

现在打开你手机上的任何应用。Instagram、Uber、Netflix、你的银行应用——所有功能都由 API 驱动。

当你浏览 Instagram 时：

• • 你的应用发送：GET /api/feed?user_id=123

• • Instagram 的 API 响应并返回要显示的帖子

当你订购 Uber 时：

• • 你的应用发送：POST /api/rides 并附上你的位置

• • Uber 的 API 找到附近的司机并返回他们的数据

当你查看银行余额时：

• • 你的应用发送：GET /api/accounts/456/balance

• • 银行的 API 返回你当前的余额

现代应用中的每个操作 = 一次 API 调用。

关键的部分在这里：大多数公司花费数月时间来完善他们应用的外观。漂亮的按钮、流畅的动画、完美的配色方案。

但驱动所有这些功能的 API 呢？通常是在截止日期压力下构建的、文档不足、安全测试极少的。

这就是你的机会。

为什么 API 持续存在漏洞（令人不舒服的真相）

为什么 API 持续存在漏洞（令人不舒服的真相）

以下是 API 仍然存在漏洞的原因：

错误 #1：”这是内部的，所以是安全的”

开发者认为：“这个 API 只被我们的移动应用使用，所以攻击者无法访问它。”

错了。

当我下载你的移动应用时，我就拥有了它。我可以：

• • 反编译 APK/IPA

• • 提取所有 API 端点

• • 用代理拦截每个请求

• • 修改任何参数

• • 重放请求数千次

当你的应用运行在我的手机上时，就没有所谓的”仅内部使用”这回事。

错误 #2：信任而不验证

看看这个常见的后端代码：

app.get('/api/users/:userId/orders', (req, res) => {
    const userId = req.params.userId;
    const orders = database.getOrders(userId);
    res.json(orders);
});
看到问题了吗？
API 假设请求中的 `userId` 属于已认证的用户。它不验证所有权。
所以我只需将：
GET /api/users/1234/orders
改为：
GET /api/users/1235/orders

然后砰——我看到了别人的订单。

错误 #3：过度共享数据

移动应用显示：

• • 你的名字

• • 头像

但 API 实际返回的是：

{
  "name": "John Doe",
  "profile_picture": "url",
  "email": "john@company.com",
  "phone": "+1-555-0199",
  "ssn": "123-45-6789",
  "internal_user_role": "premium",
  "credit_score": 720,
  "admin_notes": "用户被标记需要审查"
}

应用只使用 2 个字段。API 暴露了 8 个。

开发者这样做是认为”应用以后可能需要这些数据”。但攻击者拦截原始 API 响应后就能看到所有内容。