OWASP 代理应用程序前 10 名：API 开发人员需要更改哪些内容

例子： Stripe 集成代理可以访问 GET /api/customers/:id 和 POST /api/refunds。 代理读取客户的付款历史记录，识别 最高价值的交易，并向自身退款。 每个单独的调用都会经过授权。 链条就是漏洞。

修复：每个代理的速率限制和链深度跟踪

标准速率限制对每个 IP 或每个 API 密钥的请求进行计数。 代理速率限制增加了两个维度：

• 每个工具的限制： 限制单个代理可以在窗口内调用特定端点的次数
• 链深度限制： 跟踪代理在单个会话中进行的连续 API 调用次数，并在定义的阈值处切断它

要求代理商发送 X-Agent-Session 标头。 跟踪每个会话的呼叫计数。 当 计数超出阈值，返回 429 并包含明确的错误消息。

3. 日志记录不足：无法查看代理 API 调用

48.9% 的组织对机器到机器的流量视而不见。 当代理利用您的 API 时，您 需要回答：哪个代理？ 哪些端点？ 按什么顺序？ 在什么时间窗口？ 标准访问日志 显示 IP 地址和时间戳。 它们不显示特工身份或呼叫序列。

OWASP 代理列表将日志记录不足标记为最高风险，因为代理攻击看起来像 授权流量。 每个单独的请求都会通过身份验证。 该漏洞利用的模式如下 多个请求。

修复：需要归因标头和日志调用链

为代理消费者添加三个必需的标头：

• X-Agent-ID：代理的唯一标识符（与其 API 密钥相关）
• X-Agent-Session：当前任务或对话的标识符
• User-Agent：代理框架和版本（例如， LangChain/0.3.1）

// Middleware: log every agent request with attribution
function agentAuditLog(req, res, next) {
  const logEntry = {
    timestamp: new Date().toISOString(),
    agentId: req.headers["x-agent-id"] || "unknown",
    apiKey: req.headers["x-api-key"]?.slice(-8) || "none",
    method: req.method,
    path: req.path,
    sessionId: req.headers["x-agent-session"] || "none",
    ip: req.ip,
    userAgent: req.headers["user-agent"]
  };

  // Structured JSON log for your SIEM
  console.log(JSON.stringify(logEntry));

  // Track chain depth per session
  const session = req.headers["x-agent-session"];
  if (session) {
    const depth = chainTracker.increment(session);
    if (depth > MAX_CHAIN_DEPTH) {
      return res.status(429).json({
        error: "Agent chain depth exceeded",
        maxDepth: MAX_CHAIN_DEPTH,
        currentDepth: depth
      });
    }
  }

  next();
}

该中间件将每个请求记录为结构化 JSON，并输入到任何 SIEM 或日志聚合器中。 它还通过跟踪每个会话的顺序调用来强制链深度。 当你调查一个事件时， 您可以通过过滤来重建完整的链 sessionId。

4. 不安全的输出处理：代理信任 API 响应而不进行验证

代理调用您的 API，接收 JSON 响应，并将其传递到其链中的下一步。 如果 响应包含意外字段、错误类型或注入内容，代理会传播问题 下游。 这是 OWASP API10（API 的不安全消费）的代理等效项，放大为 事实上，代理会自动处理响应，无需人工审核。

例子： 竞争对手破坏了第三方定价 API。 代理获取产品 价格，收到带有操纵的响应 price 字段设置为0.01，并下订单 以那个价格。 没有人看到过这个回应。

修复：根据 JSON 模式验证每个响应

首先从已知良好的响应生成模式。 这 /v1/schema/json-to-jsonschema 端点从任何示例 JSON 生成 JSON 模式：

curl -s -X POST https://api.botoi.com/v1/schema/json-to-jsonschema \\
  -H "Content-Type: application/json" \\
  -H "X-API-Key: YOUR_API_KEY" \\
  -d '{
    "json": {
      "orderId": "ord_12345",
      "status": "shipped",
      "total": 49.99,
      "items": [
        { "sku": "WIDGET-A", "quantity": 2 }
      ]
    }
  }'

回复：

{
  "success": true,
  "data": {
    "schema": {
      "type": "object",
      "properties": {
        "orderId": { "type": "string" },
        "status": { "type": "string" },
        "total": { "type": "number" },
        "items": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "sku": { "type": "string" },
              "quantity": { "type": "integer" }
            }
          }
        }
      }
    }
  }
}

然后根据该架构验证您的代理收到的每个响应。 这 /v1/schema/validate 端点根据任何 JSON 模式检查 JSON 对象并返回特定错误：

curl -s -X POST https://api.botoi.com/v1/schema/validate \\
  -H "Content-Type: application/json" \\
  -H "X-API-Key: YOUR_API_KEY" \\
  -d '{
    "schema": {
      "type": "object",
      "required": ["orderId", "status", "total"],
      "properties": {
        "orderId": { "type": "string" },
        "status": { "type": "string", "enum": ["pending", "shipped", "delivered"] },
        "total": { "type": "number", "minimum": 0 }
      },
      "additionalProperties": false
    },
    "data": {
      "orderId": "ord_12345",
      "status": "shipped",
      "total": 49.99,
      "internalNote": "rush order"
    }
  }'

回复：

{
  "success": true,
  "data": {
    "valid": false,
    "errors": [
      {
        "path": "",
        "message": "must NOT have additional properties: internalNote"
      }
    ]
  }
}

验证捕获 internalNote，一个不属于响应的字段。 如果一个API 开始返回意外字段，您的代理将停止处理而不是向下游传递受污染的数据。

以下是使用 Botoi Node.js SDK 的完整模式：

import Botoi from "botoi";

const botoi = new Botoi({ apiKey: process.env.BOTOI_API_KEY });

// Step 1: generate a schema from a known-good response
const schemaResult = await botoi.schema.jsonToJsonschema({
  json: knownGoodResponse
});
const responseSchema = schemaResult.data.schema;

// Step 2: validate every agent-received response against that schema
async function validateAgentResponse(response) {
  const validation = await botoi.schema.validate({
    schema: responseSchema,
    data: response
  });

  if (!validation.data.valid) {
    console.error("Response failed validation:", validation.data.errors);
    throw new Error("Untrusted response rejected by schema validation");
  }

  return response;
}

5. 供应链漏洞：工具定义受损

AI 代理通过 MCP 服务器、OpenAPI 规范和工具清单发现工具。 如果攻击者修改了 工具定义，代理调用不同的端点，将数据发送到不同的服务器，或执行 参数与开发人员预期不同。

例子： 您使用定义了 30 个工具的开源 MCP 服务器。 攻击者提交 更改一个工具的 API URL 的拉取请求 api.stripe.com 到 api.str1pe.com。 该更改通过了代码审查，因为它是单个字符。 您的代理人 现在将付款数据发送到攻击者的服务器。

修复：哈希工具定义并在运行时验证

在部署时对每个工具定义进行哈希处理。 在您的代理在运行时注册工具之前，再次对其进行哈希处理 并进行比较。 这 /v1/hash 端点生成任何字符串的 SHA-256 哈希值：

curl -s -X POST https://api.botoi.com/v1/hash \\
  -H "Content-Type: application/json" \\
  -H "X-API-Key: YOUR_API_KEY" \\
  -d '{
    "text": "{\\"name\\":\\"get_order_status\\",\\"description\\":\\"Retrieve current order status by order ID\\",\\"parameters\\":{\\"orderId\\":\\"string\\"}}",
    "algorithm": "sha256"
  }'

回复：

{
  "success": true,
  "data": {
    "hash": "a3f2b8c1d4e5f67890abcdef1234567890abcdef1234567890abcdef12345678",
    "algorithm": "sha256"
  }
}

以下是使用 Botoi SDK 的完整完整性检查工作流程：

import Botoi from "botoi";
import fs from "fs";

const botoi = new Botoi({ apiKey: process.env.BOTOI_API_KEY });

// Hash every tool definition at deploy time
const toolDefs = JSON.parse(fs.readFileSync("./mcp-tools.json", "utf-8"));
const hashes = {};

for (const tool of toolDefs) {
  const result = await botoi.hash.sha256({
    text: JSON.stringify(tool)
  });
  hashes[tool.name] = result.data.hash;
}

fs.writeFileSync("./tool-hashes.json", JSON.stringify(hashes, null, 2));

// At runtime, verify before registering any tool
async function verifyToolIntegrity(tool) {
  const result = await botoi.hash.sha256({
    text: JSON.stringify(tool)
  });
  const expected = hashes[tool.name];

  if (result.data.hash !== expected) {
    throw new Error(
      \`Tool "\${tool.name}" failed integrity check. \\n\` +
      \`Expected: \${expected}\\n\` +
      \`Got: \${result.data.hash}\`
    );
  }
}

在 CI 管道中运行哈希生成步骤。 将哈希文件与部署一起存储 神器。 在运行时，每个工具在注册之前都会经过验证。 任意一个字符发生改变 工具定义触发硬故障。

OWASP 代理前 10 名与 API 安全前 10 名：比较

这两个列表是相辅相成的。 以下是五种代理风险如何映射到最接近的 API 安全性 对应内容以及变化：

发布清单：代理 API 安全性的五个修复

每个修复都是独立的。 选择一个，发货，然后移至下一个。

接下来会发生什么

完整的 OWASP 代理应用程序前 10 名位于 owasp.org。 思科、微软和谷歌都在 RSAC 2026 上宣布了代理安全计划，所以期待 工具和标准将在今年剩余时间内快速发展。

列表中剩余的五个风险（提示注入、内存中毒、级联故障、数据 泄漏和沙盒不足）需要在代理框架层而不是 API 层进行修复。 如果 如果您运行代理框架，请阅读完整的 OWASP 文档。 如果您运行 API，则上述五个修复是 你的起点。

从范围内的 API 密钥开始。 这一单一的改变阻止了大多数过度的代理和工具滥用 场景。 然后添加归因标头，以便您可以看到代理正在做什么。 其余部分来自 能见度。