企业面向业务开发 API 时主要关注业务功能的实现，忽略了对 API 资产和承载数据的登记管理，随着时间推移，很难再看全看清有哪些内部和外部 API、有哪些是数据类 API、API 正在如何及其为何使用敏感数据、API 在与哪些三方服务发生关系且存在敏感数据交互，这也导致对 API 数据安全的管理逐渐无从下手。

企业经常由于业务迭代快而降低甚至忽略对 API 数据安全质量的要求。常见表象是 API 交互的敏感数据超过业务最小需求范围。其次，不同数据业务场景共用 API，如内部功能和对外共享业务。第三，业务人员在前端可见非必要的敏感信息。此时将导致 API 处于观测不清的状况，存在数据泄露隐患且难落实管控。

业务先行的 API 设计原则，API 自身的开放性和易用性，以及 API 在前端业务、跨服务协作、定时任务、数据共享、数据外发等不同数据业务中交叉使用，导致 API 的活动行为难以看清，对于有意或无意的 API 违规滥用无从获知，这也是为何 API 数据泄露的发现，往往是"依赖"于出现了对企业造成严重影响的数据安全事件。

企业 API 涉及的业务繁杂、承载 API 的服务架构存在差异、安全要求和安全保护措施存在场景化要求，导致企业难以统一落实安全措施。归其根因，首先从企业对保护模式的要求来看，在不同的业务和安全管控阶段、API 所处位置不同、涉敏状态不同、业务特性不同需采用代理管控和旁路监听不同模式。其次从企业对保护位置的要求来看，由于敏感数据使用和流转路径不同，可能需要在应用主机、API 服务运行时、Nginx 代理服务、API 网关服务等不同位置实施保护。此外，伴随应用架构、API 数据业务、数据安全管理要求的变化，要求对各 API 的保护模式和保护位置按需调整，由于采用多工具堆砌方式或硬编码方式，导致难以实现灵活切换和增减，久而久之则造成安全保护措施逐步失效、弃用。