API 安全最佳实践

应用程序编程接口 (API) 安全性是指确保基于 Web 的 API 能够响应请求、安全地处理数据并按预期运行的设计、流程和系统。

API 安全是一个非常广泛的话题，因为许多不同的 API 框架和系统运作方式各不相同。本指南将帮助您构建更好、更安全的 API，并帮助您评估当前 API 实现的安全基础。

为什么 API 安全很重要？

现代 Web 编程已将应用程序的前端（HTML/CSS/JS）与后端（服务器端处理和存储）分离。同样，移动应用程序通常在应用内部处理面向用户的功能，但将数据传回中央服务器。这些趋势引发了目前投入生产的 Web API 数量的大幅增长。

API 安全与一般 Web 安全有何区别？

Web/HTTP 应用程序编程接口 (API) 具有独特的威胁模型、安全问题和身份验证模式，与标准 Web 应用程序截然不同。这种差异很大程度上是因为独立 API 无法依赖基本的浏览器安全功能来限制攻击者可能执行的操作范围。

如何保护 API

以下指南结合了多种技术和建议：

• 您可以直接在应用程序中实现
• 您可以做出设计选择来加强您的安全模型
• Expedited WAF 的功能可使整个过程更加简单

目录

1. 针对 API 的分布式拒绝服务攻击
   • 经典DDoS攻击
   • 现代拒绝服务攻击
   • 失控的 API 客户端 [案例研究]
2. 数据泄露攻击
   • SQL注入（SQLi）
   • JSON SQL注入 [案例研究]
   • 非 SQL 查询注入 (NSQLi)
   • 社交搜索问题 [案例研究]
   • XSS 和代码注入 API 攻击
3. 功能和资源攻击
   • 电子邮件发送
   • 位置追踪
   • 链接和文件发布
   • 加工
   • 网络钓鱼
4. OWASP 十大漏洞
   • 为什么要关心 OWASP Top 10？
   • OWASP Top 10 是针对 API 的吗？
   1. 代码注入
   2. 身份验证失败
   3. 敏感数据泄露
      • Devise Auth IP [案例研究]
   4. XML外部实体（XXE）
   5. 访问控制失效
   6. 安全配置错误
   7. 跨站脚本
   8. 不安全的反序列化
   9. 使用存在漏洞的组件
   10. 日志记录和监控不足
5. API 安全控制
   • 阻止 DDos 探测
   • 停止匿名代理网络
   • 指定允许的 IP 范围
     • 生产中的机器人 [案例研究]
   • 地理过滤
     • 南非 NSFW 内容链接 [案例研究]
   • 过滤机器人
     • 自动扩展 SEO 机器人 [案例研究]
6. 传输中的 API 安全 (SSL/TLS/HTTPS)
   • API 的 HTTPS 强制执行
   • TLS 版本强制执行
7. API 身份验证方法
   • API 密钥
   • 基本身份验证
   • 客户端证书 API 身份验证
   • 适用于 API 的 OAuth 2.0
8. 授权
   • 基于角色的访问控制
   • 基于属性的访问控制
9. 安全 API 设计指南
   • 简单胜过复杂
   • 允许最小权限
   • 谨慎地公开数据
   • 收集最少的数据
   • 版本控制
   • 记录请求和响应
10. 安全程序
    • 处理安全报告
    • 数据泄露事件规划

1. 针对 API 的分布式拒绝服务 (DDoS) 攻击

⇑ 返回目录

针对您的 API 采取的任何导致合法请求服务中断的行动都属于拒绝服务攻击。

保护 API 免受 DDOS 攻击是一项挑战，主要有两个原因：

1. API 客户端往往比 Web 用户消耗更多且更昂贵的请求。
2. 一些最常见的 DDoS 预防机制（如 CAPTCHA）在 API 环境中没有意义。

更糟糕的是，外部（非意外）攻击通常更为严重，因为它们通常由以下因素发起：

• 试图让您下线的竞争对手。
• 心怀不满的前雇员（对您的系统有深入的了解）。
• 网络犯罪分子试图勒索您停止攻击。

没有任何灵丹妙药可以阻止针对您的 API 的所有攻击，但以下方法形成了一种可以抵御大多数攻击的“秘诀”。

应用哪一个取决于客户端如何对您的 API 进行身份验证，客户端是从浏览器、专用客户端应用程序还是混合系统内进行操作，以及您需要支持的客户端总数。

经典分布式拒绝服务 (DDoS) 攻击

经典的分布式拒绝服务 (DDoS) 攻击依赖于低级网络技巧，例如TCP 放大攻击，其操作包括发送一个数据包，但需要服务器发送十个数据包作为响应。

网络和云操作已经擅长识别和阻止此类攻击。

现代拒绝服务攻击（HTTP 洪水）

现代拒绝服务攻击采用镜像合法流量的完整 GET/POST HTTP 请求（HTTP 洪水）。

在 HTTP 层运行的 Web API 容易受到这些攻击，因为每个 API 请求：
需要占用大量的服务器资源来解析和响应；
连接保持打开状态的时间更长；
更难确定请求是合法的还是故意制造的破坏行为。

更糟糕的是，API 提供商和 API 客户端之间的复杂交互很容易导致对 API 的无意拒绝服务攻击。

我们无法在应用程序中足够快地识别和终止连接以跟上速度。

• 被阻止的 HTTP 请求仍然会消耗应用程序资源，导致合法请求下线。
• API 客户端重试失败的请求并不断敲击 API。

2. 针对 API 的数据泄露攻击

⇑ 返回目录

数据泄露攻击试图从您的 API 中提取超出用户授权访问范围的信息。这些攻击形式多样，从隐蔽攻击（例如操纵搜索过滤器以返回通常超出范围的记录）到机器人程序在抓取数据时尝试暴力破解“不可猜测”的 URL。

API 特别容易受到数据泄露攻击，因为它们的设计初衷是供程序化使用。攻击者无需对 Web 应用的端点进行逆向工程，也无需尝试绕过 Web 表单中的真实性令牌。

注意：我们将这些攻击归类为“数据泄露”攻击，因为从我们的角度来看，这是最糟糕的情况（所有）

API 中的 SQL 注入 (SQLi)

SQL注入是最著名的数据漏洞。典型的攻击方式是攻击者将API URL从请求单个ID值更改为：

标准请求

要求：https://api.example.com/?user_id=1234

生成的 SQL：SELECT * FROM users WHERE id = 1234

注入请求

要求：https://api.example.com/?user_id=1234%20OR%20*

生成的 SQL：SELECT * FROM USERS WHERE id = 1234 OR *

这使他们能够从应用程序中提取整个用户表。

现在，这些类型的攻击通常会作为 Web 框架的安全机制的一部分被阻止。

然而：

1. 完美的实现并不存在，即使在时间和资源紧张的情况下，Web 框架仍然依赖于开发人员每次都正确完美地实现保护机制。
2. 开发人员最容易偏离标准开箱即用框架查询功能的一个领域是报表。许多应用程序试图公开一个“报表生成器”界面，让用户指定列、过滤器和连接来提取数据。这些返回到 API 的查询需要特别注意，以便进行正确的转义，因为它们更复杂，更容易被操纵。

{查询：'从任何表中选择*且无限制'}

非 SQL 查询注入 (NSQLi)

随着应用程序需求的变化，数据存储变得更加多样化，现代 Web 应用程序通常混合使用全文搜索应用程序、No-SQL 数据存储和缓存服务器将数据传回客户端。

这些数据存储区均具有自己的自定义查询语言，与传统 SQL 服务器（如Postgres和MySQL ）一样容易受到注入攻击。

但大多数开发人员所依赖的用于保护他们的 Web 框架并没有同样成熟的内置清理机制。

这并非空谈，此类攻击的实际案例目前已在野外发生。SOLR 搜索引擎及其对应的Apache Solr 注入项目就是一个很好的例子，它证明了不当转义的 SOLR 查询很容易返回越界数据或启用远程代码执行（如下图所示）。

SOLR 注入项目中注入脚本的 SOLR 查询

生成搜索结果页面是我们网站上执行最繁重的操作，似乎有一半的中国用户都在同时进行查询。

3.针对 API 的功能和资源攻击

电子邮件发送

位置追踪

除非经过适当过滤，否则 IP 地址和图像上传都会泄露位置数据。

• IP 地址可以通过IP to Earth等服务运行来确定（粗略）位置。
• 上传图像中的 EXIF 数据通常包含位置信息，除非故意剥离，请参阅Pic2Map

链接和文件发布

链接出版

文件上传

网络钓鱼

HiddenEye 将为 Facebook、Google、Twitch 等生成网络钓鱼资产……

4. OWASP 十大 API 漏洞

为什么要关注 OWASP Top 10

OWASP 列表的核心是一种优先级排序方法。它告诉您的同行，他们已经受到了这些特定类别攻击的影响，并且您也应该做好系统防御的准备。

OWASP Top 10 是针对 API 的吗？

1）代码注入

您应该做什么：
过滤所有入站输入。限制自定义内容，并将自由格式的输入与结构化数据存储分开。

2）身份验证失败

3）敏感数据泄露

案例研究：设计授权 IP

用户配置文件的简单 API 实现可能会无意中暴露该 IP 地址。

4）XML外部实体（XXE）

它是什么？

针对用于处理基于 XML 的请求的 XML 解析引擎的攻击。

您应该做什么

保持您的 XML 解析库为最新版本。

5）访问控制失效

什么情况？

对拥有合法访问权限的用户设置的限制不足。例如，普通用户可以访问 API 中的管理功能。

您应该做什么

审核您的系统是否存在越界访问。

6）安全配置错误

它是什么？

如今的系统非常复杂，以至于最终结果是什么以及谁可以访问它并不总是清晰可见。


一个常见的例子是，许多使用 Amazon Web Services 的 API 会将数据处理作业输出到 S3，但 S3 存储桶本身却没有获得正确的权限。

如果 API 是安全的，但由于配置错误，输出写入 S3 时数据不安全，那么该 API 实际上是不安全的。

您应该做什么

测试并记录内部和外部系统是否存在错误配置。

7）跨站点脚本（XSS）

什么是

操纵您的 API 来进一步传播恶意脚本。

您应该做什么

强烈过滤所有输入以确保正确性和脚本组件。

8）不安全的反序列化

它是什么？

任何时候，当数据对象从一种符号系统转换为另一种符号系统时，执行反序列化的系统本身就存在可被利用的漏洞，这是很危险的。

您应该做什么

保持您的序列化和反序列化库为最新版本，过滤恶意输入。

9）易受攻击的组件

它是什么？

现代 Web 开发在很多方面都是一个将各种库和服务整合在一起以创建所需结果的系统。虽然这极大地提高了程序员的生产力，但它隐含地要求所有组件都经过永久测试和更新。

您应该做什么

使用众多服务之一来自动跟踪框架中包含的软件包并提醒您注意不安全的版本。

10）日志记录和监控不足

它是什么？

大多数安全漏洞都是在实际发生后很久才被发现。确定哪些数据受到影响、哪些系统受到影响以及需要采取哪些措施来补救，都取决于拥有完善的访问、安全警报和用户活动日志。

您应该做什么？

定义数据保留策略，包括保留多久以前的日志。监测您的 API 访问操作，以记录关键指标和事件。确保日志可索引和搜索。

5. API安全控制

⇑ 返回目录

就安全功能而言，“控制”是指任何允许您应对威胁的功能或流程。数据隐私和安全法规通常会引用这样的措辞：“……应用程序应该有控制措施来应对 X、Y 和 Z 等威胁”，其中 XYZ 指的是网络犯罪分子对您的 API 进行攻击。

以下安全控制措施有助于抵御针对 API 的拒绝服务、数据泄露和其他攻击。没有任何控制措施能够 100% 有效地抵御威胁。因此，务必将这些控制措施与应用程序级安全预防措施相结合，以实现深度安全。

以下是提高 API 整体安全性的通用技术和方法（控制）。

大多数攻击探测会跨越多个不同的威胁领域。例如：阻止攻击探测通常会同时阻止 DDoS 攻击探测和框架漏洞探测。

停止匿名代理网络

使用 Expedited WAF 之类的解决方案，拦截来自少数 IP 地址的攻击轻而易举。攻击者的应对之策是利用所谓的“匿名代理”来掩盖攻击的真正发起点。

虽然确实存在合法的匿名代理提供商，但大多数情况下，“匿名代理”是一种委婉的说法，指的是“某人家中的一台 PC 被恶意软件感染并被远程操纵”。

这些网络很难靠自己对抗，只有通过不断梳理已识别的匿名代理的共享安全供应商列表以及我们来自 20,000 多个站点的数据，我们才能在网络级别阻止匿名代理。

阻止匿名代理具有双重好处，既可以阻止 DDoS 请求，又可以阻止针对应用程序的许多 Web 攻击的源头。

指定允许的 IP 范围

根据 API 的使用模型，您可以通过仅允许指定的 IP 和 IP 范围来进一步扩展端点的安全性。许多流行的 API 将明确允许的 IP 与令牌或 API 密钥结合使用，以此在其端点上增加额外的安全层级。Namecheap Domains API就是一个很好的例子，成千上万的组织都在使用它。

在像 Heroku 这样的云环境中（主机通过名称而非 IP 引用），客户端需要使用类似以下插件之一，以确保所有 API 调用都从同一 IP 地址进行。有许多服务旨在帮助解决以下情况：

• Fixie
• QuotaGuard 静态
• 普罗西莫

地理过滤

虽然理论上，针对 API 的攻击可能源自互联网上的任何地方，但实际上，它们通常源自同一个国家/地区。造成这种情况的原因多种多样，但其中一些国家/地区的网络安全监管较为宽松，另一些国家的计算机用户更容易被僵尸网络入侵，或者仅仅是因为攻击者更容易入侵使用其母语的计算机。

考虑到这一点，快速阻止某个国家针对您的 API 发出 GET/POST 请求可能是阻止正在进行的攻击的最快方法。

未能关闭 NSFW 链接可能会导致
Google 屏蔽您的网站。

从单页应用程序和浏览器 API 中过滤机器人

单页应用程序通常采用前端框架（如 React、Angular 或 Vue）构建，在每次交互时调用后端 API。

根据需要，任何具有右键单击页面并打开开发人员工具的技术能力的人都可以轻松发现 API 端点。

攻击者将利用这些端点并尝试暴力破解或使用命令行工具以其他方式操纵它们。

Expedited WAF 可以对机器人活动进行指纹识别并阻止这些尝试的端点枚举。

我们没有意识到有那么多愚蠢的机器人。

6. 传输中的 API 安全性（SSL/TLS/HTTPS）

⇑ 返回目录

SSL/TLS（HTTPS）是迄今为止基于 Web 的 HTTP API 最常用的传输加密机制。

安全 API 连接并非没有挑战，因为 HTTPS 连接提供的大部分安全性是 Web 浏览器创新的结果，例如 HSTS、协议协商以及其他有助于实施更高级别安全性的创新。

相比之下，大多数 API 客户端使用的 HTTP 请求/响应库默认没有或不启用类似的功能。

Expedited WAF 的 HTTPS 强制功能可消除不安全选项并阻止规避尝试，从而帮助减少不安全连接的可能性。

API 的 HTTPS 强制执行

所有客户端发送至 API 的请求都应加密（HTTPS）。遗憾的是，许多客户端 HTTP 库默认不启用 HTTPS/安全连接，因此有必要在服务器端强制启用该功能。

不幸的是，许多客户端 HTTP 库默认不启用安全连接。

Expedited WAF 将 HTTPS 强制执行作为标准（状态代码 301）重定向。尝试通过 HTTP 连接的客户端将被无缝重定向到安全的 HTTPS 连接，而不会被强制建立不安全的连接。

TLS 版本强制执行

大多数 http 客户端库都能够与多个不同版本的 SSL/TLS 规范进行交互。像 Chrome 这样的现代 Web 浏览器会优先选择最安全/最新版本的 TLS (1.3)。

许多 HTTP 库都有不同的握手模型，而是从最旧版本的 TLS 向上工作到最新版本（并且底层 SSL/TLS 库正在使用并且尚未更新）。

这会导致连接更容易被欺骗或中断。Expedited WAF 默认强制执行 v1.2 及更高版本的连接，以防止降级攻击和配置不当的客户端进行不安全的连接。

7. API 身份验证方法

⇑ 返回目录

保护 API 安全没有“最佳”方法，您需要根据以下情况选择方法：

1. 您需要支持多少个客户
2. 数据敏感性
3. 流程问题（可撤销性、到期性）
4. 支持的平台
5. 开发人员体验
6. 用户支持
7. 监管指南
8. 记录/跟踪需求

API 密钥认证

自从 Web 应用程序上线以来，静态 API 密钥就是访问 API 的经典方式之一。

何时使用 API 密钥

API 密钥支持非常简单的交互模型，该模型非常适合以下 API 客户端：

• 直接访问资源
• 在可以保守密钥秘密的平台上工作（服务器应用程序）

允许多个键

您的 API 用户应该能够生成多个密钥。这样可以在开发、测试、预发布和生产环境中进行更细粒度的访问和跟踪。

根据您的系统，允许每个开发人员或使用 API 的应用程序创建单独的 API 甚至可能是有意义的

API 密钥存储

客户端代码示例应在假设 API 密钥是从安全密钥存储区加载的、非源代码控制的环境机密文件或 Heroku 的环境变量配置功能的情况下生成。

允许自我撤销

用户应该能够撤销 API 密钥的当前授权。当密钥可能暴露给未经授权的用户时，需要撤销授权。

示例：意外签入一个密钥，然后将其部署到公共 Github 存储库。

允许过期

在某些情况下，允许 API 密钥过期有利于限制正在使用的密钥总数。

API 使用 API 密钥进行身份验证

以下突出的服务使用 API 密钥作为其身份验证方案的某些方面。

• IBM Cloud API
• Data.gov API
• 谷歌云 API

基本身份验证 API 身份验证

Basic Auth 将未加密的安全凭证（用户名和密码）通过标准 HTTP 标头传递到 API 端点。这使得它能够与几乎所有现有的 HTTP 库和 API 使用应用程序兼容。

请访问 Mozilla 开发者网站以获得有关Web/Basic 身份验证的更深入的解释。

何时使用基本身份验证

在现代 Web 应用程序中，基本身份验证通常与其他 API 身份验证方案混合使用，以创建更安全的系统。标准基本身份验证不太可能成为您进行标准 API 身份验证的必要依赖。

必须使用 HTTPS

基本身份验证 (Basic Auth) 使用 Base64 编码凭证，但由于凭证在传输过程中不会加密，除非您强制使用 HTTPS 连接，因此凭证在传输到服务器的路径上可以被任何中间设备读取。如果您使用的是 Heroku，Expedited WAF 将强制执行完全 HTTPS 合规性。

Basic Auth 与其他方案结合的示例

有许多值得注意的 API 将基本身份验证与 API 密钥或生成的令牌一起使用，以为其应用程序增加更多安全深度。

• Heroku 附加组件 API
• Jira 云

客户端证书 API 认证（X.509）

许多开发人员都熟悉用于保护服务器通信安全的 TLS/HTTPS 证书。鲜为人知的是，您可以向客户端颁发用于身份验证的公钥基础设施 (PKI) 证书。

何时使用客户端证书

客户端证书身份验证为 API 通信的身份验证和传输增加了另一层加密复杂性。管理、分发和支持客户端证书的开销并不小。

当您拥有有限数量的高价值 API 客户端和足够的支持资源来协助他们时，最适合使用此方案。

工作原理

客户端和服务器证书使用同一组密钥生成，并且需要保持同步。首次建立连接时，客户端和服务器证书都会相互验证，如果其中一个证书已过期、失效或信息不匹配，则底层 API 连接（HTTP 请求）将无法建立。

OpenSSL 生成 x.509 证书

通常，同时，另一个身份服务（例如 Active Directory）会验证客户端证书的真实性。

客户端证书认证 API 示例

• Microsoft Azure API 管理（支持）
• Salesforce API

适用于 API 的 OAuth 2.0

开放身份验证 (OAuth) 结合了身份验证（谁正在连接到您的 API）和授权（连接者可以访问哪些内容）的元素。OAuth 2 旨在成为身份验证/授权的行业标准协议，在用于第三方访问的 API 时表现出色。

OAuth 1 与 OAuth 2

尽管版本有所改进，但 OAuth 2 是该协议的一个简化版本，并且相当容易实现（即使没有客户端库）。

需要 HTTPS

OAuth 2 比 OAuth 1 简单得多的主要原因之一是 OAuth 2 依赖 TLS/SSL 来保护传输安全。安全的 OAuth 2 实现需要 HTTPS 连接。

何时使用 OAuth

OAuth 非常适合 API 生态系统，其中开发人员为最终用户构建应用程序的主要服务。

OAuth 与 API 密钥

考虑一个图书馆，它向其顾客公开一个 API，该 API 的单个端点返回顾客曾经借过的所有书籍，并允许您借阅一本书。

GET https://library-example.com/books

API 密钥： API 密钥身份验证模型允许开发人员创建应用程序来使用 API 并分析书籍以供自己使用。

OAUTH 2： OAuth 2 身份验证模型允许开发人员创建一个应用程序“CheckApp”，图书馆的其他用户也可以使用该应用程序，身份验证/授权可以包括访问的范围限制，可以轻松地从主服务中撤销，并限制用户名/密码的重用和分发。

OpenID 连接 (OIDC)

OpenID Connect 是 Open Auth 2.0 的一个进一步简化的子集，专注于请求和返回一小组可跨服务使用的用户特定信息。虽然这听起来可能很符合您的需求：

1. 一旦您超出个人资料、电子邮件、地址和电话的范围，您就会回到完整的 OAuth 2 实现。
2. OIDC 的承诺之一是它将允许服务之间更轻松地实现，但每个使用它的服务都选择分割它们的实现。

使用 OAuth 2 进行身份验证的 API

• Github
• Facebook
• Fitbit

8. API授权方法

⇑ 返回目录

授权（如果连接到您的 API 的用户有权限执行某项操作）是 API 创建过程中的一个重要但经常被忽视的方面。

通过在 API 中建立处理授权的一致模型，您不太可能过度授予用户权限，允许不安全的默认值持续存在，因此，您将提供更安全的应用程序。

基于角色的访问控制（RBAC）

角色是授予 API 用户的权限集合。以 Wordpress 用户角色为例。默认情况下，Wordpress 会创建多个不同的角色，例如管理员（完全控制文章和用户）、编辑（控制所有文章，但不控制用户）、作者（控制自己撰写的文章，但不控制其他文章）等。

Wordpress 的REST API将这些角色扩展到针对 API 端点的调用，因此，例如，编辑者无法通过 API 修改用户。

通过在 Wordpress 中提供具有相关访问权限的多个角色，开发人员大大提高了平台的安全性。

基于属性的访问控制（ABAC）

有时称为基于策略的访问控制 (PBAC)， PBAC/ABAC 的总体概念是基于角色的严格访问控制过于不灵活且效率低下。

在这个授权模型中，重要的是请求的上下文和被请求的上下文。

ABAC 策略示例

考虑一个 API，其端点返回公共信息（整体系统状态）和私人信息（用户的个人资料信息），在 ABAC 系统中，可以对这些端点应用两种不同的策略。

公共状态端点的策略可能是：

IF $client_api_key IS valid
THEN return resource

私人用户配置文件端点可能是：

IF $client_api_key IS valid

AND $client_api_ip_address IS WITHIN $allowed_ip_range

THEN return resource

策略的属性

创建策略时使用的一些常见上下文属性包括：

• 客户端 IP
• 时间
• 客户请求国家（地理 IP）
• 速率限制
• 用户代理
• 检测到 VPN/匿名代理
• 请求敏感

根据所请求的资源和上述因素的组合，可能会应用额外的访问要求，或拒绝访问。

9. 安全 API 设计

⇑ 返回目录

API 本质上极其多样化，允许开发人员做任何事情，从查明明天是否晴朗到在不到 45 分钟的时间内毁掉 4.4 亿美元。

尽管 API 的性质非常不同，但仍有一些基本方法可以帮助您创建安全可靠的 API。

简单意味着安全

“简单”和“复杂”的静态定义永远无法真正捕捉到所涉及的感受。

简单就是“我会做的事”，而复杂就是“其他人做的事”，从这个角度来看，实现 API 总是很复杂，因为其他人正在使用你的想法和设计。

就连 DHH 也同意

为您的 API 选择尽可能简单的身份验证、授权和安全控制方法。利用行业标准技术，不要自行实现加密解决方案。此外，API 的安全性应优先于灵活性。设置安全默认值，并在更改时发出警告。

允许最小权限

最小权限应用于 API 意味着仅允许 API 客户端访问其所需的必要任务。仅在必要时才应授予其他功能。

通过基于角色的访问、单独的读/写 API 密钥、OAuth 范围和细粒度的权限系统来实现这一点。

谨慎地公开数据

与最小权限类似，您应该努力仅包含任何 API 调用所需的绝对最少量的数据。

这不仅最大限度地减少了您意外暴露敏感字段的可能性，而且还防止了可以通过关联来自不同数据集的数据推断出的个人信息的无意泄露（API 的一个特定漏洞）。

1700 万人的数据遭到泄露。

2019 年 12 月， Twitter Android API 的一个设计缺陷被曝光。Twitter 的 API 允许将大量生成的电话号码列表上传到其账户匹配 API。通过这种方式，超过 1700 万个电话号码与 Twitter 账户进行了匹配。

收集最少的数据

在 GDPR 或 CCPA 等数据法规出台以及大量数据泄露事件破坏人们的隐私之前，人们普遍认为系统中拥有数据是一件好事。

目前，持有用户数据更像是持有有毒资产。

持有用户数据就像持有有毒资产。

尽量减少收集的数据量。记录收集每条用户数据的原因。记录用户同意将数据提供给你的信息。

版本控制

不可避免的是，在某个时候，您需要对您的 API 进行可能具有重大影响的更改；在那一刻，您会感谢自己从一开始就有远见地将请求版本控制构建到您的 API 中。

版本控制不仅对客户端和开发人员来说是一个很好的功能，还为您提供了一个清晰的流程来弃用可能不如您预期安全的旧 API 方法，让您可以干净地切换到更强大的身份验证方法，并将这些更改通过工作代码传达给您的 API 客户端。

Stripe 的工程博客列出了他们经历过的一些步骤，以及将版本控制作为其 API 的一流功能实施所带来的好处。

记录请求和响应

本文前面部分，我们抽象地讨论了“日志记录”，并讨论了有多少应用程序没有充分保留或构建日志以调查数据泄露事件。现在，我们将重点讨论请求/响应周期，以及一个可以添加到每个响应中的功能：添加 request_id，以大大简化日志搜索和调试。

通常，这是输入（请求参数、JSON 博客、SOAP 信封等）的加密哈希，在响应中返回并记录。

稍后，如果发现 API 的数据转储，安全研究人员会报告问题，或者即使您只是在调试，您也可以非常轻松地搜索日志参数。

10.安全程序

⇑ 返回目录

处理安全报告

即使有最好的意图、最新的框架和安全控制堆栈，您的 API 仍然可能存在安全问题。

鉴于此，公开建立一个可以报告安全问题的联系点至关重要。如果没有公开的联系方式，安全报告可能会在支持或客户服务队列中丢失。最简单的方法是在“联系我们”页面添加一个别名（我们的security@example.com页面如下）。

你不能走进一家星巴克，点一杯派克市场大杯啤酒，然后漫不经心地报告说你已经获得了他们所有内部管理应用程序的访问权限。

或者，您可以将“security.txt”文件添加到您网站的根目录，更多信息请访问：securitytxt.org。

举个实际的例子：星巴克的API 开发人员意外地将一个API 密钥遗留在一个公共 Github 仓库中，而该仓库允许访问星巴克内部的身份验证和单点登录 (SSO) 服务。一位独立的漏洞猎人发现了这个密钥，并通过星巴克的漏洞披露服务将其报告给了星巴克，最终开发人员得以在系统受到影响之前解决问题。

现在，想象一下没有这些通讯系统的情况。你不可能指望走进你家门口的星巴克，点一杯派克市场大杯，然后漫不经心地跟你说，如果你愿意的话，你可以在他们的公司网络上冒充霍华德·舒尔茨。

清晰的安全沟通渠道：

• 减少漏洞暴露的时间
• 鼓励威胁研究人员在漏洞修复之前公开漏洞
• 改善整体安全态势

安全通信流程是提高 API 安全性的最有效、最快捷且最具成本效益的方法之一。

数据泄露处理

根据您的管辖范围，如果发生数据泄露，您需要向各个机构报告，例如美国州检察长或欧盟国家的数据保护机构。

在大多数情况下，随着敏感度水平的提高（例如：在数据泄露中，医疗数据比当地天气报告受到更严重的处理）和受影响人数的增加，报告要求的级别也会不断升级。