在前后端分离、移动应用和微服务逐渐普及的今天，大量业务能力由API提供。有些接口没有明显的网页入口，有些已不再被当前页面调用，却仍然可以访问。Burp Scanner能够从符合要求的API定义中识别端点和参数，帮助企业将更多页面之外的接口纳入安全测试范围。
1. 页面扫完了，接口可能还没有测完
传统Web安全测试通常从系统首页开始，通过跟随链接、提交表单和分析请求了解应用结构。这种方式能够覆盖常见业务路径，但企业应用早已不只运行在网页中。
同一套系统可能同时服务于PC端、移动端、小程序、内部管理平台和合作伙伴系统。不同入口调用的API并不完全相同，例如移动端独立接口、特定角色才能访问的管理接口，以及页面已经下线但后台仍在运行的旧接口，都可能无法通过普通网页爬取发现。
这些接口不一定存在漏洞，但如果没有进入测试范围，安全团队就无法确认其身份认证、权限控制和输入处理是否符合预期。对于应用安全负责人和研发管理者而言，真正需要关注的不只是扫描是否完成，而是哪些接口已经测试，哪些接口仍处在覆盖范围之外。
2. 利用API定义扩大测试范围
许多研发团队已经通过OpenAPI或Postman维护接口资料。这些资料通常用于接口设计、开发联调和功能测试，也可以成为安全测试的入口。
根据PortSwigger官方文档，Burp Suite Professional和Burp Suite DAST支持上传符合要求的API定义。Burp Scanner可以从中识别端点、参数及部分认证信息，并对发现的接口进行安全审计。
与等待爬虫在网页中"碰到"接口相比，从API定义出发，可以更直接地建立测试范围。只要接口被记录在符合要求的定义中，并且扫描器能够访问对应服务器，即使当前页面没有调用它，也有机会进入检查流程。
这项能力的价值不只是多扫描几个接口，还能减少安全人员反复收集地址、请求方法和参数的工作，让企业已有的接口资料继续服务于安全测试。
3. 不同API需要不同准备
Burp Scanner可处理符合要求的OpenAPI、Postman Collection、SOAP WSDL和GraphQL API，但不同形式有相应的使用条件。
例如，Postman Collection需要以支持的格式导出，服务器地址和相关变量也要提前配置。对于GraphQL，如果目标满足相关条件并启用Introspection，扫描器可以查询其结构，识别可用的查询和Mutation，再进行审计。
因此，企业在启动扫描前，需要检查接口定义是否完整、服务器地址是否可访问、认证信息是否有效。准备工作不到位，扫描任务即使正常结束，实际覆盖范围也可能低于预期。
4. 发现端点，不等于完成测试
将API定义导入Burp Suite只是开始。部分接口可能依赖特定账号、角色权限、业务数据或操作顺序。
例如，退款接口可能要求先创建订单并完成支付；管理接口可能只允许特定角色访问。缺少相应账号和测试数据时，扫描器虽然识别到了接口，却不一定能够进入完整业务流程。
安全团队除了查看扫描结果，还应确认关键接口是否真正产生测试请求、认证状态是否有效，以及未完成测试的原因。API覆盖质量不仅取决于工具能力，也取决于接口资料、测试环境和业务条件是否准备充分。
5. 自动扫描仍需结合人工判断
利用API定义可以帮助Burp Scanner扩大已知接口的测试范围，但自动扫描不能替代所有人工测试。接口文档可能过期，也可能遗漏内部接口和历史版本；多租户越权、复杂角色关系、交易状态绕过等问题，通常仍需要测试人员结合业务场景判断。
更合理的方式，是将API定义扫描、网页爬取、真实业务流量和人工验证结合起来。自动扫描负责扩大覆盖面，人工测试负责确认漏洞条件和实际影响。
对企业而言，这种方式还能改善研发、测试与安全团队之间的协作。各团队可以围绕同一份接口资料核对范围、补充测试数据并跟进问题，减少因信息分散造成的重复沟通。
结语
当越来越多的业务通过API提供时，安全测试也需要从可见页面延伸到接口本身。
Burp Scanner能够利用符合要求的API定义识别并测试接口端点，减少测试范围对网页入口的单一依赖。它真正解决的，不只是"能不能扫描API"，而是帮助企业更清楚地了解哪些接口已纳入检查，哪些风险仍可能隐藏在页面之外。
如需了解Burp Suite Professional、Burp Suite DAST的API扫描能力、授权方式及部署要求，可通过慧都进行产品咨询与测试评估。具体功能和适用范围，以PortSwigger官方资料及正式商务沟通为准。