1. API安全概述

1.1 什么是API安全?

API安全,说白了就是保护你的API接口不被坏人利用。我经常跟团队说,API就像你家的大门——门锁好了,坏人进不来;门没锁,那什么都保不住。

API安全涵盖的范围其实挺广的:

  • 认证与授权——你是谁?你能干什么?
  • 数据加密——传输过程中数据不能被偷看
  • 输入验证——别让恶意数据混进来
  • 速率限制——防止被刷爆
  • 日志与监控——出了事能追溯

我个人习惯把API安全分成三层:传输层安全(HTTPS/TLS)、应用层安全(认证、授权、输入校验)、数据层安全(加密存储、脱敏)。这三层缺一不可。

1.2 为什么API安全重要?

你想想看,现在哪个应用不用API?前端调后端、微服务之间通信、第三方集成……API已经成了现代应用的"血管"。血管出了问题,整个系统都得瘫痪。

我在项目中遇到过好几次因为API安全问题导致的数据泄露事件。有一次,一个客户因为未对API做速率限制,被攻击者用脚本暴力枚举了用户ID,结果几万条用户信息被拖走。嗯,那场面……老板直接拍桌子了。

API安全为什么重要,我总结了几点:

  • 数据泄露成本高——GDPR罚款最高可达全球营收的4%
  • API是攻击面最大的入口——据统计,83%的Web流量来自API
  • 合规要求——PCI DSS、HIPAA、等保2.0都有明确要求
  • 业务连续性——API挂了,业务就停了

核心观点:API安全不是可选项,而是必选项。尤其是在微服务架构盛行的今天,API的数量呈指数级增长,攻击面也随之扩大。

1.3 常见API攻击类型

做API安全这些年,我见过的攻击类型五花八门。但最常见的,其实就那几类。

1.3.1 注入攻击

注入攻击是最老牌的攻击方式了。攻击者把恶意数据塞进API请求里,让后端去执行。SQL注入、NoSQL注入、命令注入、LDAP注入……花样很多。

举个例子:

// 不安全的API代码
GET /api/users?id=1 OR 1=1

// 后端直接拼接SQL
SELECT * FROM users WHERE id = 1 OR 1=1
// 结果:所有用户数据都被返回了

我曾经在一个金融项目中看到,开发人员直接把前端传过来的参数拼到SQL里。我当时就问他:"你这是在给黑客开后门吗?"后来我们强制要求所有API必须使用参数化查询或ORM框架。

1.3.2 越权攻击

越权攻击分两种:水平越权和垂直越权。

  • 水平越权——用户A看到了用户B的数据。比如你登录后修改URL里的user_id就能看到别人的订单。
  • 垂直越权——普通用户干了管理员的事。比如普通用户调用/admin/deleteUser接口。

我记得有一次做安全审计,发现一个电商平台的API,只要把请求中的role参数从"user"改成"admin",就能直接访问管理后台。这种问题,说白了就是后端没做权限校验。

避坑指南:我曾经见过一个团队,前端隐藏了管理员按钮就觉得安全了。结果攻击者直接用Postman调API,照样能删用户。记住:前端控制权限就是个笑话,真正的权限校验必须在后端做。

1.3.3 数据泄露

数据泄露往往不是因为黑客多厉害,而是API返回了太多不该返回的数据。比如:

// 返回了太多敏感字段
{
  "id": 123,
  "username": "张三",
  "password_hash": "5f4dcc3b5aa765d61d8327deb882cf99",
  "credit_card": "4111-1111-1111-1111",
  "ssn": "123-45-6789"
}

你想想看,前端只需要显示用户名,你返回密码哈希和信用卡号干嘛?这就是典型的"过度数据暴露"。我建议API设计时遵循"最小数据原则"——只返回客户端需要的数据。

1.4 OWASP API Top 10解读

OWASP API Top 10是API安全领域的"圣经"。我每年都会带着团队过一遍这个列表。来,我挑几个重点说说。

排名 风险类别 我的解读
API1 对象级别授权失效 最常见的问题。用户能访问不属于自己的资源。我在项目中遇到最多的问题就是这个。
API2 用户认证失效 认证机制有漏洞,比如弱密码、Token泄露、Session固定攻击等。
API3 对象属性级别授权失效 用户能修改不该修改的字段。比如普通用户把自己role改成admin。
API4 资源消耗无限制 没有速率限制,攻击者可以刷爆你的API。我见过一个案例,攻击者用脚本每秒请求1000次,直接把数据库打挂了。
API5 函数级别授权失效 普通用户能调用管理员接口。说白了就是权限校验没做好。
API6 批量分配 攻击者通过批量请求获取大量数据。比如用脚本遍历ID。
API7 安全配置错误 CORS配置不当、默认凭证未修改、调试接口未关闭……这些都是低级错误,但很常见。
API8 注入 前面说过了,SQL注入、命令注入等。
API9 资产管理不当 老版本API还在运行、文档泄露、影子API等。我建议定期做API资产盘点。
API10 日志与监控不足 出了安全问题发现不了,或者发现了追溯不了。没有日志,安全就是瞎子。

我的建议:别想着一次性解决所有问题。从API1和API2开始,把授权和认证做好,就能挡住80%的攻击。剩下的,慢慢来。

1.5 小结

API安全不是一蹴而就的事。它需要从设计阶段就开始考虑,贯穿开发、测试、部署、运维的全流程。我个人习惯在每次代码评审时都问一句:"这个API有没有做权限校验?有没有做输入验证?"