#api-security

共收录 5 条相关安全情报。

← 返回所有主题
👥 作者: Mahima Agarwal, Keshav Ranjan

本文针对现代企业面临日益严重的API安全威胁问题,提出了一种基于零信任架构(Zero-Trust Architecture)的“安全优先”API流水线开发框架。研究背景指出,API已占Web流量主导地位,成为数据泄露的主要载体,99%的组织在过去一年遭遇过API安全事件,22%因此发生实际数据泄露。同时,漏洞披露数量激增(2023年28,818个CVE,2024年40,009个),漏洞利用时间缩短至数天(2023年平均约5天)。为此,作者提出五支柱方法:治理与规划、安全设计、持续测试、流水线控制、运行时保护,并遵循OWASP API Security Top 10 2023、NIST安全软件开发框架等标准。该方法将安全嵌入DevSecOps实践,通过案例研究展示了显著效果:安全事件减少30%,发布后漏洞减少40%。论文还讨论了实施挑战、不断演变的威胁态势,并给出了组织采用安全优先流水线与零信任的建议。本文适合API安全从业者、DevSecOps工程师和安全架构师阅读。

💡 推荐理由: 当前API攻击面急剧扩大,而传统安全方法往往滞后。本文提出的系统化框架将零信任原则贯穿API开发生命周期,为蓝队防御API威胁提供了可操作的参考架构,有助于缩短安全响应时间。

🎯 建议动作: 研究跟进,评估框架在自身环境中的适用性

排序因子: 来自 arXiv 其他板块 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.5)
推荐 10.5
Conf: 50%
👥 作者: Ryan Fahey

本文研究大型语言模型(LLM)推理API中提示缓存(prompt caching)实现的安全隔离问题。提示缓存通过复用请求的KV缓存来节省计算资源并加速响应,但许多实现存在时序攻击或元数据泄露风险。Gu等人(ICML 2025)已提出一种审核LLM中提示缓存的方法。本研究重点关注OpenRouter API网关架构,该网关充当多个LLM提供商的前端,使用共享组织凭据路由请求。作者利用缓存探测技术,验证了OpenRouter是否引入跨用户缓存共享漏洞,从而破坏提供商层面本应提供的每账户或每组织缓存隔离。实验结果表明,OpenRouter的缓存机制确实存在全局共享现象,导致一个用户的缓存内容可能被其他用户访问,进而泄露敏感提示信息。该发现揭示了API网关在实现缓存功能时可能忽视的隔离缺陷,对多租户LLM服务的安全设计具有重要警示意义。

💡 推荐理由: LLM API网关的缓存隔离漏洞可能导致跨用户提示数据泄露,影响企业级AI服务的安全可信赖性。

🎯 建议动作: 研究跟进

排序因子: 影响边界/网络设备 (+5) | 来自 arXiv 其他板块 (+2) | 命中热门研究主题 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.5)
👥 作者: Bandana Kaur

该论文对公开披露的漏洞赏金报告中的“对象级授权失效”(BOLA)漏洞进行了首次大规模实证分析。作者从HackerOne平台收集了200份标记为IDOR或不当访问控制的报告(2021-2026年),并应用三标准包含过滤器,最终得到107份已分类的报告。分类采用LLM辅助的模式补全程序,在人类裁决的约束标准下,针对一个六族BOLA分类法进行。在107份分类报告中,84份(78.5%)被确认为有效范围内的BOLA。其中,行为级对象BOLA(定义为对他人对象执行未经授权的状态更改操作)占确认案例的41.7%,与直接对象引用BOLA一同成为数据集中观察到的两个主要族。这表明在实践指南中历史性地未被充分代表的模式。约21.5%的分类报告在严格标准下属于范围外,表明在HackerOne等平台上的标签计数显著夸大了BOLA特定信号。论文报告了各家族、操作类型、授权方向、行业领域、标识符格式和利用机制的分布。关键次要发现包括11.9%的垂直(用户到管理员)权限故障率,以及跨主要平台系统性地利用GraphQL全局ID。这些发现对API安全测试协议、开发者教育和OWASP指南具有直接影响。

💡 推荐理由: BOLA是API安全中最关键的漏洞,但以往研究多为概念性。本工作基于真实漏洞赏金报告提供了实证分类和分布数据,有助于安全团队更精准地识别和防御BOLA,改进测试策略。

🎯 建议动作: 纳入内部研究参考,更新API安全测试用例以覆盖BOLA主要家族。

排序因子: 来自 arXiv 其他板块 (+2) | 命中热门研究主题 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.5)
👥 作者: Yifei Zhou, Xianjun Gu, Xinyu Dai, Ming Liu, Lansheng Han

本文提出了一种名为PEMark的API响应水印方案,旨在解决API数据泄露后的溯源问题。现有水印技术通常需要修改数据库或API响应数据,这会迫使业务系统代码变更,甚至因数据值改变而影响正常业务。作者创新性地利用JSON/XML键值对顺序中固有的排列冗余——这一被忽视的维度不携带语义信息,但提供了丰富的编码容量。方案包含两个核心组件:水印代理网关和基于位置编码的水印嵌入。首先,服务器响应被转发至水印代理网关,该设计无需对现有业务系统进行任何修改;然后,通过位置编码对键值对进行重新排序来嵌入水印,而不改变任何数据值。据作者所知,这是首个通过代理网关上的位置编码实现无损API响应水印的工作。实验结果显示,该框架在保持业务可用性的同时,确保返回的API数据可追溯。与当前主流方案相比,该方法对篡改和插入攻击具有鲁棒性(100%相似度),并能抵御一定程度的删除攻击。论文主要贡献包括:零业务代码修改、零数据值修改、高鲁棒性、以及首创性的位置编码水印方法。适合关注API安全、数据泄露防护、水印技术的研究人员和工程师阅读。

💡 推荐理由: 提出了一种无需修改业务代码和数据值的API水印方案,解决了现有方案影响业务运行的核心痛点,为API数据泄漏溯源提供了实用且低侵入性的解决思路。

🎯 建议动作: 研究跟进,评估将代理网关水印方案集成到内部API网关的可行性与性能影响。

排序因子: 影响边界/网络设备 (+5) | 来自 arXiv 其他板块 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.5)
MEDIUM
PAPER 2026-05-17

Exploiting the Shared Storage API.

推荐 9.6
Conf: 50%
👥 作者: Alexandra Nisenoff, Deian Stefan, Nicolas Christin

本文研究了 Google 提出的 Shared Storage API,该 API 是 Privacy Sandbox 的一部分,旨在替代第三方 cookie,同时减少隐私风险。Shared Storage API 允许第三方存储不被顶级网站分区的数据,但限制对这些数据的读取权限,以防止用户跨站重识别。然而,作者发现该 API 的设计和实现存在缺陷,使得攻击者能够绕过隐私保护目标,实现跨站用户重识别,并泄露比 Google 预期更多的数据。作者通过多种攻击方法证明了这些缺陷,包括利用 API 的写入和读取机制,结合其他 Web 技术(如导航和事件时序)来推断用户身份。尽管作者已向 Google 负责任地披露了这些攻击,但大多数攻击在 Chrome 中仍可执行。论文详细描述了攻击原理、实验验证,并讨论了潜在的缓解策略。该研究对关注 Web 隐私、广告技术和浏览器安全的研究人员和安全从业者有重要参考价值。

💡 推荐理由: Shared Storage API 是 Google 替代第三方 cookie 的核心隐私方案,已部署在 Chrome 并被主要广告商使用。本文揭示其存在严重隐私漏洞,可能导致用户跨站追踪和数据泄露,威胁 Web 隐私保护战略。

🎯 建议动作: 关注后续缓解更新,评估内部系统对 Shared Storage API 的依赖风险。

排序因子: 来自网络安全顶级会议 (+8) | Community 数据源 (+1) | LLM 评分加成 (+0.6)