QA 与发布保障

API 安全

在您的 REST 和 GraphQL API 被利用之前找出其中的弱点。经您许可,我们测试认证、授权和数据暴露,报告经过验证的发现,并对您的修复进行重新测试。

我们测试谁的 API

你的应用只会按照其界面允许的方式调用 API,但任何人都可以直接向它发送经过修改的请求。你需要知道这样的请求能够读取、更改或耗尽哪些内容。

  • 许多租户共享同一个 API 和数据库的 SaaS 产品
  • 后端 API 任何人只要检查流量就能调用的移动应用团队
  • 在 AI 编码工具的帮助下快速扩张且从未进行过安全测试的 API 所属团队

每项 API 风险如何测试

这是一个带有多种用户角色的 REST API 的示例计划;你的组合遵循约定的范围。

自动化扫描手动测试修复后重新测试回归检查
身份验证和令牌有选择地使用该领域的核心技术该领域的核心技术有选择地使用
对象级授权在此几乎没有用处该领域的核心技术该领域的核心技术该领域的核心技术
输入处理和注入该领域的核心技术有选择地使用该领域的核心技术该领域的核心技术
速率限制和暴力破解有选择地使用该领域的核心技术有选择地使用在此几乎没有用处
响应中的多余数据有选择地使用该领域的核心技术该领域的核心技术有选择地使用
业务逻辑滥用在此几乎没有用处该领域的核心技术该领域的核心技术有选择地使用
  • 该领域的核心技术
  • 有选择地使用
  • 在此几乎没有用处

您的 API 是通往您数据的大门

大多数严重的 API 缺陷并不罕见。用户更改一个 ID 便读取了他人的记录,某个端点返回的字段比屏幕显示的更多,或者缺少速率限制招致暴力破解和抓取。无论您的 API 服务于您自己的应用、合作伙伴还是客户,我们都会在您书面授权的范围内,遵循 OWASP 指南对其进行测试。您将获得可复现的发现及修复指导,并且在您的修复到位后我们会重新测试。

AI 辅助覆盖,人工确认的发现

AI 如何协助

  • 从您的 API 规范、代码和流量中映射端点、参数和角色,以规划要测试的内容。
  • 构建授权测试矩阵,列出哪个角色可以对谁的数据调用什么,供测试人员逐项执行。
  • 根据每个端点的架构和业务规则,起草模糊测试输入和滥用用例。
  • 一旦确认某个问题,就在代码和日志中搜索其他位置是否存在相同缺陷。

我们的专家负责什么

  • 安全工程师与您商定范围和交战规则;测试始终在您授权的范围内进行。
  • 每个发现在报告前都会经过人工复现。原始扫描器输出不会作为发现传递。
  • 诸如跳过支付步骤之类的业务逻辑滥用,由先了解您工作流程的人员进行测试。
  • 严重程度按对您数据和用户的真实影响评级,修复建议契合您的框架。

您将获得什么

经授权的 API 测试,发现均经验证

  • API 攻击面地图

    记录端点、方法、角色、数据流和第三方连接,包括测试期间发现的未记录端点。

  • 授权测试

    跨角色和租户的对象级和功能级访问检查,以找出一个用户能够触及另一个用户数据或操作的地方。

  • 认证和令牌审查

    检查登录、密码重置、会话过期、多因素流程以及 JWT、OAuth 和 API 密钥的令牌处理是否存在弱点。

  • 输入、暴露和滥用检查

    注入、批量赋值、响应中的过量数据、速率限制,以及 GraphQL 查询深度、批处理和内省控制。

  • 附带修复方案的发现报告

    每个问题都映射到 OWASP API Security Top 10,附有复现步骤、影响、严重程度以及针对您框架的修复指导。

  • 重新测试和回归检查

    对修复进行重新测试以确认其有效,并将关键安全检查加入您的自动化测试,这样一旦相同缺陷再次出现便能被捕获。

API 安全评估如何进行

  1. 01

    范围与授权

    以书面形式商定端点、环境、测试账户和交战规则。未经您授权,不测试任何内容。

  2. 02

    映射与规划

    从规范、代码和流量中映射端点、角色和数据流,然后围绕风险最高的数据和操作规划测试。

  3. 03

    测试与确认

    将自动化扫描与对授权、认证、输入处理和滥用用例的人工测试相结合。确认每一个发现。

  4. 04

    报告、修复、重新测试

    交付可复现的发现及修复指导,如您需要可协助修复,然后重新测试并添加回归检查。

使用 AI 工具的两种方式

AI 协助起草测试并调查缺陷。选择它可以在何处处理您的代码和测试数据。

不确定?我们会在界定范围时为您推荐一个。 比较 AI 交付选项

典型的 API 安全需求

我们所界定范围的典型场景,而非客户案例研究。

  • 添加团队工作区后的租户检查

    某个 SaaS 产品添加了团队工作区,因此现在每个查询都需要进行租户检查。我们用分属不同租户、覆盖每种角色的账户进行测试,看一个租户能否读取或更改另一个租户的数据,并在修复上线后重新测试。

  • 面向外部开发者的 API 密钥

    某公司计划向外部开发者发放 API 密钥。我们检查密钥如何限定作用域、轮换和吊销,测试一个密钥能否触及其预定作用域之外的范围,并确认速率限制是否按每个密钥生效。

  • 一个信任应用的结账 API

    某商店的结账 API 按应用发送的内容接受总额和折扣码。我们测试经过修改的请求能否更改价格、重复使用折扣码或跳过付款步骤,并手动确认每一项发现。

API 测试不涵盖哪些内容

  • Web 前端、云设置以及跨系统串联的攻击由渗透测试涵盖;此处 API 才是目标。
  • 重新设计端点或重建 API 不包括在内;结构性修复可在 API 开发下进行范围界定。
  • 你调用但并不拥有的服务不在范围内,除非其所有者同意;我们转而测试你的 API 如何应对它们的错误。
  • 对 API 源代码的完整通读属于代码审计与评审;此处使用代码是为了定位和确认发现。

API 安全如何与设计、QA 和运维相衔接

  • 设计:安全、清晰的错误状态

    设计师和工程师商定错误和权限拒绝消息,既帮助用户,又不向攻击者透露内部细节。

  • QA:每次发布都包含安全性

    授权和输入检查加入回归套件,这样新端点和 AI 生成的更改都会以同样的方式被测试。

  • 运维:监控和密钥

    发现会反馈到 API 日志、可疑使用告警、密钥轮换和网关速率限制,与您的 DevOps 团队一起设置。

  • 持续:随着 API 的成长重新测试

    按与您商定的时间表审查和重新测试新端点和重大发布,使覆盖范围与 API 保持同步。

常见问题

常见问题解答

你们测试 GraphQL 吗,还是只测试 REST API?

测试。GraphQL 需要额外关注:内省暴露、查询深度和复杂度限制、批处理滥用以及字段级授权。我们在您授权的范围内对两者都进行测试。

API 安全评估会让我们合规吗?

单靠它不会;任何测试都做不到。我们支持您的合规工作:测试遵循 OWASP 指南,报告的撰写方式便于审计人员和您客户的安全团队审阅,而重新测试结果有助于您准备问题已修复的证据。

你们也能修复漏洞吗?

能。我们的工程师可以实施修复、与您的开发人员协作,或审查您的修复拉取请求。无论哪种方式,我们都会重新测试每项修复并添加回归检查,这样您就有证据证明它有效。

AI 工具会看到我们的 API 规范和发现吗?

仅在您选择的边界内,因为安全发现是敏感的。使用私有 / 本地 AI 工程时,模型运行在您控制的基础设施上,或运行在我们商定的隔离环境中。使用 Claude Code / OpenAI Codex 工程时,商业提供商按商定的账户和保留条款处理数据。我们尽可能使用测试账户和合成数据。

在别人之前先测试你的 API

告诉我们关于您 API 的情况、谁在使用它以及它处理的数据。我们将为一次经授权的测试提出范围和交战规则建议。