网络限制较大，可能存在相关鉴权等操作，通常校验力度较低，安全防护力度较低，攻击者如果发现并嗅探到了此类内部 API 接口，就会针对此类 API 接口进行定向攻击。在多起数据泄露事件中， 对内部 API 的攻击、是导致泄露的罪魁祸首。
渠道 API
通常在数据中心或私有云网络环境中部署和运行，向特定的外部合作伙伴、供应商提供对内部 API 的有限制的访问。 通常用于特定合作伙伴的定向数据拉取及管控，对数据拉取的敏感度低，但对数据外泄的敏感程度较高。
访问程度控制权位于内部和外部 API 之间，安全管控层级也是一样，主流手段是通过 API 网关管控，但缺少安全方面的考虑。很少对此类 API 进行相关越权方面的业务管控。如果上下游供应链上的合作伙伴被入侵进而调度相关的 API 进行数据滥用，在渠道 API 上通常会缺少滥用的监控监管机制，因此多起数据泄漏事件就因为没有对渠道 API 进行滥用管控造成的。
为什么要做 API 敏感数据发现
据《Salt Labs State of API Security Report, Q1 2022》报告，在受访者最关心的 API 安全问题中，僵尸 API 以43%占比高居第一；远超过以22%的占比位居第二的账户接管/滥用；还有83%的受访者对组织 API 资产清单是否完整没有信心。
为何企业对 API 资产有如此大的担忧？安全隐患往往藏于“未知”，未知的僵尸 API、未知的影子 API、未知的敏感数据暴露等，根源都在于企业对 API 资产全貌的未知。安全的管理与防护始于“已知”和“可见”，人们难以掌控那些被遗忘的、看不见摸不着的资产安全状况。然而正是这些被人遗忘、不可管控的 API，往往会有相关敏感数据在上面运行，如果没有办法及时的发现这些敏感的 API 接口则会导致相关 API 数据被拖取或意外暴露的情况，攻击者很有可能就会通过此类 API 接口对业务敏感数据进行定向发现及攻击，紧接着进行相关敏感数据拖取，更有甚者会进一步的扩大 API 攻击的利用权限，对服务器、数据库的权限进行进一步获取。从而导致页数受损。
即便是企业已经开始重视并着手治理僵尸 API 问题，也仍有一处容易被忽略的巨大风险——僵尸参数。不同于那些被彻底遗忘的僵尸 API，这些僵尸参数有可能还存在于当前仍在服务且持续维护的 API 接口中。常见的僵尸参数，例如在开发测试周期内设置的调试参数、系统属性参数，它们在接口正式上线后未对外暴露给用户，但仍能被暗处的攻击者恶意调用。攻击者基于僵尸参数，能够利用批量分配等漏洞获得越权的响应。一旦这些未知的 API 脆弱点被恶意利用，背后的核心业务数据、平台用户数据等海量敏感数据在黑客面前就变成了内部 API 调用，没有任何安全管制，再无秘密可言。
