Ubuntu 上 Postman 的安全设置与最佳实践
一 安装与运行的最小权限
- 优先使用 Snap 经典模式安装，减少与系统目录的冲突并便于隔离：sudo snap install postman --classic；如需手动安装，下载 Linux 64 版本，解压至 /opt，并以普通用户运行，避免以 root 启动 GUI 应用。为便捷启动可创建桌面文件（Exec 指向解压目录下的 Postman 可执行文件），但务必确保执行权限与路径正确。以上安装方式均为 Ubuntu 常见实践。
二 传输与证书安全
- 全程使用 HTTPS，并在 Postman 设置中保持 SSL certificate verification 开启，仅对受信任的内部自签 CA 临时关闭验证。需要双向 TLS（mTLS）时，在 File > Settings > General > SSL certificate verification 区域导入客户端证书（支持 CRT/PFX 及私钥，受密码保护的证书按提示输入密码），发起请求时 Postman 会自动携带证书完成握手。
- 如需捕获浏览器或移动端流量，Postman 内置 Proxy/Interceptor 可用，但其根证书（默认位于 ~/.config/Postman/proxy/postman-proxy-ca.crt）一旦被系统或浏览器信任，会带来中间人风险。仅在需要时启用，用完即撤销信任；移动端和桌面浏览器安装该 CA 的方法与步骤需严格受控并最小暴露面。
三 代理与网络安全
- 在 Settings > Proxy 明确选择 System Proxy 或配置 Custom Proxy；两者同时开启时以 Custom Proxy 优先。通过代理路由可集中审计与管控出站流量，但同样会扩大攻击面，应确保代理服务器本身的安全与访问控制。
- 避免在生产环境或对敏感目标使用 Postman 的 Interceptor 捕获 HTTPS 流量；多数站点启用 HSTS 会导致拦截失败或不安全，且安装根证书到浏览器/系统会削弱信任链，应仅用于测试环境的受控场景。
四 凭据与敏感信息管理
- 使用 环境变量/全局变量 管理 API Key、Token、密码 等敏感信息，避免硬编码到请求或脚本；为 开发/测试/预发/生产 分别维护环境并在提交前审查变更，防止密钥泄露到代码仓库。
- 在集合的 Tests/Pre-request Script 中处理令牌时，优先使用 pm.environment.set 等受控方式更新变量，避免将明文凭据打印到控制台或日志；与 CI/CD 集成时，通过受控的变量文件或密钥管理服务注入，而非硬编码或明文传递。
五 安全测试与持续化
- 建立“安全测试集合”，覆盖常见风险：使用脚本构造 SQL 注入、XSS、未授权访问 等测试用例，并断言响应是否按预期拒绝或转义；将安全断言纳入自动化回归。
- 将 Postman 测试纳入 CI/CD（如使用 Newman）以在每次变更后自动执行安全与功能回归，并生成报告；与 OWASP ZAP 等工具联动，增强漏洞扫描与覆盖。
- 安全配置速查表：
- 传输安全：仅用 HTTPS；保持 证书校验开启；按需导入 mTLS 证书
- 代理与拦截：明确 System/Custom Proxy；拦截器与根证书仅测试环境启用
- 凭据管理：用 环境变量；禁止硬编码；CI/CD 通过受控方式注入
- 自动化：构建 安全测试集合；Newman 持续运行；与 ZAP 联动扫描
- 最小权限：以 普通用户运行；必要时用 Snap 经典模式隔离