一、环境变量与 Secret 管理：从源头杜绝凭证泄露

在团队协作中，API Key、Token、数据库密码等敏感信息被明文写入 Collection 或直接硬编码到请求参数中，是最常见也最危险的安全隐患。Postman 提供了多层防护机制来应对这一问题。

第一步，严格区分 Initial Value 与 Current Value。在 Environment 或 Global 变量中，Initial Value 会随 Collection 同步到云端和团队成员，而 Current Value 仅存储在本地。所有密钥类信息只应填写在 Current Value 中，Initial Value 留空或填入占位符如 ``。

第二步，启用 Secret 类型变量。从 Postman v10.18 起，变量类型新增了 `secret` 选项。将变量标记为 secret 后，其值在界面上默认以掩码显示，且不会被同步到 Postman 云端的 Activity Feed 中。操作路径：进入 Environment → 点击变量类型下拉框 → 选择 `secret`。

具体排查场景：如果你发现团队成员在 Postman Cloud 的 Activity Log 中能看到某个 Token 的明文值，大概率是该变量仍为 `default` 类型。立即将其切换为 `secret`，并轮换（Rotate）已暴露的凭证。

二、Postman Secret Scanner：自动检测已泄露的凭证

Postman 从 2023 年起在 Public API Network 上线了 Secret Scanner 功能，到 2025-2026 年已扩展至 Team/Enterprise Workspace 内部。该功能会自动扫描 Collection、Environment、Request 中是否包含已知格式的密钥（如 AWS Access Key、GitHub Token、Stripe Key 等，支持超过 100 种 Secret 模式）。

启用方式（需 Team 或 Enterprise 计划）：进入 Team Settings → Security → 开启 "Secret Scanner"。扫描结果会在 Security Audit Dashboard 中集中展示，包含泄露位置、Secret 类型和风险等级。

故障排查场景：某团队在 Sprint 结束后发现 Secret Scanner 报告了 3 条 AWS Access Key 泄露告警，定位到一位成员在 Pre-request Script 中直接写入了 `aws_access_key_id = "AKIA..."` 的硬编码值。处理步骤：① 在 AWS IAM 控制台立即停用并轮换该 Access Key；② 将密钥迁移到 Postman Environment 的 secret 类型变量中；③ 在 Pre-request Script 中改用 `pm.environment.get("aws_key")` 引用。整个修复过程不超过 10 分钟，但如果没有 Scanner 的主动告警，这类泄露可能数周都不会被发现。

三、权限管控与 Workspace 隔离策略

Postman 的 Workspace 分为 Personal、Team、Partner 和 Public 四种类型，安全敏感项目应严格控制 Workspace 类型和成员角色。

核心原则：最小权限。Postman 支持 Admin、Editor、Viewer 三级角色。对于包含生产环境配置的 Collection，建议仅授予核心成员 Editor 权限，其余人员设为 Viewer。操作路径：Workspace Settings → Members → 逐人调整 Role。

对于需要与外部供应商协作的场景，使用 Partner Workspace 而非直接邀请外部人员进入 Team Workspace。Partner Workspace 天然隔离了内部 Collection 和 Environment，外部成员只能访问显式共享的资源。

此外，定期审计 Workspace 成员列表同样重要。建议每季度检查一次：是否有已离职人员仍保留访问权限、是否有 Workspace 被意外设置为 Public。Enterprise 计划用户可通过 SCIM 协议对接企业 IdP（如 Okta、Azure AD），实现成员的自动化生命周期管理。

四、本地数据清理与请求历史管控

Postman 桌面客户端会在本地存储请求历史、Cookie、响应缓存等数据。在共享开发机或受监管环境中，这些残留数据可能构成合规风险。

清理请求历史：进入 History 面板 → 点击右上角垃圾桶图标 → 选择 "Clear All"。也可以在 Settings → General → 关闭 "Save Responses" 来阻止响应体被持久化存储。

清理 Cookie：进入右下角 "Cookies" 管理器 → 选择目标域名 → 逐条或批量删除。对于自动化场景，可在 Pre-request Script 中调用 `pm.cookies.jar()` 的 `clear` 方法，确保每次请求前 Cookie 状态干净。

在合规审计（如 SOC 2、ISO 27001）场景下，建议将 Postman 的数据存储路径纳入终端数据防泄漏（DLP）策略的监控范围。Postman 桌面端默认数据目录在 macOS 上为 `~/Library/Application Support/Postman`，Windows 上为 `%AppData%/Postman`。

总结

API 安全不是一次性配置，而是贯穿开发全生命周期的持续实践。从环境变量的 secret 标记、Secret Scanner 的主动检测，到 Workspace 权限隔离和本地数据清理，Postman 已经提供了相当完整的安全工具链。关键在于团队是否真正将这些能力融入日常工作流。

建议立即行动：打开你的 Postman，检查当前所有 Environment 中是否存在明文存储的密钥，将它们全部切换为 secret 类型变量。这一个动作，可能就能避免下一次凭证泄露事故。如需更深入的企业级安全方案，可访问 Postman 官网（postman.com）了解 Enterprise 计划的 SSO、审计日志和 SCIM 集成能力。

相关阅读：Postman 面向关注安全与合规的用户的使用技巧 202602，Postman 面向关注安全与合规的用户的使用技巧 202602使用技巧，Postman替代工具推荐：5款更注重数据安全的