呱呱 数据库
检测客户端代码中泄漏的 Supabase…
在安全审计或上线前代码审查时，检测 Supabase 的 service_role（管理员）密钥是否被错误地暴露在客户端代码中。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 38/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
检测客户端代码中泄漏的 Supabase特定
解决思路
- 解码客户端代码中找到的所有 JWT，检查 payload 的 `role` 字段；若为 `service_role`（并对照 `"iss": "supabase"` 与 `"ref"` 确认）即为 P0 关键泄漏
- 搜索常见服务密钥变量名：SUPABASE_SERVICE_KEY、SUPABASE_SERVICE_ROLE_KEY、SUPABASE_ADMIN_KEY、SUPABASE_SECRET_KEY、SERVICE_ROLE_KEY
- 检查密钥是否与 anon key 一起被意外暴露，例如 `const keys = { anon: 'eyJ...', service: 'eyJ...' }`
- 逐项扫描：HTML 源码、JavaScript bundles（记录文件数与分析体积）、内联脚本块、source maps
- 对找到的密钥逐个解码确认 role：role=anon 属正常安全，role=service_role 需立即标记为 P0
- 检查 source map 是否暴露：给 JS URL 加 `.map` 后缀访问（如 `/static/js/main.js.map`），若暴露则提示可能包含密钥并建议在生产环境禁用 source maps
- 每发现一项结果就立即写入 `.sb-pentest-context.json`（在 `supabase.service_key_exposed`、`supabase.service_key_location`、`findings[]` 中记录，不要攒到最后）
- 在每个动作前后把日志写入 `.sb-pentest-audit.log`，格式为 `[TIMESTAMP] [supabase-extract-service-key] [START|CRITICAL|CONTEXT_UPDATED] ...`；文件不存在则先创建
- 若发现泄漏，在 `.sb-pentest-evidence/02-extraction/service-key-exposure/` 下创建证据文件：`location.txt`（文件路径与行号）、`decoded-payload.json`（证明是 service_role 的解码 JWT）、`code-snippet.txt`（脱敏后的代码上下文）
- 向 `timeline.md` 添加 P0 条目：时间戳、位置 [file]:[line]、影响（全库访问、RLS 绕过）、证据目录
- 修复步骤 1：立即通过 Supabase Dashboard > Settings > API > Regenerate service_role key 轮换密钥
- 修复步骤 2：从客户端源代码删除该密钥并重新部署应用
- 修复步骤 3：检查 Supabase 日志中的未授权访问，审查数据库中的异常改动以审计滥用
- 修复步骤 4：将特权操作迁移到 Edge Functions——客户端只调用 Edge Function，由 Edge Function 在服务端使用 service key
- 客户端代码只使用 anon key（`NEXT_PUBLIC_SUPABASE_ANON_KEY`，不是 `NEXT_PUBLIC_SUPABASE_SERVICE_KEY`）；特权操作通过 `supabase.functions.invoke('admin-action', { body: {...} })` 调用；Edge Function 内用 `Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')` 读取 service key
- 排查常见成因：环境变量用错（`NEXT_PUBLIC_` 前缀只应用于 anon key）、复制粘贴错误、遗留的调试代码、打包工具配置错误导致 service key 环境变量被打包进客户端
适用边界 · 注意事项
- 目标项目完全不使用 Supabase 时无需执行
- 纯服务端项目、不存在客户端代码时无适用场景