开发规范：API安全
API是现代移动、SaaS和web应用程序的关键组成部分，可以应用在面向客户、合作伙伴和内部应用程序中。API可以暴露应用程序逻辑和敏感数据。不安全的API很容易成为黑客攻击的目标，使他们能够访问安全的服务器或网络。攻击者可以试图执行中间人攻击(MITM)、分布式拒绝服务攻击(DDoS)、注入或破坏访问控制等攻击。
以下是一些通用的API安全建议：
API 资产管理
列出并记录应用程序的所有接口。
必须了解API的暴露及别了解这些信息将有助于更好地定义哪些API安全控制必须加强，哪些必须使用默认的安全设置：
内部API：内部访问的API，无需暴露在因特网，通过内部服务、后端/员工应用程序或合作伙伴通过VPN或其他安全手段在内部访问。
外部API：暴露在互联网上的API，外部用户可以访问，不管他们是合作伙伴还是客户端。
对于API本身，我们可以根据以下几点对API进行分类:
- 应用程序是由内部团队开发的还是由第三方合作伙伴开发的?
- 应用程序是由另一个API/后端应用程序访问还是由前端应用程序访问?
不支持的版本：
- 除了发布到互联网上的当前API版本之外，API不能有任何其他版本，任何特性都必须包含到最新的版本中，以符合最新的安全需求和最佳实践。
- 较旧的和开发版本的API必须只能在开发环境中访问，在开发环境中不能使用任何真实的客户数据。
授权安全
- 接口只能通过系统服务帐户运行，而不能通过任何个人帐户运行。
- API密钥身份验证：内部API必须在所有场景中使用基于API密钥或其他类型的强身份验证，限制对每个端点的访问的方式，即使攻击者可以通过网络访问我们的内部虚拟网络。
- API密钥最小权限授权架构：内部API密钥必须具有定义良好的基于角色的访问控制 (RBAC)，以便分配它们以限制每个密钥只使用它们所需的权限功能，从而减少数据泄漏风险。
跨域访问:
- 跨域请求必须使用安全机制(如跨源资源共享(CORS))和限制性策略(例如限制来自某些主机、域或禁用证书)。
- 跨域请求的源报头必须在服务器端得到授权。
- 服务应该实现最大请求限制(每个客户端或时间间隔)。
- WebSockets必须使用wss:// schema和源报头额外的服务器端授权来传输所有机密数据。
安全配置
安全配置错误不仅会暴露敏感的用户数据，还会暴露应用系统的细节信息，可能导致整个服务器遭到破坏。
注入验证
执行输入验证是为了确保只有格式正确的数据才进入信息系统的工作流，防止格式错误的数据保存在数据库中，从而触发下游各个组件的故障。输入验证应该在数据流中尽可能早地进行，最好是在从外部接收到数据时进行。
因此，我们的API接收的所有输入都必须经过验证，以便发现任何恶意输入或无效的信息尝试。这些检查必须对任何API的使用者进行，即使他们是内部的，因为他们可能有意或无意中输入的一些恶意的字符发送给API。
实现依赖于安全策略的正确输入验证控制。
防止过多的数据暴露
API通过设计将敏感数据返回给客户端。这些数据通常在客户端进行过滤之后呈现给用户。攻击者可以很容易地通过嗅探流量并查看敏感数据。
对于每个API的输出都应该进行规范化和细粒度：API必须有标准化的输出，考虑输出的颗粒度以最小化数据泄漏的风险，例如对用户ID或任何单一信息的请求应该只返回该信息，而不是与用户相关的所有数据。
- 明确地显式定义和强制执行所有API方法返回的数据，包括响应模式、字符串模式、字段名和错误信息。
- 检查来自API的响应，确保它们只包含合法的数据。
- 定义应用程序存储和使用的所有敏感和个人信息(PII)，并检查所有API调用和返回此类信息是最小必要的。
- 不要依赖客户端来执行敏感数据过滤。
资源和速率限制
如果 API 不对客户端/用户可以请求的资源的大小或数量施加任何限制，这不仅会影响 API 服务器性能，导致拒绝服务 (DoS)，而且还会为诸如蛮力攻击之类的身份验证缺陷敞开大门。
- API必须实施访问速率的限制，以减少身份验证攻击的可能性或其他的恶意使用，并通过实现锁定策略防止滥用使用和可能的暴力尝试攻击。
- 限制客户端在定义的时间范围内调用API的频率。实际的限制必须在每个API定义的基础上，分析可能的用例，如互联网开放API，将有许多用户但每个用户请求并不多，而相反在与合作伙伴进行数据处理的后端API中，单个用户请求会比较大。
- 对于敏感操作，如登录或密码重置，应对通过API认证的方式、客户端IP地址、用户属性等实现对API进行速率限制。
- 当超过限制数量时或重新设置新的和限制时间，须通知相关人员。
- 为查询字符串和请求体参数添加适当的服务器端验证，特别是控制响应中返回的记录数量的参数。
- 如果API接受压缩文件，在扩展文件之前检查压缩比，以对抗“zip炸弹攻击”
充分的日志和监控
日志记录和监控不足，再加上与事件响应的缺失或无效，使得攻击者可以进一步攻击系统、更持久地、转向更多的系统，进行篡改、获取或破坏数据。
因此，API也必须生成安全日志，并将这些日志集成到监视和SIEM(安全信息和事件管理)系统中。应该记录所有的在源系统和目标系统之间API事务和事件。
必须记录的信息如下:
- 应用程序特性尝试失败
- 拒绝请求/错误时使用的Key
- 输入验证失败
- 任何安全/使用策略失败
日志中不包括:
- 敏感数据
- 财务数据
- 用户数据
- 日志模式也应该在应用程序之间进行规范化，但是仍然需要定义确切的模型。
参考链接
- OWASP API Security Top 10 2019: https://owasp.org/www-project-api-security/
- NIST Guidelines on API Security: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf
- Cloud Security Alliance - API Security: https://cloudsecurityalliance.org/artifacts/security-guidance-api/
- Microsoft - API security best practices: https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design
- RapidAPI Developer Guide to API Security: https://rapidapi.com/blog/api-security-best-practices/
