Postman 实战｜API 安全威胁与防护实践

接口暴露在网络上，攻击面比页面大得多。这篇梳理最常见的 API 威胁，并给出可落地的防护手段——这些也正是你写测试时要重点验证的点。

① 是什么

API 安全关注：谁能调（认证授权）、传什么（注入/篡改）、是否加密（传输）、扛不扛造（DDoS）。常见威胁包括注入、认证缺陷、明文通信、敏感数据泄露、DoS、配置错误。

② 为什么重要

• 一个 SQL 注入点可能拖走整库；一个越权漏洞让用户能看别人的订单。
• 把安全用例写进 Postman 集合，每次改动都自动回归，比事后救火便宜得多。

③ 核心概念拆解

• 注入攻击：SQL / 命令 / 代码注入。防护用参数化查询、输入校验、最小权限账号。测试时故意塞 ' OR 1=1-- 看是否被拦截。
• 认证与授权缺陷：弱密码、令牌不过期。防护用 bcrypt 哈希密码、JWT 短时令牌、基于角色的访问控制（RBAC）。
• 中间人（MITM）：明文被窃听。强制 HTTPS、校验 TLS 证书、必要时用客户端证书。
• 参数篡改：改 URL/Body 越权。防护做输入校验、用参数化查询、不在 URL 放敏感数据、做访问控制。
• DDoS：限流（Rate Limiting）、IP 黑白名单、CDN、自动响应与预案。

④ 常见误区

• 误区 1：内网接口不用 HTTPS。内网也可能被嗅探，全链路加密更稳。
• 误区 2：JWT 不设过期。拿到就能永久用，泄露即失控。
• 误区 3：限流只防外网。内部批处理脚本也可能打挂服务。

⑤ 一句话小结

API 安全 = 验身份、防注入、加密传、限滥用；把这些写成 Postman 安全用例，改动即回归。

下一篇：OAuth 2.1 实战：PKCE 与令牌安全

参考来源：Mastering Postman, Second Edition（本文为原创讲解，非转载原文）