2024 年 API 安全最佳实践

在APIsec大学，我们与许多公司交流，了解他们在API安全方面的成功经验、挑战和2024年的重点关注领域。尽管这份清单可以很长，但以下是我们在2023年反复听到的关键点。

团队很容易直接跳到“修复”API安全的操作上。但持久的API安全需要从基础构建。因此，从治理开始——召集所有团队（开发、安全、运营、合规、风险等）讨论你的API需求：API在我们组织中的角色是什么，我们如何确保API的一致性，API的管理在哪里……

你无法保护你不了解的东西。因此，确保你了解整个API生态系统。了解你拥有的API、它们访问的数据、数据的所有者、部署位置等。

许多安全团队抱怨API可见性差。我们建议首先让安全和开发团队进行对话（参考第三条）。我保证开发团队对现有的API以及未来的计划有很好的了解。考虑创建一个API市场，开发者可以在此发布他们的作品，使其可访问。

安全和开发团队往往过于孤立。安全性需要编织进API的DNA中——即应用逻辑和代码本身。这需要开发团队参与到安全工作中，并承担保持API免受逻辑缺陷、授权漏洞和其他漏洞的部分责任。安全性不能在API上线后再去加固。

太多的API缺乏文档，或者文档薄弱、过时。这必须是强制性的。这不仅对你的API用户重要——它也大大有助于安全工作。有了文档，你就能让安全团队清楚地了解你的API的功能、接受的输入和执行的功能。这有助于测试的创建，以确保这些API没有漏洞。

正如第三条所提到的，开发团队需要共同负责API安全——所以我们需要确保他们意识到API风险并接受安全最佳实践培训。我们推荐API开发者和产品所有者参加API安全基础课程。课程只需90分钟，涵盖OWASP API前10名，回顾真实世界的安全漏洞，并提供API安全的最佳实践

我们经常听到“影子”和“流氓”API的问题。这些是你不知道的API，不知怎的被创建并发布了。我们认为没有经过标准化、定义良好的过程的API不应该被部署（参考第一条）。如果你有流氓/影子API，那就是治理问题。改善的最佳方式之一是要求所有API都在集中的API网关中部署和管理。

这很简单——不要信任进入你API的任何东西。也就是说，进行强有力的输入验证。如果你的API有一个LinkedIn个人资料URL的输入，但有人插入了/etc/passwd、恶意链接，或真的任何看起来不像LinkedIn URL的东西——就把它丢掉。确保在进行任何操作之前检查每个输入。

UI是控制用户可以看到哪些数据、可以点击哪些按钮等的好地方。问题是攻击者会找到支持你UI的API并直接攻击它们——绕过所有这些控制。如果你在UI中过滤数据，那意味着API返回的数据超出了需要。如果你限制用户在UI中可以按的按钮，攻击者将尝试直接操作那些API端点。

有无数API安全漏洞的例子，其中攻击者能够利用API访问其他用户的记录。这是经典的BOLA（Broken Object Level Authorization，对象级授权破坏），也是OWASP API安全前10名中的第一名，理由充分。

许多组织在其API上实施认证并认为任务已完成。API被锁定，你必须提供有效的凭据才能访问它。但一旦认证，攻击者就使用API请求另一个用户的记录——通常是通过递增用户ID。这是一个授权缺陷，需要直接在应用逻辑中解决。

如今，大多数组织每月/每周/每天都会将新代码推送到生产环境。但API安全测试仍然主要是手动的，通常一年进行一次或两次，由渗透测试团队执行。开发的速度和测试的频率之间存在巨大的不匹配。因此，发布上线的API没有经过彻底的安全测试。

所需的是向左移动测试——在每次发布时测试API，针对一系列全面的攻击场景，作为CI/CD流水线的一部分。这样测试就能跟上发布的步伐，没有经过适当审查的API不会上线。实现这一目标的唯一方式是自动化测试的创建和执行，并与流水线和工单系统集成。