每1000个网页里就有1个在裸奔。不是比喻，是斯坦福大学、UC Davis和代尔夫特理工的 researchers（研究人员）真去数了——1000万个页面，筛出1.7万条有效 API credentials（应用程序接口凭证），散落在近万个公开网址上。
这些不是测试用的假密钥，是连在云服务商、支付平台和生产环境里的真家伙。
Nurullah Demir，斯坦福的博士生，语气很克制：「我们发现的是高度敏感的 API 凭证被公开暴露在公共网页上。」他没说「令人震惊」，但数据替他完成了表达。
云时代的门钥匙，被复制了贴在玻璃上
API 凭证和普通密码的区别，在于它是机器之间的「自动通关文牒」。你登录网站要输密码，你的 App 调用云服务要掏凭证——后者不需要你每次点确认，代码自己就能划走数据、触发转账、删改配置。
研究团队把这东西比作「数字基础设施的后门钥匙」。问题是，这些钥匙现在被随手扔在 HTML 源码、JavaScript 文件和公开的 config 里，搜索引擎一抓一个准。
覆盖范围没有规律可循。小站、大机构、金融服务、基础设施服务商，全在名单里。不是某个程序员手滑，是系统性的控制失效。
10万样本里的1.7万，暴露率比想象中硬
具体数字：1000万页面，1.7万条有效凭证，涉及近1万个独立页面。换算下来，暴露密度约0.1%——听起来低，但考虑到这是自动化扫描的「被动发现」，实际存量只会更高。
凭证类型覆盖三大高危领域：
• 云平台（AWS、Azure、GCP 等）——直接控制服务器集群
• 支付服务——涉及资金流转接口
• 开发者工具——CI/CD 管道、代码仓库的访问令牌
研究团队用了「very little protection」这个表述。翻译过来：大部分连基本的混淆都没有，明文躺在那里，就像把家门钥匙刻在门牌号旁边。
为什么扫出来这么多？扫描器变便宜了
这不是人类逐行审计的结果。1000万页面的量级，靠的是自动化工具链——爬虫、静态分析、模式匹配、凭证有效性验证。过去五年，这类扫描的成本从「需要国家背景」降到了「一个 PhD 学生加几台云服务器」。攻击者和研究者的成本曲线，同时下探。
Demir 的观察指向一个结构性问题：「weak controls rather than isolated mistakes」。不是谁不小心，是流程没设防。代码提交前的扫描？缺失。凭证轮换机制？没有。生产环境的配置审计？靠运气。
更麻烦的是「历史负债」。很多暴露的凭证来自旧版本页面、废弃的测试环境、被遗忘的子域名——组织连自己有多少对外接口都数不清楚。
攻击者已经在用同样的工具
研究团队没有披露具体受害机构名称，但强调了一个事实：他们用的扫描方法，和恶意行为者用的「没有本质区别」。换句话说，这份预印本论文发布之前，这些凭证可能已经被扫过好几轮。
云服务商的应对策略是「责任共担模型」——平台提供工具（比如 AWS Secrets Manager、GitHub secret scanning），但用户得自己用。现实是，工具存在，启用率参差不齐。研究团队发现的大量明文凭证，很多本可以被这些工具拦截。
一个细节：部分暴露的凭证属于「长期有效令牌」，没有过期时间，没有使用次数限制。一旦泄露，风险窗口无限延长。
修复比发现更难
论文的隐含结论很直白：扫描是便宜的，治理是贵的。找到一个暴露的凭证，需要协调开发、运维、安全、法务多个团队，确认影响范围、轮换密钥、审计日志、通知下游。组织规模越大，这个链条越长。
研究团队正在与部分受影响机构沟通 remediation（补救措施）。但 1.7 万条凭证的背后，是更庞大的「影子 API」生态——那些没有文档、没有 owner、没有监控的接口，连暴露了自己都不知道。
Demir 最后补了一句：「我们希望这项研究能推动更广泛的行业行动。」
问题是，当扫描成本已经低到任何人都能操作时，「行业行动」的速度，赶得上密钥泄露的速度吗？
热门跟贴