API 安全：不让大门敞开的基本步骤

当我们考虑系统安全时，我们会看屏幕：强密码、浏览器锁定、双因素登录。但攻击者并没有看屏幕。它着眼于 API，即界面背后的数据服务层，其中根本不存在可见的保护。

这是现代应用的危险的不对称性。该界面是为人类设计的，隐藏了复杂性。 API 是为机器设计的，直接公开一切。攻击者绕过按钮并直接与 API 对话，而界面的良好礼仪规则并不适用。

可以毫不夸张地说，API 已成为数字系统的主要攻击媒介。 OWASP 本身维护了主要 API 安全风险的特定列表，与 Web 应用程序的一般列表分开，正是因为问题有其自身的性质。本文为已在生产中拥有 API 并需要确保它们不是后门的团队提供了保护 API 的基本步骤的路线图。

为什么API是最有针对性的链接

该界面会过滤您所看到的内容。如果 API 设计不当，其提供的内容将远远超出屏幕显示的内容。 API 通常会返回整个用户对象，包括界面从不显示的字段，因为发送所有内容并让前端选择要显示的内容更容易。攻击者查看原始响应，发现其中的数据是任何人都不应看到的。

添加到自动化。攻击者不会像人类那样一次测试一个请求。它每秒扫描数千个组合，探测标识符、参数和端点。难以手动利用的缺陷在自动化规模上变得微不足道。

论文：保护接口而不保护 API 就是锁住前门，让后门敞开。真正的安全性存在于服务数据的层，而不是呈现数据的层。

每个 API 调用都需要证明是谁发起的。仅保护登录并信任其余部分是不够的。对受保护资源的每个请求都必须携带有效的凭证，通常是服务器验证的令牌。

最重要的是对这些代币的管理。它们必须具有有限的有效性，以便被盗的令牌不能永远使用。它们必须能够被撤销。并且切勿以不安全的方式运输或储存它们。长期存在、永不撤销的代币会招致灾难：只需一次泄漏即可。

这里常见的错误是将[身份验证2]视为一次性解决的问题。事实上，这是一个持续的颁发、验证、过期和撤销凭证的规则。

这是最重要也是最容易被忽视的一步。身份验证回答“你是谁？”。授权响应“您可以访问这个吗？”。它们是不同的问题，最严重的 API 泄漏来自于回答了第一个问题而忘记了第二个问题。

这种失败模式在 OWASP 列表中有一个名字：破坏的对象级授权。系统确认您已登录，但不会验证该特定数据是否是您的。结果是更改 URL 中的数字的经典攻击：您查询0，将其更改为1并查看其他人的请求。

不可协商的规则：对于每次访问资源，服务器必须检查该特定用户是否有权访问该特定资源。此检查无法位于攻击者控制的客户端上。在每个请求中，它都必须位于服务器上，无一例外。

API 不能信任任何来自外部的东西。所有输入、参数、请求正文、标头在使用前必须验证格式、类型和大小。信任输入是注入攻击的根源，其中恶意数据被解释为命令。

服务器上的严格验证是防御措施。客户端验证对用户来说是方便的，而不是安全的，因为攻击者只是绕过客户端并直接与 API 对话。

还值得限制可以发送的内容。接受大负载或返回大量数据的查询的 API 是过载和大量信息提取的载体。

如果没有速率限制，API 就会遭受暴力滥用和大量数据泄露。攻击者可以每分钟尝试数千个密码，或者循环遍历所有可能的标识符来下载整个数据库，只需发出许多快速请求。

速率限制，速率限制，限制客户端在给定时间内可以发出的请求数量。它是针对恶意自动化、拒绝服务攻击和数据抓取的简单而强大的防御措施。它的缺失会使任何其他缺陷变成可在工业规模上利用的东西。

两个实践结束了基本的设置。首先是避免暴露：API 应该只返回操作所需的数据，而不是“为了方便”而返回完整的对象。每个额外暴露的字段都会导致更多可能被泄露的数据。错误消息也不应该透露帮助攻击者映射系统的内部详细信息。

第二个是日志记录和监控。如果没有 API 中发生的情况的日志，攻击可能会持续数周而不被注意到。记录访问、身份验证失败和异常模式使您能够进行检测和响应。在[LGPD3]下的系统中，能够知道数据发生了什么以及何时发生，不仅是良好的安全实践，也是问责法律责任的一部分。

最常见的陷阱是将 API 安全性视为启动时的一次性检查。 API 不断发展，获得新的端点，与新系统集成。每一次改变都是引入缺陷的机会。攻击面随着每个版本的发布而增长，监控也需要随之增长。

还有 API 被遗忘的问题。仍在运行的旧版本、暴露的测试端点、不再有人维护的集成。这些幽灵 API 是最容易被利用的载体之一，因为它们没有受到任何人的关注。维护暴露的清单是防御的重要组成部分。

领导者的战略愿景：API 是您的系统真正存在的地方。在 API 未受保护的情况下投资接口安全是投资安全的外观，而不是安全。现代事件发生在数据实际传输的地方，这就是 API。

确保 API 的安全并不需要天才。它需要一致地应用基础知识：验证每个请求、授权每个访问、验证每个输入、限制速率、暴露最小值并记录所有内容。那些以有纪律的方式做到这一点的人会关闭大多数攻击进入的大门。

如果您的组织在生产中拥有 API，并且从未对它们进行过认真的安全审查，那么这是一个值得优先解决的盲点。还有其他关于[身份验证4、、OWASP 和安全架构] 的博客文章深入介绍了每个步骤。如果 API 安全性在您的环境中确实是一个问题，那么就值得讨论。