API key(API 密钥 / access token / secret key)不会自己消失。它会从 Git 仓库、日志、截图、客户端 bundle 里跑出来,在几小时内被 bot 扫到,几千元到几十万元的云账单、加密币挖矿、Stripe 假卡刷爆、JWT 伪造 token 跟在后面。本文 8 个真实 API key 泄露事故 + 5 个真实场景 + 7 天护身法,看完至少能避坑 80%。

30 秒总览

API key 泄露不是”会不会”的问题,是”什么时候”的问题 — GitHub 公开 repo 平均 30 秒就被 secret scanning bot 扫到,Slack 截图 24 小时内被爬虫扫到,客户端 JS bundle 用户打开 DevTools 就能读
8 个真实事故:console.log("API_KEY=" + key) 进 Sentry / commit message 含 key 永久保留 / .env 没 .gitignore / 客户端 bundle 反编译 / Slack 截图 / 离职员工保留 access / Stack Overflow 贴代码 / Docker image 含 key
5 个真实场景:AWS key 几小时被刷几千美元加密币挖矿 / Stripe key 被刷真实扣款 / OpenAI key ¥10k 账单过夜 / Slack token 仓库被克隆 / JWT 私钥泄露绕过所有认证
7 天护身法(每个 ≤ 30 分钟可完成):本地预提交 hook 自动扫 secret / GitHub 仓库启用 secret scanning / 任何 key 走环境变量 + .gitignore / IAM 用户权限最小化 / CI 流水线用临时 token / 客户端永远不放 long-lived key / 日志过滤自动 redaction
用 Piick 工具集 debug 任何跟 API key 相关的 response / JWT / URL — 所有工具 100% 本地不上传,不污染你的 audit log

8 个真实 API Key 泄露事故

事故 1:硬编码在 Git + push public repo

症状:个人项目 demo 用了 Stripe test key sk_test_xxxx,写完 git add . && git commit -m "init" && git push origin main,几个小时后邮箱收到 Stripe 风险团队邮件:「你的 account 出现异常交易」。登录一看,几小时内被刷了真实扣款给欺诈商家(虽然你说”是 test key”,但 Stripe 默认 test key 也能产生实际扣款,需要明确用 sk_test_restricted_ 限制)。

为什么:GitHub secret scanning 实时监控 — 每次 push 到 public repo,平均 30 秒内就有 bot 扫到所有高熵字符串。AWS、Stripe、Google Cloud、OpenAI 全部跟 GitHub 合作,自动检测自己的 key 格式(AKIA... / sk_live_... / AIza... / sk-...)并通过 GitHub 发 alert 给 key 拥有者。

修复:

立刻 revoke 旧 key(Stripe Dashboard / AWS IAM),生成新 key
新 key 走环境变量:process.env.STRIPE_SECRET_KEY 而不是字面量
.env 加 .gitignore(echo ".env" >> .gitignore)
GitHub 启用 secret scanning(免费,Settings → Code security and analysis → Secret scanning → Enable)
pre-commit hook 扫 secret:brew install git-secrets 或 pip install pre-commit + 配置 detect-private-key hook

真实场景:Stack Overflow 2019 年公开数据泄露 — 某开发者 post 一个 Python 脚本问问题,代码里硬编码 AWS access key,6 小时内 9600 美元加密币挖矿账单。Stack Overflow 编辑员删帖,但 key 已被 bot 永久抓取。

事故 2:commit message 含 key

症状:同事 review 代码,发现 .env 里写了 STRIPE_KEY=sk_live_xxx,你改用环境变量后 commit: feat: switch to env vars

removed hardcoded keys, now using process.env

old: sk_live_xxxxx(忘记删除 history)

你删了代码,但 git commit history 永久保留 — git log -p 任何人 clone repo 都能看到。即使你 force-push,GitHub 的 force-push protection 也可能没启用,其他人已经 clone 的本地 repo 还在。

为什么:Git 永远不会主动删除 commit。git reset --hard HEAD~1 改的是分支指针,旧 commit 对象还在 .git/objects/ 里(直到 gc 自动清理,但默认 30 天后才生效)。git push --force 把分支回滚,但已经 clone 的开发者本地 repo 不会跟着回滚。

修复:

永远不要在 commit message 里写 key(包括 PR description、issue、Slack 通知)
如果已经泄露:git filter-branch --tree-filter 'rm -f path/to/file' 或 git filter-repo(新版工具),然后全员重新 clone(旧的本地 repo 还有历史)
未来预防:pre-commit hook 扫 commit message 内容(不只扫文件)

真实场景:某 SaaS 公司工程师 2018 年在 commit message 写了 “removed prod DB password”,真实密码就在 commit message 里,密码跟公司生产 DB 用了 2 年才被发现泄露。

事故 3:`.env` 没加 `.gitignore`

症状:本地开发用 .env 存真实 key(正确做法),但第一次 git init 时没创建 .gitignore,直接 git add . — .env 也被加进去了。你 push 到 GitHub,.env 文件在 GitHub 公开仓库,key 30 秒被扫到。

为什么:新手最容易踩的坑。.env 文件放在项目根目录,如果 .gitignore 还没创建,git add . 默认会加所有未跟踪文件。GitHub Desktop、VS Code Git 图形界面的”stage all changes”按钮,默认也会包含 .env。

修复:

第一步就创建 .gitignore(项目初始化时): .env .env.* !.env.example *.pem *.key node_modules/ .DS_Store
.env.example 提交(占位,无真实 key,告诉协作者需要哪些变量)
CI 跑检测:GitHub Actions 加 gitleaks step,任何 PR 含 secret 直接 fail
本地开发用 direnv:自动加载 .env,不需要手动 export

真实场景:某 startup 创始人在 HackerNews show HN 推自己的产品,仓库里 .env 暴露了 SendGrid API key,有人用这个 key 给创始人发了 50 万封垃圾邮件(用完他的 monthly quota),创始人的 IP 邮箱被列入 spamhaus 黑名单。

事故 4:日志里 print API key

症状:debug 一个 API 调用 401 错误,你在代码里加: console.log(“Authorization:”, req.headers.Authorization) console.log(“Request:”, apiKey)

本地跑通了,忘删 console.log 就 commit。Sentry 自动收集所有 console.log 输出,所有错误日志里都有 Authorization header,Sentry 项目里有几百个团队成员都能看。

为什么:前端 debug 输出 console.log 是肌肉记忆,Node.js console.log(req.headers) 会打印完整 Authorization header。Sentry / LogRocket / Datadog / CloudWatch Logs 自动收集所有 console 输出,key 进了日志系统就扩散到所有有权限的人。

修复:

debug 时用专门的 redaction 库:debug npm 包 + redact() 函数
CI 加 lint 规则:禁止 console.log(req.headers) console.log(apiKey) console.log(token) 等模式
Sentry 配置 beforeSend hook 自动 redaction: Sentry.init with beforeSend hook: redact request.headers before sending return event; } });
日志库自动 mask 敏感字段:pino / winston 支持 redact: ['req.headers.authorization']

真实场景:某 SaaS 公司的 Sentry 项目开了 public access(为方便 support 团队看用户报错),Sentry 里有 12 万条 console.log 输出,每条都含 API key,被人 Google 搜到 Authorization: Bearer sk-... 字符串,直接拿到公司所有 Stripe charge 权限。

事故 5:错误信息含 key

症状:调用 Stripe API 失败,错误返回: StripeAPIError: Request failed with API key sk_live_xxxxx (status 401)

你 catch 错误,error.message 进了 Sentry,真实 key 在所有 500 错误的日志里。

为什么:很多 SDK 在错误信息里打印 API key(尤其 Python / Node.js 老版本 SDK),有些 SDK 的 debug mode 默认打印完整 curl 请求:curl -H "Authorization: Bearer sk_live_..."。Error message 是最容易泄露的渠道 — 因为开发者总想看”为什么报错”,打印完整 error 就把 key 带出来了。

修复:

永远不要把 error.message 直接给用户(生产环境可能含 internal info)
生产环境关闭 SDK debug mode(Stripe stripe.setEnableTelemetry(false),AWS SDK logger level 设 WARN)
Sentry beforeSend hook 扫描 message:正则 /(sk_live_|sk_test_|AKIA|AIza|ghp_|gho_)[A-Za-z0-9_-]+/ 替换成 ***REDACTED***

真实场景:某公司在 Stack Overflow 贴了一个 Python traceback,里面 requests.exceptions.SSLError: HTTPSConnectionPool(host='api.openai.com', port=443): Max retries exceeded with url: /v1/chat/completions (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:997)'))) Headers: {'Authorization': 'Bearer sk-xxxxx'} — 完整 API key 贴在 Stack Overflow 公开帖,OpenAI billing team 立刻联系作者 revoke key。

事故 6:客户端 JS / 移动 app 里

症状:前端项目用 process.env.REACT_APP_STRIPE_KEY 读 Stripe publishable key,build 之后 bundle.js 里包含这个 key。任何用户打开 DevTools → Sources → 找到 bundle.js → 搜 “sk_” → 直接拿到 key。你以为 publishable key 没事?Stripe publishable key 不能扣款,但泄露后攻击者可以做钓鱼:用你的 key 嵌入到假网站收银页面,用户输卡号被骗。

为什么:任何前端 bundle 都能被反编译。Webpack / Vite / Rollup 把 process.env.X 编译时替换为字面量,grep "sk_live" bundle.js 立刻找到。移动 app 同样:apktool 反编译 .apk、Hopper 反编译 .ipa,所有 string literal 都能找到。前端代码不算”安全边界” — 它是给所有用户的,不是”受信”环境。

修复:

前端永远只放 publishable key(Stripe publishable / Google Maps API key 等设计上可公开的)
secret key 永远走后端 — 前端 fetch 自己的后端 API,后端用 secret key 调 Stripe,前端看不到
API key 加密存后端 DB,前端需要时 fetch 后端,后端解密用
Rate limit 永远要有(防止前端 key 被滥用)

真实场景:某 SaaS 公司前端 React app 用了 Firebase API key,key 被反编译泄露,攻击者用这个 key 在 Firebase 控制台写入了 50GB 假数据到他们的 production firestore,月底账单 $40,000。

事故 7:截图 / 屏幕分享泄露

症状:debug 一个本地服务起不来,你截屏发给同事:“看看这个报错”。屏幕里有 .env 内容、终端里 STRIPE_KEY=sk_live_xxx,Slack 自动把截图存到云端,key 进了 Slack 服务器。或者你贴到 Stack Overflow 问问题,key 公开了。

为什么:Slack / Teams / Discord 都自动上传图片到 CDN,截图里的任何文字(包括代码、token、URL query string)都被 OCR 化进数据库。Stack Overflow 更直接,key 永久公开。GitHub secret scanning 还会扫 issue / PR / 评论里的图片 OCR。

修复:

debug 时不要截全屏 — 截报错区域就行,手动检查截图里有没有 key
敏感 debug 用本地窗口 + redact(macOS Sketch 的 redact 工具、Snagit 都支持)
Slack workspace 启用 Enterprise Key Management(EKM)+ 消息 retention 政策
截图发出去前 3 秒规则:重新看截图 3 秒,找敏感字段涂掉

真实场景:2023 年某创业公司 CTO 在 Twitter 贴 demo 截图,Slack 截图自动上传到 Twitter,截图里有他们 AWS root access key(他从 AWS console 复制后没清剪贴板)。攻击者 30 分钟内用这个 key 启动了 50 个 EC2 实例挖矿,账单 $85,000。CTO 公司差点倒闭。

事故 8:同事离职没轮换 key

症状:同事张三在你公司工作了 3 年,负责生产环境运维。他有 AWS IAM AdministratorAccess policy 长期 access key + GitHub organization owner 权限 + 1Password vault 中所有 key 的访问。他离职了,IT 部门只 disable 了他的 SSO 账户 + 邮箱,没 disable AWS / GitHub / 各种 SaaS 的 access key / personal access token。3 个月后,前同事发现公司产品有 bug,他用旧 key 登录 production 数据库,删了用户表(报复 + 自认为”帮公司 debug”)。

为什么:离职流程的 access 回收经常不完整。IT 部门 disable 邮箱 + SSO,但各部门各自的 SaaS access 没人专门去 disable:

AWS IAM 用户 access key — 默认不会过期
GitHub PAT / OAuth token — 默认 30 天过期但经常被 disable 检查遗漏
Slack / Stripe / Notion / Figma / Datadog — 每个都有独立的 access 控制,IT 不一定有权限 disable
1Password / LastPass — 离职后 vault 不一定立即删除用户

修复:

离职当天跑完整 access 清单(用 IAM Identity Center / Okta / Rippling 等): AWS IAM list-access-keys —user-name zhangsan GitHub: Settings → Organizations → Remove member Stripe Dashboard: Team → Remove member Notion / Figma / Slack: Team settings → Remove
强制 access key 定期轮换:aws iam create-access-key + 旧 key 90 天后自动 disable
离职流程写进 HR 系统 checklist,IT + 各部门 manager + 安全部门三方确认
离职审计日志记录”谁在什么时候撤了张三的什么 access”

真实场景:2022 年某 SaaS 公司前员工离职 2 个月后,用离职时没回收的 AWS access key 登 production S3 bucket,删了所有客户数据备份,然后勒索公司要 50 BTC。公司 2 周没发现,客户已经流失 30%。

5 个真实场景

场景 1:AWS key 泄露 → 加密币挖矿账单

个人 AWS account 暴露 access key(可能在 GitHub / 前端 / 同事 share),攻击者用你的 key 启动 EC2 GPU 实例挖矿(通常选 p3.16xlarge $24/h)。几小时到几天,账单从 $0 涨到 $5k-$50k。AWS 不会自动停机(默认),需要 IAM 配 Service Control Policy 或 Billing Alarm 限额。

步骤:

立刻去 IAM → Users → Security credentials → Delete access key(旧 key)
Create new access key,只给最小权限(IAM Policy),不用 root key
AWS Console → Billing → Budgets:设 $100 警告、$500 hard limit
CloudTrail 查 CloudTrail Event History:看过去 24h 谁用了你的 key,评估损失
启用 Piick JSON 格式化工具查 CloudTrail response 是否含敏感数据

真实建议:永远用 IAM user(不用 root)、永远最小权限、永远启 Billing Alarm。

场景 2:Stripe key 泄露 → 假卡刷爆 / 真实扣款

Stripe live key 泄露,攻击者写脚本调 Stripe Charge API,对偷来的信用卡发起真实扣款,钱进攻击者的 Stripe connected account。或者创建大量假 customer / subscription,污染你的 CRM,等你发现时数据库已经烂了。

步骤:

Stripe Dashboard → Developers → API keys → Roll(旧 live key 立即失效)
Stripe Dashboard → Logs:查过去 24h 所有可疑 charge / customer / subscription 创建记录,refund 所有欺诈 charge
启用 Stripe Radar(内置欺诈检测)+ 自定义规则
Webhook 监听 charge.succeeded + customer.created,异常阈值报警
不要忘了 webhook secret(也是 key 类,泄露后攻击者伪造 webhook)

真实建议:sk_live_ 永远只放后端 env,测试用 sk_test_,test mode 仍能扣款(真实测试卡 + 测试 merchant),不要在生产环境用 test key。

场景 3:OpenAI / Anthropic API key 泄露 → 过夜账单

LLM API key 泄露是 2024-2025 年最常见的”过夜账单”事故 — 攻击者写循环调 GPT-4 / Claude Opus,每次生成几万 token,几小时就能刷 ¥10k-¥100k。OpenAI 在 2024 年公开承认这是他们最大的 abuse vector。

步骤:

OpenAI Dashboard → API keys → Revoke(旧 key)
Usage limits → Set monthly cap(e.g., $100 软上限 + 邮件告警)
OpenAI Dashboard → Usage:看过去 24h 用量,异常时段(深夜)异常大量调用 = 泄露
OpenAI 推荐用 gpt-4o-mini 代替 gpt-4o(便宜 30 倍),严格限制 max_tokens(每请求)
启用 cached input + prompt caching(降成本)+ 多 key 轮换(按用户 / 项目)

真实建议:永远设硬上限(不是警告,是 deny 阈值),永远用最便宜的模型,永远监控 usage 异常。

场景 4:Slack / GitHub token 泄露 → 仓库被克隆 / 消息外泄

GitHub personal access token / OAuth token 泄露,攻击者clone 所有 private 仓库(包括 .git history 里的旧 key)+ 读所有 Slack 频道(特别是 #private-dev / #credentials / #prod-issues)。几个小时后公司所有 code + 内部沟通都外泄。

步骤:

GitHub Settings → Developer settings → Personal access tokens → Revoke(旧 token)
GitHub → Organization → Audit log:看过去 24h 是否有异常 clone / push
检查所有 repo 的 webhook / deploy key:可能也被添加了恶意 webhook
Slack Workspace settings → Audit logs:查过去 24h 异常 IP / 异常 user agent
启用 GitHub IP allowlist(Enterprise 用户)+ Slack Enterprise Key Management(EKM)

真实建议:GitHub PAT 永远最小 scope(不要勾 repo 全权限,只勾需要的)、有过期时间、按用途分多 token(CI 用的 token 和本地开发用的分开)。

场景 5:JWT 私钥泄露 → 伪造 token 绕过认证

JWT 用 RS256(非对称)时,私钥(private.pem / JWT_SECRET)泄露 = 攻击者可以签发任意 token,绕过所有认证。如果用 HS256(对称),secret 泄露 = 同样的灾难。

步骤:

立刻轮换 JWT_SECRET(HS256)或重新生成 key pair(RS256)
所有现有 token 失效 — 用户强制重新登录(短期 UX 代价,但安全必需)
审计 token 签发日志:看过去 24h 是否有异常 token 签发(攻击者可能已经签发了 admin token)
所有下游 API verify 失败的安全兜底:验证 token 是否在 revoke 列表中(revoked token blacklist)
用 Piick JWT 解码器本地解码可疑 token 检查 claims(数据不上传)

真实建议:JWT secret 永远放后端 .env,永远不上 git、永远不打印到日志,rotation script 必须 24 小时内能完成(参考 Auth0 / Clerk 的 SDK)。

7 天护身法

第 1 天:本地 pre-commit hook 自动扫 secret

30 分钟搞定。安装 gitleaks 或 git-secrets,配置 pre-commit hook: brew install gitleaks gitleaks detect —source . # 手动扫一次现有 repo

加 pre-commit hook:

write hook script (see gitleaks docs): protect —staged —verbose

chmod +x .git/hooks/pre-commit

或者用 pre-commit(Python,跨平台): pip install pre-commit

configure .pre-commit-config.yaml with gitleaks hooks

then: pre-commit install

永远不要跳过 pre-commit(除非紧急 hotfix,事后必须 retroactive 扫)。

第 2 天:GitHub 仓库启用 Secret Scanning

5 分钟搞定。GitHub 对 public repo 免费,private repo 在 GitHub Advanced Security 也免费(2023 年起)。

Settings → Code security and analysis → Secret scanning → Enable
Push protection → Enable(push 时实时拦截)
Push protection for yourself(个人设置)和 organization(全公司)

效果:任何 commit 含 AWS / Stripe / GitHub 等已知格式 key,push 直接被拒绝。即使已泄露,GitHub 自动发邮件给你 + 给 key 颁发商发 alert(AWS / Stripe 会主动 revoke)。

第 3 天:所有 key 走环境变量 + `.gitignore`

半天搞定(迁移现有代码)。步骤:

创建 .env.example(占位,无真实 key,提交到 git): STRIPE_SECRET_KEY=sk_test_xxxxx DATABASE_URL=postgres://user:pass@host:5432/db OPENAI_API_KEY=sk-xxxxx
创建 .gitignore(在项目根目录): .env .env.* !.env.example
本地开发用 direnv / dotenv 自动加载:echo "dotenv" >> ~/.bashrc(或直接 node --env-file=.env)
CI 用 GitHub Actions secrets + OIDC(短期 secret,长期用 IAM role assume)
部署平台用原生 secrets 管理:Vercel / Netlify / Cloudflare 都支持 env vars + encrypted secrets

永远不在代码里写 const key = "sk_..." — 永远 const key = process.env.STRIPE_SECRET_KEY。

第 4 天:IAM 权限最小化

1-2 天搞定(审计现有 IAM 用户)。核心原则:每个用户 / 服务只用最小权限,需要时再申请。

删除 root access key(用 root 登录 web console,但永远不创建 root access key)
每个应用一个 IAM user / role,给最小 policy(JSON policy)
跨服务用 IAM Role assume,不共享 access key
启用 CloudTrail + IAM Access Analyzer(自动检测过度授权)
定期 90 天 review IAM 用户(用 aws iam generate-credential-report)

第 5 天:CI 流水线用临时 token / OIDC

半天搞定。CI 永远不要用长期 access key — 用 OIDC federation(GitHub Actions → AWS / GCP / Azure assume role):

GitHub Actions workflow

uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/github-actions-role aws-region: us-east-1

优势:GitHub 仓库被攻破,攻击者拿不到长期 key,只有 1 小时过期的 session token。AWS / GCP / Azure 全部原生支持 OIDC federation。

第 6 天:客户端永远不放 long-lived key

开发流程规则:

前端 / 移动 app 永远只用 publishable key(设计上可公开)
API 路由必须走你自己的后端,后端用 secret key 调上游服务
任何敏感操作必须有后端代理(用户登录、支付、admin 操作)
API key 加密存后端 DB,前端 fetch 时后端解密用,不用前端直传 key

永远不要bundle.js 里出现 sk_live_ AKIA AIza ghp_ gho_ secret 等高熵字符串。

第 7 天:日志过滤 + 监控告警

1 天搞定:

Sentry / LogRocket beforeSend hook 自动 redact 正则匹配 API key 格式
日志库配置 redact 字段:pino redact: ['req.headers.authorization', 'req.headers.cookie']
Billing alarm + 使用量监控: AWS: Budgets + CloudWatch alarm on EstimatedCharges Stripe: Radar rules + email notification on charge > $X OpenAI: Usage limit $100 + email on 80% reached
异常 IP / User-Agent 报警:CloudFront / Cloudflare WAF 检测异常地区 / 异常 client

工具选型决策

选项 A:商业 secrets management 平台(AWS Secrets Manager / HashiCorp Vault / 1Password CLI)

适合:中大型团队 / 多云 / 严格合规要求(金融、医疗)。

优点:统一管理、自动 rotation、audit log、RBAC、加密静态和传输。缺点:价格高(Vault $20/user/月起,AWS Secrets Manager $0.40/secret/月)、学习曲线陡、过度工程对小项目。

选项 B:.env + direnv + 1Password + CI OIDC(本方案)

适合:个人 / 小团队 / startup / MVP。

优点:零成本、5 分钟上手、标准工具链、足够安全(配合 gitignore + pre-commit + OIDC)。缺点:manual rotation、没有 audit log、密码靠人记。95% 的项目应该从这里开始,scale up 再换 Vault。

选项 C:Piick 工具集做 key 安全 audit

适合:任何规模的 debug / audit 场景。

所有 Piick 工具 100% 本地不上传,特别适合审计可疑 token / 调试 API 响应:

JWT 解码器(同 doc cluster):本地解码可疑 JWT 看 claims,确认是否伪造
JSON 格式化工具:本地 beautify API response,看是否含敏感字段泄漏
URL 编码解码器:本地解码 OAuth redirect URL,看 state / code / access_token 是否在 URL 里泄露
JSON 格式化 + JWT 解码:组合用,验证 token 是真的从 IdP 签发还是伪造

决策树:

个人 / 小团队 / MVP → 选项 B(.env + direnv + 1Password + OIDC),用 Piick 做 debug
中大型 / 多云 / 严格合规 → 选项 A(Vault / Secrets Manager),用 Piick 做临时 debug
任何审计场景(怀疑泄露) → 第一时间用 Piick 本地检查,不要上传到任何第三方

API key 不会自己消失:8 个真实泄露事故 + 5 个真实场景 + Piick 工具 7 天护身法

30 秒总览

8 个真实 API Key 泄露事故

事故 1:硬编码在 Git + push public repo

事故 2:commit message 含 key

事故 3:`.env` 没加 `.gitignore`

事故 4:日志里 print API key

事故 5:错误信息含 key

事故 6:客户端 JS / 移动 app 里

事故 7:截图 / 屏幕分享泄露

事故 8:同事离职没轮换 key

5 个真实场景

场景 1:AWS key 泄露 → 加密币挖矿账单

场景 2:Stripe key 泄露 → 假卡刷爆 / 真实扣款

场景 3:OpenAI / Anthropic API key 泄露 → 过夜账单

场景 4:Slack / GitHub token 泄露 → 仓库被克隆 / 消息外泄

场景 5:JWT 私钥泄露 → 伪造 token 绕过认证

7 天护身法

第 1 天:本地 pre-commit hook 自动扫 secret

加 pre-commit hook:

write hook script (see gitleaks docs): protect —staged —verbose

chmod +x .git/hooks/pre-commit

configure .pre-commit-config.yaml with gitleaks hooks

then: pre-commit install

第 2 天:GitHub 仓库启用 Secret Scanning

第 3 天:所有 key 走环境变量 + `.gitignore`

第 4 天:IAM 权限最小化

第 5 天:CI 流水线用临时 token / OIDC

GitHub Actions workflow

第 6 天:客户端永远不放 long-lived key

第 7 天:日志过滤 + 监控告警

工具选型决策

选项 A:商业 secrets management 平台(AWS Secrets Manager / HashiCorp Vault / 1Password CLI)

选项 B:.env + direnv + 1Password + CI OIDC(本方案)

选项 C:Piick 工具集做 key 安全 audit

推荐做法

30 秒总览

8 个真实 API Key 泄露事故

事故 1:硬编码在 Git + push public repo

事故 2:commit message 含 key

事故 3:.env 没加 .gitignore

事故 4:日志里 print API key

事故 5:错误信息含 key

事故 6:客户端 JS / 移动 app 里

事故 7:截图 / 屏幕分享泄露

事故 8:同事离职没轮换 key

5 个真实场景

场景 1:AWS key 泄露 → 加密币挖矿账单

场景 2:Stripe key 泄露 → 假卡刷爆 / 真实扣款

场景 3:OpenAI / Anthropic API key 泄露 → 过夜账单

场景 4:Slack / GitHub token 泄露 → 仓库被克隆 / 消息外泄

场景 5:JWT 私钥泄露 → 伪造 token 绕过认证

7 天护身法

第 1 天:本地 pre-commit hook 自动扫 secret

加 pre-commit hook:

write hook script (see gitleaks docs): protect —staged —verbose

chmod +x .git/hooks/pre-commit

configure .pre-commit-config.yaml with gitleaks hooks

then: pre-commit install

第 2 天:GitHub 仓库启用 Secret Scanning

第 3 天:所有 key 走环境变量 + .gitignore

第 4 天:IAM 权限最小化

第 5 天:CI 流水线用临时 token / OIDC

GitHub Actions workflow

第 6 天:客户端永远不放 long-lived key

第 7 天:日志过滤 + 监控告警

工具选型决策

选项 A:商业 secrets management 平台(AWS Secrets Manager / HashiCorp Vault / 1Password CLI)

选项 B:.env + direnv + 1Password + CI OIDC(本方案)

选项 C:Piick 工具集做 key 安全 audit

推荐做法

事故 3:`.env` 没加 `.gitignore`

第 3 天:所有 key 走环境变量 + `.gitignore`