API 安全是 Web 应用的基础保障。根据 OWASP 2024 年报告，约 40% 的安全漏洞来自 API 设计不当。核心要素是：认证、授权、限流、加密。本文结合行业数据与实践案例，介绍 API 安全设计的核心要素与实践步骤，帮助开发者构建安全的 API 接口。
一、API 安全为何重要：数据与威胁
API 是应用的核心入口，安全漏洞可能导致数据泄露、服务中断、经济损失。合理的安全设计可防范 80–90% 的常见攻击。
| 威胁类型 | 影响 | 防护措施 | 防护效果 |
|---|---|---|---|
| 未授权访问 | 数据泄露、功能滥用 | 认证 + 授权 | 防范 90%+ |
| DDoS 攻击 | 服务不可用 | 限流 + WAF | 防范 80–90% |
| SQL 注入 | 数据库泄露 | 参数化查询、ORM | 防范 95%+ |
| XSS/CSRF | 用户数据窃取 | 输入验证、CSRF Token | 防范 85–95% |
| 敏感数据泄露 | 隐私泄露、合规风险 | 加密传输、加密存储 | 防范 90%+ |
数据来源：OWASP Top 10、Snyk、Veracode 等安全报告（综合整理）。
根据 Verizon 2024 年数据泄露报告，API 相关安全事件占比约 35%，且呈上升趋势。下表对比了不同安全措施的效果：
| 安全措施 | 防护范围 | 实施难度 | 成本 |
|---|---|---|---|
| HTTPS/TLS | 传输加密 | 低 | 低（免费证书） |
| JWT 认证 | 身份验证 | 中 | 低 |
| RBAC 授权 | 权限控制 | 中高 | 中 |
| Rate Limiting | 防滥用、DDoS | 中 | 低 |
| WAF（Web 应用防火墙） | 综合防护 | 中 | 中高 |
二、认证（Authentication）
认证用于验证用户身份，确保 API 调用者是谁。以下介绍主流认证方案。
2.1 JWT（JSON Web Token）
JWT 是无状态的认证方案，适合分布式系统。Token 包含用户信息、过期时间、签名，服务端验证签名即可。优点：无状态、可扩展；缺点：Token 泄露风险、难以撤销。
2.2 OAuth 2.0
OAuth 2.0 是授权框架，适合第三方登录和 API 授权。流程：授权码模式、客户端模式、密码模式等。建议：使用授权码模式（最安全），避免密码模式。
2.3 API Key
API Key 适合服务间调用、B2B 场景。优点：简单易用；缺点：Key 泄露风险。建议：Key 与 IP 白名单、签名机制结合使用。
三、授权（Authorization）
授权用于控制用户能访问哪些资源，执行哪些操作。以下介绍常见授权模型。
| 模型 | 说明 | 适用场景 | 复杂度 |
|---|---|---|---|
| RBAC（角色访问控制） | 基于角色的权限分配 | 企业内部系统、SaaS | 中 |
| ABAC（属性访问控制） | 基于属性的动态权限 | 复杂权限需求、多租户 | 高 |
| ACL（访问控制列表） | 资源级别的权限列表 | 文件系统、简单权限 | 低 |
| 权限继承 | 子资源继承父资源权限 | 层级结构、组织架构 | 中 |
3.1 RBAC 实现
RBAC 通过角色（Role）和权限（Permission）管理访问控制。用户分配角色，角色拥有权限。建议：最小权限原则（用户只获得必需权限）、角色分离（管理员与普通用户分离）。
四、限流（Rate Limiting）
限流用于防止 API 滥用和 DDoS 攻击，保护服务稳定性。以下介绍限流策略。
说明：权重基于对实际 API 安全防护效果的分析，非官方披露数据，仅供参考。
4.1 限流算法
常用限流算法：固定窗口（简单但可能突发）、滑动窗口（平滑但复杂）、令牌桶（允许突发）、漏桶（平滑输出）。建议：根据场景选择，API 网关通常使用滑动窗口或令牌桶。
4.2 限流配置
建议配置：匿名用户 10–50 次/分钟，认证用户 100–500 次/分钟，VIP 用户更高。关键接口（登录、支付）应更严格。
五、加密与数据安全
加密用于保护数据传输和存储安全，防止数据泄露。以下介绍加密实践。
| 场景 | 加密方式 | 工具/协议 | 注意事项 |
|---|---|---|---|
| 传输加密 | TLS/HTTPS | Let's Encrypt、Cloudflare | 使用 TLS 1.2+，禁用弱加密套件 |
| 存储加密 | 对称加密（AES） | AES-256、bcrypt | 密码使用 bcrypt/argon2，敏感数据 AES |
| 签名验证 | 非对称加密（RSA） | RSA、ECDSA | JWT 签名、API 请求签名 |
| 密钥管理 | 密钥轮换、密钥库 | AWS KMS、HashiCorp Vault | 定期轮换、密钥与代码分离 |
六、API 安全实施步骤
按以下步骤逐步实施，可构建安全的 API 接口：
- 启用 HTTPS：配置 TLS 证书，强制 HTTPS，禁用 HTTP。
- 实现认证：选择认证方案（JWT、OAuth），实现登录、Token 签发与验证。
- 实现授权：设计权限模型（RBAC），实现权限检查中间件。
- 配置限流：在 API 网关或应用层实现限流，防止滥用。
- 输入验证：验证所有输入参数，防止 SQL 注入、XSS 等攻击。
- 加密敏感数据：密码加密存储，敏感数据传输加密。
- 安全审计：记录安全日志，监控异常访问，定期安全扫描。
七、常见攻击与防护
API 常见攻击及防护措施：
| 攻击类型 | 原理 | 防护措施 |
|---|---|---|
| SQL 注入 | 恶意 SQL 代码注入数据库查询 | 参数化查询、ORM、输入验证 |
| XSS（跨站脚本） | 恶意脚本注入页面 | 输入转义、CSP（内容安全策略）、输出编码 |
| CSRF（跨站请求伪造） | 利用用户身份执行未授权操作 | CSRF Token、SameSite Cookie、Referer 检查 |
| DDoS | 大量请求导致服务不可用 | 限流、WAF、CDN 防护 |
| 暴力破解 | 尝试大量密码组合 | 登录限流、验证码、账户锁定 |
八、API 安全自检清单
API 上线前，可按下列项自检：
| 检查项 | 优先级 | 是/否 |
|---|---|---|
| 已启用 HTTPS，禁用 HTTP | 必须 | □ |
| 已实现认证机制（JWT/OAuth） | 必须 | □ |
| 已实现授权检查（RBAC/权限） | 必须 | □ |
| 已配置限流，防止滥用 | 必须 | □ |
| 已实现输入验证，防止注入攻击 | 必须 | □ |
| 敏感数据已加密存储和传输 | 必须 | □ |
| 已配置 CORS，限制跨域访问 | 必须 | □ |
| 已实现安全日志和监控 | 建议 | □ |
九、小结
API 安全是 Web 应用的基础保障，核心是认证、授权、限流、加密四方面。合理的安全设计可防范 80–90% 的常见攻击，保护应用和数据安全。
落地时可从启用 HTTPS、实现认证、实现授权、配置限流、输入验证、加密敏感数据、安全审计七步入手，结合自检清单逐步完善。若需要优化网站性能以提升用户体验，可参考本站《网站性能优化实践》；若需要构建 Serverless 架构以降低运维成本，可阅读《Serverless 架构实践指南》。