凌晨三点，一个攻击者坐在屏幕前，拧开一罐功能饮料的拉环。他没有写一行恶意代码，没有发起钓鱼邮件，没有渗透供应链。他只是对着一个API接口，发起了数千万次几乎一模一样的请求，每一次，只把路径里的几位数字往上加一点。
而每一次回应里，都装着一个陌生人的社保号、出生日期、医疗计划详情。
这听起来像是某部网络犯罪小说的开篇，但它真实发生在2025年底到2026年初的Navia Benefit Solutions（美国头部员工福利管理服务商）身上。269万美国人的敏感健康数据——教师、州政府职员、学校行政人员——就这样被悄无声息地搬空。而这家公司，在攻击停止整整八天之后，才察觉到异常。
经系统性地复盘50多起重大API泄露事件：包括正式的事后调查报告、SEC披露文件、州检察长的通知记录、安全研究员的技术分析，以及与亲历应急响应的工程师们的对话。这些事件横跨医疗、金融科技、零售、SaaS、政府基础设施和消费应用，涉及的机构从县级政府到市值数十亿美元的上市公司，技术栈千差万别。
导致这些灾难的，从来不是新型武器，而是同样的五个错误，反复出现，且从未被真正纠正。
这不是一份漏洞清单。这是一份行业的病历。它指向一个所有人心知肚明、却很少有人愿意大声说出来的真相:大多数API泄露，根本不是因为攻击者技术高明，而是因为防守者一遍又一遍，重复着那些早就知道该如何避免的失误。
第一个错误：七年榜首的漏洞，依然在屠戮
Navia事件有一个精确的技术名字——破损的对象级授权(Broken Object Level Authorization，简称BOLA)。
自2019年起，它就稳坐OWASP API安全十大风险榜首，七年未曾让位。它曾导致社交平台Parler泄露70TB用户数据；它曾让美国邮政系统(USPS)的一个漏洞，在安全研究员报告之后整整一年多无人修补，直到知名记者Brian Krebs公开曝光才被迫修复。今天，它仍然占据全部API漏洞的40%以上。
七年，榜首，四成以上的泄露事件，这已经不能用”人有失手”来解释，这是一种系统性的、结构性的失灵。
让我用最直观的方式还原这个漏洞。假设你是一家医疗福利公司的API用户，你发起一次正常查询:
GET /api/v1/benefits/participant/883441 → 200 OK
{ ssn: “XXX-XX-4291”, dob: “1979-03-14”, plan: “FSA” }
系统验证了你的身份，你看到了自己的记录。一切正常。
现在，你把末尾的数字从883441改成883442:
GET /api/v1/benefits/participant/883442 → 200 OK
{ ssn: “XXX-XX-7738”, dob: “1984-11-02”, plan: “COBRA” }
你看到了另一个人的社保号和出生日期。
883443、883444、883445……每改一次，返回的都是另一个人最私密的健康数据。把这个动作循环269万次，就是Navia事件的全部攻击路径。没有黑魔法，只有一个被反复忽略的提问。
系统问了一个问题：”你是登录用户吗?”——你回答：”是。”
它从来没问第二个问题：”这条记录是你的吗?”——于是它把别人的隐私，毫无保留地交了出去。
这里有一个常常被混淆的概念区分：认证(Authentication)验证的是”谁在发出请求”，授权(Authorization)验证的是”这个身份有没有权限访问这个具体的对象”。两者性质截然不同，但行业始终习惯性地把它们当成一回事。认证通常可以借助框架或中间件，一次性集中配置，全局生效；而对象级授权，却必须在每一个接口、每一个数据返回点，由编写该接口的工程师亲手实现，而不同工程师对”谁能看什么”的理解，往往天差地别。
修复方法在技术上极其简单：在数据访问层加一句校验——”当前令牌的所有者，和这条记录的所有者是否一致?不一致，返回403禁止访问。”一行判断，几分钟就能写出来。
但真正的难点从来不在”会不会写”，而在”能不能在每一处都写”。你需要为系统里每一个返回对象的接口都补上这行校验，而且要在所有历史代码、所有第三方集成、所有AI辅助生成的接口上保持一致的标准。你需要的不是一行代码，而是一种组织纪律。而大多数公司，显然还不具备这种纪律。
第二个错误：信任在无声地堆积，直到变成入口
2026年初公开披露的700Credit事件，波及约560万人。攻击路径并不曲折：一个第三方集成合作伙伴被攻破，而700Credit恰好为这个合作方暴露了一个API接口。数据从合作伙伴的服务器一路流入攻击者手中，中间几乎没有设置任何隔离屏障。
第三方集成，如今已是超过四分之一API泄露事件的初始入口点。这一点其实并不令人意外，每一次集成，都在建立一份信任关系，而信任关系堆积的速度，永远比安全审查跟进的速度快得多。
想象一个企业两年内的日常产品迭代：为某个新功能接入一个合作伙伴API，功能上线后渐渐无人维护，但那条API连接依然悄悄活着。一位外部承包商为某个项目搭建了内部服务集成，项目交付后人就离场了，而留下的服务账号凭证从未被吊销。用户注册流程里用了一个第三方数据丰富服务，授权范围本是”只读访问客户记录”。六个月后，第三方更新了客户端库，运维工程师升级依赖时，没有人去复核新版本里悄悄扩大的权限范围。
没有哪一个环节是出于恶意，也没有哪一个决定明显属于疏忽。这只是一种自然的、缓慢的积累，复杂的集成生态在持续开发中不断生长，而安全可见性，却永远追不上它生长的脚步。
更值得警惕的，是机器身份的泛滥。据CyberArk的数据，如今机器身份(用于服务间通信的凭证、令牌、密钥)与人类身份的比例已经超过45:1。每一次新部署、每一个微服务、每一条CI/CD流水线，都会衍生出一堆静态密钥、长寿命令牌和硬编码凭证。它们不会出现在季度访问审查的清单里，不会在项目结束时被主动吊销，也不会在工程师离职换岗时被一并清理。一旦这些机器身份泄露，无论是通过源码外泄还是供应链攻击，它们造成的破坏半径往往远超人类身份的泄露，因为这些服务账号，可能仍然保留着某个早已废弃的项目所需要的、远超实际用途的过宽权限。
修复路径并不是技术难题：把机器身份的治理，提升到与人类身份同等严格的水平，创建时明确写下业务目的，定期审查是否仍然必要，自动化检测超出合理范围的凭证，配备无需依赖原始创建者就能执行的吊销流程。但现实是，大多数企业在这件事上，已经落后了三到五年，而一份接一份的泄露记录，正在忠实地反映这个差距。
第三个错误：秘密渗入每个角落——2865万个硬编码凭证，64%的”永续令牌”
2025年一年之内，公共GitHub仓库中新增了2865万个硬编码秘密——包括API密钥、数据库密码、云服务凭证。这是GitGuardian记录到的最大单年增幅，比前一年增长了34%。
这个数字本身，值得一个长长的停顿。
更令人不安的是，AI辅助生成的代码中，秘密泄露的比率大约是GitHub整体基线水平的两倍。AI服务凭证泄露同比增长81%，达到127.5万个。使用AI编程助手生成的代码提交中，秘密泄露率约为3.2%，正是基线的两倍。
背后的机制清晰得近乎残酷：AI编程工具极大地降低了构建API集成的门槛，这本是一件好事。但它同时催生出一类新的开发者：精通业务逻辑和产品迭代，却对安全惯例几乎没有经验。他们很可能直接从项目文档里复制一段API密钥，粘贴进.env文件，再随手和代码一起提交进了仓库。AI不会主动提醒他们：”这个东西应该放进密钥管理器，而不是代码库里。”
更可怕的是秘密的扩散方式。在某次大规模检测中，6943台机器上发现了294,842个秘密实例，对应33,185个唯一秘密。平均每个存活的秘密，会同时出现在同一台机器的八个不同位置——从.env文件到shell历史记录，从IDE配置到缓存令牌和构建产物。其中59%的泄露，发生在CI/CD运行器上，而不是个人笔记本电脑里。
这个CI/CD的数字是关键。开发者笔记本上的秘密泄露，是个体的暴露；而CI/CD运行器上的秘密，却可以被该环境中执行的每一个进程访问到，包括那些通过供应链攻击悄悄植入的恶意进程。某次知名供应链攻击事件正是如此：恶意包从开发者机器上系统性收割SSH密钥、云凭证和API令牌，而AI开发工具，恰恰已经在那些机器上集中了海量凭证。
还有一个全新的泄漏面正在打开：MCP配置文件。2025年，公共GitHub上与MCP相关的配置，暴露了24,008个唯一秘密——其中8.8%在检测当时依然有效。
最令人绝望的，是修复的缺口。2022年被证实有效的凭证，到2025年1月仍有近70%有效；2026年1月重新测试时，有效率依然超过64%。三年前已知的暴露。六成以上的凭证依然活着、依然能用。检测技术在飞速进步。但补救流程几乎没有动起来，很多组织部署了秘密扫描工具。却没有建立配套的处理流程：在规定时间内轮换凭证，在吊销前先识别清楚有哪些系统在依赖它，把发现的秘密当成紧急修复项，而不是一条可以慢慢处理的信息类告警。
这相当于装了一个再灵敏不过的烟雾探测器，然后坐在原地，看着大楼烧起来。
第四个错误：监看做的是”设路障”，不是”看行为”
2025年，攻击者被入侵后的全球中位数停留时间为14天——比2024年的11天还要长。从初始入侵到横向移动的时间间隔，却降到了29分钟，同比加速65%。在至少一个案例中，数据外泄在入侵发生后四分钟就已经开始。
14天的中位停留时间，最快四分钟的外泄速度，攻击者的节奏越来越快，而检测的节奏却在背道而驰地变慢。Navia事件持续24天未被内部检测触发，这甚至算不上最糟糕的案例，它只是略高于中位数而已。在更大范围的统计里，34%的事件初始入侵向量被标记为”未知”或”未确定”——这意味着，监看基础设施完全没能捕获到入侵发生的路径。
为什么BOLA这种利用方式，可以连续数周不被发现？因为它产生的信号，根本不是传统基础设施监看工具设计来捕捉的那一类。请求格式完全正确，认证全部通过，每一次都返回200状态码。请求速率可能确实偏高，但偏高的API请求速率，也是正常移动应用、批量数据处理、合作伙伴集成在高负载下的典型症状。唯一能区分”正常”与”异常”的特征——被查询的对象ID，究竟属于谁，需要业务逻辑上下文才能判断，而标准的监看工具，根本不具备这种判断能力。
你无法调查一份从未被收集的数据。更致命的说法：你无法检测一个从未被定义过的异常。
针对Web应用、API和软件供应链的应用层攻击，往往能在传统安全工具的雷达下从容飞行，因为这些工具在设计之初，压根没有考虑过运行时视角下的业务逻辑。真正有效的API行为监看，需要两个大多数组织还没有搭建起来的东西：第一，每个接口的行为基线——这个API的合法使用模式应该是什么样的?每次会话正常应该访问几个对象ID？每个认证身份的数据检索速率，是否符合它本应承担的业务目的？第二，围绕这些基线校准出来的异常定义——什么样的具体模式，才构成枚举或外泄，而不是一次正常的批量操作？
这些基线无法从流量数据中自动推断出来。它们需要熟悉API设计意图的人，亲手用自然语言写下”什么是合法使用”的具体定义。这件事一点都不性感，不能用来发布新功能，也无法通过任何合规检查表，但它恰恰是区分”入侵发生四小时内就被发现”，和”攻击者悄无声息离开八天后才被发现”的关键所在。
第五个错误：把安全当成一个”项目”——可项目有截止日期，安全没有
2024年，法国三家大型零售商——Boulanger、Cultura和Truffaut——通过它们共享的电商后端，遭遇了一次协同攻击。原因只是一个配置不当的安全规则。一家出问题，三家同时沦陷，数百万客户记录被盗。共享基础设施，让一个漏洞像多米诺骨牌一样接连倒下。
这正是把安全当成”项目”对待的典型后果：安全审查只在部署上线那一刻做一次，之后集成架构却一直在持续演化——共享后端被修改，新合作伙伴被接入，配置因为新功能需求而被更新，而最初那次审查，从来没有覆盖过这些后续的变化。
渗透测试拍下的，是系统在两周测试窗口期内的一张快照。这张快照在生成的那一刻是准确的，然后随着每一次代码部署、每一次配置变更、每一次新集成的接入，变得越来越不准确。如果把渗透测试结果当作一种”持续的保障”——以为安全已经”搞定了”，可以一直撑到下一个合规周期——就意味着你始终在用一份早已过时的评估，去判断一个真正在不断变化的攻击面。
攻击者不会按照项目周期工作。自动化扫描工具能在几分钟之内发现一个新部署的端点。而企业的安全审查周期，通常是以季度甚至年度计算的。”API部署”到”被攻击者发现”之间的时间差，以分钟计；”API部署”到”被安全团队复审”之间的时间差，以月计。
有调查显示，68%经历过API安全事件的组织，损失超过100万美元。而累积起这些损失的组织，绝大多数并不是那些彻底跳过了安全环节的公司——恰恰相反，他们曾经在正确的时间、用正确的工具、做过一次正确的安全评估，然后就再也没有跟进过。他们做了一次，就以为结束了。但安全暴露，从来不会”结束”。
连续安全的五个支点：让防守与攻击，跳同一支舞
上述五个模式，其实指向同一个结构性需求：安全实践必须贯穿API的完整生命周期，而不能停留在某几个离散的合规节点上打勾了事。下面这个框架，可以叫它”API安全生命周期”——把关键动作组织成一个模型，在这个模型里，安全是系统被持续维护出来的属性，而不是组织定期验证一下的状态:
设计阶段：在写出第一行代码之前，先定义清楚对象所有权模型——谁拥有这条记录?什么样的访问才是被允许的?这能从根本上杜绝BOLA，让安全成为一种设计约束，而不是事后才补上的测试。
威胁建模：审查每一个会返回对象的接口，逐一评估所有权实施情况；审计每一个集成的信任边界。在威胁真正进入代码之前识别它们，成本永远最低。
开发阶段：在数据访问层(而不是控制器层)强制实施所有权校验。从一开始就把秘密放进密钥管理器里调用，而不是硬编码进代码。开发纪律，必须从第一天就立起来。
测试阶段：为每一个接口编写对抗性BOLA测试套件——用不属于测试用户的对象ID发起请求，确认返回的是403而不是200。每一次代码push都在CI/CD里跑一遍，不是季度一次，是每一次提交都要跑。
监看阶段：为每个接口建立行为基线，由真正理解这个API业务目的的人来撰写。把异常定义，牢牢关联到所有权上下文，不只是盯着速率阈值，更要关注”这个身份，是不是正在访问不属于ta的对象”。
持续验证:自动化维护API清单，确保每一个活跃端点都被知晓、被记录、被审查过。每90天复审一次所有信任关系，按明确标准吊销那些不再必要的集成。自动执行凭证轮换，并把轮换的SLA记录下来，接受检验。
这个框架的设计，刻意对准了那五个反复出现的错误模式:每个阶段，关闭一个特定的失败点，而每一个失败点的修复成本，在对应阶段是最低的。在设计和开发阶段修复BOLA，成本几乎为零；等到269万条社保号被盗之后再去修复，代价是天文数字。在开发阶段靠密钥优先的纪律去防止泄露，成本可以忽略不计；等到CI/CD运行器被攻陷、凭证扩散到整个构建基础设施之后再去补救，代价几乎无限。
未来三年：AI生成API、智能体间API、机器身份的暴涨
这五个模式并非一成不变的静态描述。技术的演进，正在给每一个模式持续加码。
AI生成的API，正在飞速扩展BOLA的攻击面。AI编码工具能极其高效地搭建出接口逻辑，同时却以两倍于基线的速度泄露秘密。它们创建出来的端点，究竟有没有正确实施对象级授权，完全取决于生成时的提示词质量、代码审查的力度，以及后续对抗性测试的覆盖率。把安全要求嵌入AI编码工具的配置里——比如”每个接口脚手架必须包含所有权校验””密钥必须从密钥管理器获取”，已经从一个加分项，变成了一个不能再忽略的防御动作。不这样做的组织，其实正在亲手构建2027年的BOLA攻击面。
智能体之间的API调用，正在创建一种大多数现有安全实践从未设计要去评估的授权链条。当一个AI智能体发起工具调用，再调用另一个API，再触发另一个服务时，授权上下文需要经过多跳传播——每一跳，是否都正确执行了所有权模型？整条聚合链路，在每一跳单独合规的情况下，是否依然能产生一个合规的授权结果？这需要在编排边界进行一种现有工具还无法执行的分析——这是一个尚未被真正解决的问题，但它将带来的泄露类别，在结构上已经可以被预见。
机器身份的泛滥，只会继续加速。自2021年以来，秘密的数量增长速度，大约是活跃开发者人口增长速度的1.6倍。每一次AI智能体的部署，都会创造出具有特定权限范围的非人类身份。当每个组织内的机器身份数量再次翻倍时，当前由凭证管理不善所导致的那批泄露记录，只会以更大的规模重演一次。
实时风险评估——根据行为上下文、身份态势和请求风险信号，动态调整API访问权限，是整个行业接下来需要转向的方向。用连续授权取代静态的权限授予；让访问决策融入会话历史、异常信号和行为基线的偏离程度。这在架构上很有野心，但它的前提，是先打好行为监看的地基，而这恰恰是第四个错误模式里，当下大多数生产环境中缺失的那一块。
所有这些更高级的能力，前提都是先把那五个最基础的动作做扎实。建立在没有所有权校验的授权逻辑之上的零信任架构，是一种安全剧场；建立在没有行为基线的监看之上的高级异常检测，只是一台昂贵的噪声发生器。高级的工作，只有在基础的纪律真正存在的时候，才能创造出真正的价值。
模式本身，才是真正的问题
Navia事件不需要任何高明的黑客技巧。它只需要一个可枚举的资源标识符，和一次缺失的所有权校验。同样的技术，仅仅是参数数字的递增，曾在2021年攻破Parler，在那之前攻破USPS，后来又先后成功攻破Spoutible和Optus。技术从未发生变化，因为那个被反复利用的基础性失败，忘记检查”这条记录到底是不是你的”，从来没有在组织层面真正被纠正过。
整个行业其实存在一个叙事问题。每一起重大泄露，都被当作一个需要全新分析的、独一无二的事件来报道。技术细节确实各不相同，但它们底层的结构性失败，却是同样的五个模式，只是排列组合不同，造成的后果不同。把每一起事件都当成特例来看待，意味着这个领域永远没法建立起真正的模式识别能力，永远没法把力量组织起来去解决根本原因，而不是反复扑灭表面的火苗。
安全的成熟，始于一个组织不再孤立地分析每一起泄露，而是开始去识别那些反复制造泄露的结构性失败。这五个模式，并不是对下一场泄露会从哪里发生的预测，它们是对当下大多数生产环境中API真实状况的客观描述。这些状况，只要有攻击者决定动手，就会产生几乎可以预见的后果。
Navia事件影响了269万人。泄露在攻击停止八天后才被发现。通知在入侵开始八十六天之后才发出。而那个导致泄露的漏洞，对象级授权破损，作为行业头号被记录在案的API风险，已经整整七年了。
下一场泄露，可能此刻就已经开始运行了，在一个拥有出色基础设施监看、干净日志、安全团队曾在发布时认真审查过代码库的组织里。在一个所有人都以为安全”已经做好了”的系统里，只是没有人写下那条对抗性的授权测试。
写到这里，我想起一位资深安全工程师说过的一句话：”安全不是一种最终状态，而是一个持续的过程。它不是你买到的东西，而是你做到的事。”
这五个错误，最终告诉我们一件事：做到的事，比买到的东西重要一万倍。而做到这件事最短的路径，就是从今天起，不再把BOLA当作老生常谈，不再让第三方集成的信任关系在无声中悄悄累积，不再允许密钥在代码仓库里一住就是好几年，不再相信没有行为基线的监看能发现真正的异常，不再把安全当成一件可以”做完”的事情。
因为攻击者，从来不会”做完”。
所以，防守者，也不该停下来。
来源：https://www.51cto.com/article/849024.html