11月3日，threatpost网站发布了杰森肯特（Jason Kent）的文章。现在此对该文章作摘译如下，以供读者参考。
API（应用程序编程接口）安全风险在过去两年中发生了巨大变化。下面将讨论一下当今最重要的 API 安全问题以及如何解决这些问题。
“作为一名长期的OWASP成员和应用程序安全从业人员，我想与大家分享一下我的想法，新发布的OWASP Web App Top 10（应用安全风险Top 10）将会如何影响API security Top 10（API安全风险Top 10）的更新。”杰森肯特说。上一轮API security Top 10发布于2019年12月。
（图片来源：threatpost）
最近更新了Web App Top 10（应用安全风险Top 10），以反映不断变化的应用程序和威胁情况。
以目前的形式，API安全风险Top 10与2017年Web应用安全风险Top 10大致有60%的重叠。这在当时是有意义的，因为API的使用才刚刚开始激增，而且对于如何最好地满足API的安全需求，确实需要指导。
自API安全风险Top 10发布以来，API 的使用和相关的安全问题都发生了变化。即便如此，从API安全风险Top 10和新的 Web应用安全风险Top 10中可以得出许多相似之处：
（图片来源：threatpost）
在下一轮API安全风险Top 10列表中，我希望术语保持一致，尽管我不期望类似的定位，因为API和web应用之间存在明显的差异。我预计新的Web应用程序列表会有一些重叠，但会有一些特定于API的威胁，比如：
（图片来源：threatpost）
让我们来看看对未来列表的预测。
下一版OWASP API安全风险Top 10
API:1 和API:2：识别和认证失败以及访问控制中断
与API身份验证和授权错误相关的安全事件几乎与安全错误配置一样常见，这证明了将其放在列表顶部的合理性（并对错误配置排名的第5位提出了质疑）。组织需要更加关注他们设计和实现API的方式，也许可以使用安全规范来监视缺少的端点身份验证、授权和管理功能。
API:3加密失败
加密失败一直困扰着Web应用程序。在早期，开发人员拒绝进行可能需要用户升级的更改。因此，将强加密作为应用程序（或API）要求是不受欢迎的——但现在不会了。强制升级以改善数据保护并可能防止信用违约成为常态。开发人员可能会失去一两个客户，但它不会担心因为泄露的数据交换和糟糕的加密而发布有关信用卡违规的消息。同样，利用API的应用程序现在可以包含证书和强大的加密算法。
API:4缺乏资源和速率限制
此威胁在列表中排名更高，因为API使合法或恶意流量峰值更容易发生。今年我们看到针对API的恶意流量峰值增加了30倍。如果不应用速率限制，这将是一场灾难。组织需要更加努力地对API实施速率限制，因为它不仅有助于抵御恶意攻击，还有助于控制基础设施成本超支。
API:5安全配置错误
安全配置错误的API是我们在客户群中看到的常见错误。根据我们在新闻中看到的内容，这是许多组织的常见错误。意外的端点，或那些没有身份验证或授权标志的端点，只是我们看到的几个错误示例。出现这种频率的原因是，API安全性错误配置没有被大多数组织检测到。要想把这条从列表中删除，组织需要了解和测试他们的 API 功能——不仅仅是渗透测试，而是真正的功能测试。
API:6不安全的设计
应用程序安全架构师一度被视为一个奇怪的角色，但随着“左移”和DevSecOps的广泛采用，它的作用迅速发展。随着API变得越来越基础化，了解体系结构、特别是API每个部分的安全性至关重要。当应用程序在内部、外部或向第三方/从第三方使用或发送数据时，将访问或移动该数据的所有实例都需要安全设计。这只是一个小例子，当需要体系结构时，还需要考虑登录、会话管理、授权和其他方面。
API:7注入
注入在此列表中排名靠后，而在新的AppSec前十名中排名靠前，因为 Web 应用程序是通过Web浏览器查看的，并且需要JavaScript来呈现部分页面。这可能会导致跨站脚本攻击 (XSS)，随后通常会针对后端数据库进行SQL注入。API 通常不需要浏览器，因此注入是可能的，但可能性较小。API注入通常只发生在某人对应用程序有深入了解并试图打破另一种机制时。
API:8资产管理不当
API资产管理从一个良好的清单开始，该清单随着元素的添加和删除而更新。大多数组织都在为他们的应用程序清单而苦恼，很少有人准确了解他们拥有的 API 数量及其所有相关组件。API 可见性和资产管理应该是所有 API 安全计划的基石。
API:9日志记录和监控不足
每当问到“发生了什么？”这一主要安全问题时，只能通过找出可用的日志来得出答案。没有日志，很难确定根本原因。如果没有监控，很可能没有人会问“发生了什么事？”，因为违规行为仍然会发生。日志记录和监视成本低廉，易于实现，并且经常需要进行故障排除。我很想看到这一项在下一轮榜单中消失。
API:10数据完整性失败
对于任何围绕API中的数据完整性的事情来说，这最终有点笼统。这可能是第三方库或其他存在缺陷的依赖项。这可能是持续集成和交付(CI/CD) 管道未确认源或添加以某种方式易受攻击的源的问题。这些类型的故障越来越突出，但代码完整性的概念变得越来越重要。我们有机会扭转这一趋势。
这个 API Top 10列表，我觉得在不久的将来会在官方OWASP列表修订中反映出来。其中大部分来自处理被自动化对手攻击的 API，以及那些希望在组织内站稳脚跟的 API。
相关链接：
OWASP(开放式Web应用程序安全项目- Open WebApplication Security Project)是一个开放社群、非盈利性组织，长期致力于协助政府或企业了解并改善网页应用程式与网页服务的安全性。近期其发布的OWASP Web App Top 10（应用程序安全风险Top 10）一文摘译如下。
2021 年前 10 名发生了什么变化
有三个新类别，四个类别的命名和范围发生了变化，并在 2021 年的前 10 名中进行了一些整合。我们在必要时更改了名称，以关注根本原因。
· A01:2021-失效的访问控制 从第五名上升到 Web 应用程序安全风险最严重的类别；提供的数据表明，平均3.81%的测试应用程序具有一个或多个通用弱点枚举 (CWE)。映射到失效的访问控制的34个CWE在应用程序中出现的次数比任何其他类别都多。
· A02:2021-加密失败 上移一名至第二名，以前称为A3:2017-暴露敏感数据，这并非根本原因。更新后的名称侧重于与密码学相关的失败，因为它之前已经隐含了。此类别通常会导致敏感数据暴露或系统受损。
· A03:2021-注入 下滑至第三名。94% 的应用程序针对某种形式的注入进行了测试，最大发生率为19%，平均发生率为3.37%。跨站点脚本编写现在是此版本中此类别的一部分。
· A04:2021-不安全设计 是2021年的一个新类别，重点关注与设计缺陷相关的风险。如果我们真的想作为一个行业“左移”，我们需要更多的威胁建模、安全设计模式和原则以及参考架构。不安全的设计不能通过完美的实现来修复，因为根据定义，从来没有创建所需的安全控制来防御特定的攻击。
· A05:2021-安全配置错误 从上一版的第6名上升；90% 的应用程序都针对某种形式的错误配置进行了测试，平均发生率为 4.5%，超过208,000次 CWE 映射到此风险类别。随着更多转向高度可配置的软件，看到这一类别上升也就不足为奇了。
· A06:2021-易受攻击和过时的组件 之前的标题是使用具有已知漏洞的组件。该类别从 2017年的第9位上升，是我们难以测试和评估风险的已知问题。它是唯一没有任何通用漏洞披露(CVE)映射到包含的CWE的类别。
· A07:2021-识别和身份验证失败 之前是断开的身份验证，并且从第二名下滑，现在包括与识别失败更多相关的CWE。这个类别仍然是前10名的一个组成部分，但标准化框架的可用性增加似乎有所帮助。
· A08:2021-软件和数据完整性故障是 2021 年的一个新类别，专注于在不验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。来自通用漏洞披露/通用漏洞评分系统 (CVE/CVSS) 数据的最高加权影响之一映射到该类别中的10个CWE。A8:2017-不安全的反序列化现在是这个更大类别的一部分。
· A09:2021-安全日志记录和监视失败 之前是A10:2017-日志记录和监视不足 。此类别已扩展为包括更多类型的故障，难以测试，并且在CVE/CVSS 数据中没有得到很好的表示。但是，此类故障会直接影响可见性、事件警报和取证。
· A10:2021-服务器端请求伪造 数据显示，发生率相对较低，测试覆盖率高于平均水平，并且利用和影响潜力的评级高于平均水平。此类别代表安全社区成员告诉我们这是很重要的场景，即使目前数据中没有说明这一点。
（来源：threatpost等。本文参考内容均来源于网络，仅供读者了解和掌握相关情况参考，不用于任何商业用途。侵删）
