为什么API测试脚本必须重视安全

很多开发者把Postman当作简单的接口调试工具，手动填入Token、明文存储密钥、忽略响应中的敏感信息泄露。这种做法在个人调试阶段问题不大，但一旦进入团队协作或CI/CD集成，安全隐患会被迅速放大——共享的Collection中硬编码的API Key、日志里暴露的用户手机号、过期未清理的认证凭据，每一项都可能成为合规审计的扣分点。

Postman相关配图

Postman从v10版本开始强化了Vault功能和脚本沙箱的安全边界，脚本运行环境基于Node.js沙箱（当前Postman Desktop v11.x使用的脚本引擎支持ES6语法），这意味着你可以在Pre-request Script和Tests中编写相当复杂的安全逻辑。这篇Postman脚本编写指南的核心目标，就是把这些能力用在最该用的地方：认证流程自动化、敏感数据保护、以及权限边界校验。

Pre-request Script：动态认证与密钥保护

Pre-request Script在每次请求发送前执行，是处理认证逻辑的最佳位置。一个典型的安全场景是OAuth 2.0的Token自动刷新——避免团队成员手动复制Token并将其粘贴到共享环境变量中。

Postman相关配图

以下脚本实现了Token过期自动刷新，且全程不暴露client_secret：

```javascript // Pre-request Script: 自动刷新OAuth Token const tokenExpiry = pm.environment.get("token_expiry"); const currentTime = Math.floor(Date.now() / 1000);

if (!tokenExpiry || currentTime >= tokenExpiry - 60) { const clientId = pm.vault.get("oauth_client_id"); const clientSecret = pm.vault.get("oauth_client_secret");

pm.sendRequest({ url: pm.environment.get("auth_server") + "/oauth/token", method: "POST", header: { "Content-Type": "application/x-www-form-urlencoded" }, body: { mode: "urlencoded", urlencoded: [ { key: "grant_type", value: "client_credentials" }, { key: "client_id", value: clientId }, { key: "client_secret", value: clientSecret } ] } }, function (err, res) { if (err) { console.error("Token刷新失败:", err); return; } const jsonRes = res.json(); pm.environment.set("access_token", jsonRes.access_token); pm.environment.set("token_expiry", currentTime + jsonRes.expires_in); }); } ```

关键安全细节：client_id和client_secret从Postman Vault读取而非环境变量，Vault中的值不会随Collection导出，也不会同步到团队工作区的明文存储中。如果你的团队仍在用Environment存储密钥，这是最值得优先改造的一环。

故障排查场景：当脚本执行后请求仍返回401时，打开Postman Console（快捷键Ctrl+Alt+C / Cmd+Alt+C），检查两个点：一是pm.sendRequest的回调是否触发了err分支，二是token_expiry的时间戳是否因时区问题导致判断异常。常见的坑是服务端返回的expires_in单位是秒，但本地计算时混入了毫秒级时间戳。

Tests脚本：响应数据脱敏与合规校验

Tests脚本在收到响应后执行，除了常规的状态码断言，更重要的安全用途是校验响应中是否泄露了不该暴露的敏感信息。

Postman相关配图

以下脚本检测响应体中是否包含手机号、身份证号等敏感字段的明文数据：

```javascript // Tests: 敏感数据泄露检测 pm.test("响应中不包含明文手机号", function () { const body = pm.response.text(); const phonePattern = /1[3-9]\d{9}/g; const matches = body.match(phonePattern); pm.expect(matches, "检测到疑似明文手机号: " + (matches || []).join(", ")).to.be.null; });

pm.test("响应中不包含明文身份证号", function () { const body = pm.response.text(); const idPattern = /\d{17}[\dXx]/g; const matches = body.match(idPattern); pm.expect(matches, "检测到疑似明文身份证号").to.be.null; });

pm.test("认证Token未在响应体中回显", function () { const body = pm.response.text(); const token = pm.environment.get("access_token"); if (token) { pm.expect(body).to.not.include(token); } }); ```

把这组Tests挂载到Collection级别，整个集合下的所有请求都会自动执行敏感数据检测，无需逐个接口配置。在配合Newman（Postman的CLI运行器）集成到CI流水线时，任何一个接口返回了明文手机号都会导致构建失败，从而在上线前拦截数据泄露风险。

环境变量清理与会话安全管理

测试结束后残留在环境变量中的Token、Session ID是容易被忽视的安全盲区。尤其在共享工作区中，一个成员的测试Token可能被另一个成员的请求意外复用，导致权限越界。

在Collection的Tests（即Collection级别的后置脚本）中添加清理逻辑：

```javascript // Collection级Tests: 测试完成后清理敏感变量 if (pm.info.iteration === pm.info.iterationCount - 1) { const sensitiveKeys = ["access_token", "token_expiry", "session_id", "refresh_token"]; sensitiveKeys.forEach(function(key) { pm.environment.unset(key); console.log("已清理环境变量: " + key); }); } ```

故障排查场景：如果你发现变量清理脚本在Runner中没有生效，检查pm.info.iterationCount的值。当Runner只执行1次迭代时，iterationCount为1而iteration为0，条件 `0 === 1 - 1` 是成立的，逻辑没问题。但如果你在单个请求中测试这段脚本，pm.info.iteration可能返回undefined，导致条件永远不成立。解决方法是加一个兜底判断：

```javascript const isLastIteration = (pm.info.iterationCount) ? (pm.info.iteration === pm.info.iterationCount - 1) : true; ```

这样在非Runner环境下也能正常触发清理。

总结

安全不是API测试的附加项，而是脚本设计的基础约束。从Vault管理密钥、Pre-request Script自动化认证，到Tests层的敏感数据拦截和会话清理，Postman的脚本能力足以覆盖大多数安全合规场景。建议把本文中的敏感数据检测脚本作为团队Collection的标准配置，在Newman集成到CI/CD时强制执行。如果你还没有使用Postman Vault功能，现在就打开设置迁移你的明文密钥——这是投入最小、收益最直接的一步。访问 Postman官方文档的Scripting章节，获取更完整的API参考和安全最佳实践。

相关阅读：Postman脚本编写指南使用技巧，Postman Mock服务器教程：安全搭建与数