Salt Security扎心报告：93%的API过了安检

去年有家企业花了200万美元做安全审计，API全上了HTTPS、密钥验证、代码审查三件套。结果上线三个月，用户A用普通账号调出了用户B的银行流水——认证全对，授权没做。这不是段子，是Salt Security 2024年报告里的真实案例。

「安全检查」和「真的安全」之间，隔着一条马里亚纳海沟

Salt Security分析了数百万个生产环境API，发现一个反常识的数据：93%的API通过了基础安全检查，却在授权环节集体翻车。翻译成人话就是——门卫认对了你的脸，但从不查你能进哪个房间。

这种漏洞在 happy path（正常流程）里完全隐身。代码跑起来没问题，日志干干净净，直到某个用户偶然发现「诶，我怎么能看到别人的数据？」

更麻烦的是，现代API的授权逻辑比十年前复杂十倍。微服务架构下，一个请求可能穿过十几个服务，每个服务都要决定「这人能不能操作这个资源」。某个中间层漏了检查，前面全白费。

认证和授权：一对经常被混用的双胞胎

很多人把这两个词当同义词用，但技术上它们是完全不同的工序。

认证（Authentication）回答「你是谁」——验密钥、验Token、验指纹。授权（Authorization）回答「你能干什么」——这个用户能不能删这条记录、能不能看那个文件。

Salt Security的数据显示，78%的API漏洞属于「认证过关、授权裸奔」。攻击者不需要伪造身份，只需要用合法身份去碰不该碰的资源。就像你拿着自家门卡，刷开了整栋楼的房门。

OAuth 2.0、RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）……这些方案文档都很全，但什么时候用哪个、怎么组合，才是让人头秃的地方。

为什么授权比认证难做？

认证是标准化动作——行业有JWT、有OAuth、有成熟的库可以直接用。授权是业务动作——每个产品的资源关系都不一样，没有现成答案。

举个例子：一个文档协作工具，授权逻辑要判断「用户是否是文档所有者」「是否被分享过」「分享权限是只读还是可编辑」「所在团队有没有企业级权限覆盖」。这些规则散落在代码各处，某个角落漏掉一个条件，就是漏洞。

而且授权检查的位置也很微妙。放网关层，可能拿不到业务上下文；放服务层，每个服务都要重复实现；放数据库层，性能扛不住。没有银弹，只有权衡。

Salt Security建议的底线是：每个API端点必须显式声明需要什么权限，默认拒绝一切未声明的访问。听起来像常识，但能做到的团队不到15%。

那个花200万做审计的企业，最后发现问题出在一个被忽略的「内部服务间调用」接口——它信任了来自其他服务的请求，没做二次授权校验。攻击者只需要先控制一个低权限服务，就能横向移动。

你的API授权逻辑，最后一次全量审计是什么时候？