虽然当今的企业定期为其内部应用程序提供 API，允许它们与其他软件通信，但这些接口有时存在安全漏洞，使敏感数据面临风险。在最坏的情况下，它们为 API 攻击打开了大门，可能导致灾难性的数据泄露。
一些主要的 API 风险来自发布 API，而另一些则源于使用 API 与其他地方的系统集成。
API 发布风险
身份验证错误或较弱
为了确保安全使用，即使在内部，API应该使用身份验证机制。然而，在API开发过程中，编码人员经常无法实现当前的验证和强身份验证，通常API后端是薄弱的身份验证，网络攻击者很容易破坏或绕过身份验证。
当API不能正确地建立API调用另一端实体的身份时，企业就面临着执行操作、共享敏感信息或接受来自其无意的人或系统的输入的风险。
缓解：遵循安全的开发方法。编码人员应该对强身份验证模块进行标准化，并在开发周期中使用静态测试等自动测试，以拒绝任何带有非标准身份验证的代码。安全人员针对API进行渗透测试，发现不充分的身份验证。
授权错误
不充分的API访问可能会阻止未经授权的访问，但会使合法的合作伙伴或客户在没有授权的情况下检索他们需要正常运行的数据和服务。
另一方面，过于宽泛的访问控制会让用户看到或执行超出他们需要的操作，并可能允许恶意行为者访问私人信息和系统。
缓解：通过完整的用户验收测试，还原真实的访问场景，API授予经过正确身份验证的请求访问所有必要数据的能力，无论该请求来自控制它的对象或数据存储。此类安全测试还应包括检索数据或执行测试帐户未授权的操作的请求。发布API的企业应该在其整体身份验证策略审计中添加API审查。
拒绝服务攻击
作为面向网络的服务，API 可能会受到 DoS 和 DDoS 攻击，这些攻击用虚假流量淹没它们。如果 API 提供业务必需的服务，则其性能不佳或缺乏可用性将会对业务造成严重影响。
DoS或DDoS攻击可能意味着API无法及时为合法请求提供服务。或者，格式错误的请求可能导致它们消耗资源而不释放资源，从而耗尽资源，最后进程崩溃。
缓解:在请求到达后端系统之前对其进行排队和限制。此外，考虑实现DDoS防御和更严格的编码，以防止“挂起请求”问题。
服务器端请求伪造
API主要风险之一是服务器端请求伪造。SSRF 会在不知情的情况下将 API 服务变成不良行为者的工具，从而造成横向入侵或成为攻击他人的帮凶的风险。
缓解:限制输入上有效url的类型和范围，使它们只能执行预期的操作。在url上使用当前解析器，以确保它们是格式良好且符合预期类型的。使用许可名单来控制url可以指向的位置。
恶意输入
API处理程序接受用户输入，并将其存储在代码或外部数据库的数据结构中，而不首先对其进行检查。这是SQL注入攻击、缓冲区溢出攻击、SSRF等的经典载体。
缓解:不接受来自请求者的原始输入，并且始终解析和验证输入。
数据过度共享
API有时暴露的数据比公司数据安全政策规定的要多。这就造成了个人身份信息或其他受保护信息可能被不当泄露的风险。
缓解:针对限制记录数量但不限制包含的类型或字段的数据集进行测试，以便更准确地验证访问。使用数据丢失防护系统来监控和提醒、阻止数据泄露。
API 依赖项
当内部流程依赖于与外部集成相同的 API 服务时，企业业务流程会受到 API 用户的干扰。以 API 为中心的 DoS 攻击可能会削弱内部流程(不仅仅是面向外部的流程)，并严重阻碍组织的业务能力。
缓解:将面向内部的 API 服务与面向外部的 API 服务隔离，以防止对外部 API 的攻击直接影响内部 API。
其他 API 风险源
发布 API 的公司的其他常见风险来源包括：
- API 底层服务的版本控制不足，导致身份验证、授权和输入扫描不匹配。
- 缺少或不充分的 API 活动日志记录和日志监控。
OWASP的10大API风险
- 对象级授权中断。
- 身份验证损坏。
- 损坏的对象属性级授权。
- 不受限制的资源消耗。
- 函数级授权损坏。
- 不受限制地访问敏感的业务流程。
- 服务器端请求伪造。
- 安全配置错误。
- 库存管理不当。
- 不安全地使用 API。
API 使用风险
API 风险不仅限于发布，考虑以下与API使用相关的风险。
不安全的数据使用
当一个组织使用API从其他地方的系统检索数据时，会产生数据不良甚至是恶意的风险。这可能会导致组织做出错误的决定，采取不正确的行动，或者向监管机构、客户或合作伙伴报告虚假信息而不是事实。
缓解:输入验证是保护API的关键。跟踪数据的来源，以便对问题进行适当的归因和调查。
未记录的第三方风险
当企业承担第三方风险时，就会给自己带来问题，这些风险可能来自其供应商。
缓解:通过限制API使用的其他API的数量来控制API生态系统。寻求与其他API提供商签订合同协议，来定义和限制来自第三方风险。
业务流程中未记录的风险
当业务流程依赖于 API 使用，但没有记录这种依赖关系时，可能造成一些流程中断。对业务流程的更改可能忽略了它们需要更改API的使用方式这一事实。或者更改API的工作方式可能会导致其行为的细微变化，这些变化造成的问题可能不会立即显现出来。
缓解:记录所有业务流程。使用零信任架构来限制内部系统在没有明确许可的情况下接触内部或外部API。
参读链接：
