接口是数据的入口，也是事故最常发生的地方。这份清单给自己写的接口用，全部是防御方向。

一、参数校验：不信任任何输入

  • 类型、长度、范围都校验，别只在前端做（前端只是给用户体验用的）
  • 不要直接把用户输入拼进文件名、SQL、命令里
  • 查询参数里出现数组（?id[]=1）要能安全处理，而不是报 500
  • 所有输出到 HTML 的地方做转义，富文本单独走白名单

二、鉴权与越权：最容易被忽略的一条

很多人只验证"登录了吗"，忘了验证"这条数据是不是他的"。改个 ID 就能看别人的订单，这类问题至今仍常见。

// 反例：只判断登录
if (is_login()) { echo get_order($_GET['id']); }

// 正确：数据归属也判断
$order = get_order($_GET['id']);
if (!$order || $order['user_id'] !== current_user_id()) {
    http_response_code(404);
    exit;
}

三、限流：让接口在被打的时候还能用

  • 按 IP、按账号、按接口分别限流（只按 IP 容易误伤共用出口的用户）
  • 验证码、登录、发信这类接口单独定更严的阈值
  • 返回 429 并带上"多久之后重试"，前端才好提示

四、日志：出问题时的唯一证据

  • 记录时间、IP、账号、动作、结果，不记密码和完整令牌
  • 敏感字段脱敏（邮箱打码、长数字打码）
  • 日志按天分割并设定保留期，别让它把磁盘写满

五、几条小习惯

  • 给用户看的错误和写进日志的错误分开 —— 别把数据库报错回给前端
  • 接口只允许需要的 HTTP 方法
  • 涉及状态的写操作加 CSRF 或同源校验