API接口安全防护措施：别让数据在传输路上“裸奔”

最近帮朋友修一个小程序，发现后端API直接把用户手机号、地址全暴露在请求参数里，连个Token验证都没有。一查日志，每天有几十个陌生IP在疯狂调用注册接口——这哪是接口，简直是敞开的后门。

身份认证不能只靠“用户名+密码”

很多老系统还用明文传参做登录校验：?username=admin&password=123456。这种写法早该进博物馆了。现在主流做法是用JWT（JSON Web Token）或OAuth 2.0。每次请求带上Authorization: Bearer eyJhbGciOi...，服务端只需验签名、查有效期，不碰密码明文。

限流不是“可有可无”，而是保命线

某电商大促前没设接口限流，一个爬虫脚本每秒发200次商品详情请求，直接拖垮库存服务。简单加个Redis计数器就能拦住大部分恶意刷量：

INCR api:rate_limit:user_12345
EXPIRE api:rate_limit:user_12345 60
GET api:rate_limit:user_12345

超过100次/分钟就返回429状态码，前端弹个“操作太快，请稍后再试”就行。

敏感字段必须脱敏+加密

返回用户信息时，别图省事把身份证号、银行卡号原样吐出来。后端要主动处理：

{
  "name": "张*",
  "id_card": "110101********1234",
  "phone": "138****5678"
}

涉及支付类场景，卡号、CVV等字段必须用AES-256加密传输，密钥绝不硬编码在代码里。

别忽略HTTPS和CORS的实际配置

有些开发者以为装了SSL证书就万事大吉，结果Nginx配置漏了一行：add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;，导致HTTP回退攻击仍有风险。CORS也不能简单写Access-Control-Allow-Origin: *，尤其带Cookie时，必须指定可信域名，比如https://app.shumaoketang.com。

上周修的一个后台系统，管理员接口被嵌在恶意网页里悄悄调用，就因为CORS放得太宽。后来改成只允许自家域名+携带凭证，问题立刻消失。

日志里别留密码和token

调试时习惯性打全量请求日志？小心日志文件被人拖走。记录API调用时，自动过滤password、token、auth_key等关键词字段，或者统一用[REDACTED]占位。ELK或阿里云SLS里也可以配正则脱敏规则，一劳永逸。

接口安全不是堆功能，而是建立一层层“检查站”：进门验身份，进门限流量，进门查行李，进门记台账——每个环节松一扣，整条链就可能崩。