Supabase 暴露表数据读取与 RLS…

已列出 Supabase 暴露表并持有 anon key 时，只读测试各表可访问数据，验证 RLS 是否按预期保护敏感信息。

适用场景

解决思路

1. 对每个已暴露的 Supabase 表执行只读 SELECT 测试：请求 `GET https://[project].supabase.co/rest/v1/[table]?select=*&limit=5`，并带上 `Authorization: Bearer [anon-key]`；全程只读，不修改或删除数据。
2. 若尚未列出表，先自动调用 `supabase-audit-tables-list` 获取表清单，再逐表测试。
3. 使用 Quick 模式：对每个表取前 5 行，查询参数用 `?limit=5`。
4. 使用 Sample 模式：跨表随机采样，查询参数用 `?limit=10&order=random`。
5. 使用 Count 模式：只获取行数而不取数据，发送 `HEAD` 请求。
6. 按需执行基本读取测试：对暴露表执行读取并判断访问结果。
7. 按需执行 Quick Count Only：统计所有表中可访问行数，不检索数据。
8. 按需只测试指定表，例如对 `users` 表执行 `Test read access on the users table`。
9. 按响应和可访问数据评估严重级别：敏感数据可访问为 🔴 P0 DATA EXPOSED；比预期更多但非关键为 🟠 P1 PARTIAL ACCESS；可访问但低风险为 🟡 P2 UNEXPECTED；RLS 正确阻止为 ✅ BLOCKED；公开数据且访问适当为 ✅ EXPECTED。
10. 识别并分类敏感数据：PII（email、phone、name、address）暴露为 P0；Financial（amount、total、card、payment）暴露为 P0；Secrets（key、secret、token、password）暴露为 P0；Auth（user_id、session、jwt）暴露为 P1；Metadata（created_at、updated_at）暴露为 P2。
11. 生成 `DATA ACCESS TEST RESULTS` 输出：包含 Test Mode、Tables Tested、按表结果（Status、Rows Retrieved、Sample Data、Finding/Note）、Summary（P0/P1/Blocked/Expected 数量、Total Rows Accessible）和 Immediate Actions。
12. 将结果写入 `.sb-pentest-context.json` 的 `data_access` 对象：包含 timestamp、tables_tested、summary（p0_exposed、p1_partial、blocked、expected）、results（table、status、severity、rows_accessible、sensitive_columns、sensitive_data_types、finding、sample_redacted）和 total_rows_accessible。
13. 将审计日志写入 `.sb-pentest-audit.log`：记录 `READ_TEST_START tables=8`、每个表的 `READ_TEST table=... status=... rows=... severity=...`、以及 `READ_TEST_COMPLETE exposed=4 blocked=2`。
14. 执行渐进式文件更新：每个表测试前先写 `.sb-pentest-audit.log`，每个表测试后立即用结果更新 `.sb-pentest-context.json`，每个发现后把严重级别写入 `.sb-pentest-audit.log`；不要等全部完成再批量写入。
15. 若 `.sb-pentest-context.json` 或 `.sb-pentest-audit.log` 不存在，先创建它们再写入；确保技能中断、崩溃或超时前所有已得发现均已保存。
16. 创建证据目录 `.sb-pentest-evidence/03-api-audit/data-samples/`。
17. 为每个可访问表创建 `data-samples/[table]-sample.json` 证据文件，字段包括 evidence_id、timestamp、category、type、severity、finding_id、table、request（method、url、headers、curl_command）、response（status、headers、content-range、total_rows、sample_data、data_redacted）和 analysis（severity、pii_exposed、total_records_accessible、authentication_required）；样本数据中的敏感值需打码/redact。
18. 为每个被阻止的表创建 `data-samples/[table]-blocked.json` 证据文件，字段包括 evidence_id、timestamp、table、severity、response（status 403、body message）和 analysis（rls_working、access_blocked）。
19. 将数据访问测试命令追加到 `curl-commands.sh`：例如 `curl -s "$SUPABASE_URL/rest/v1/users?select=*&limit=5" -H "apikey: $ANON_KEY" -H "Authorization: Bearer $ANON_KEY"`，以及被阻止表的同类命令。
20. 对用户表实施修复：`ALTER TABLE users ENABLE ROW LEVEL SECURITY;`，创建策略 `CREATE POLICY "Users see own data" ON users FOR SELECT USING (auth.uid() = id);`，或创建 `public.users_public` 视图仅暴露 `id, avatar_url, created_at`。
21. 对设置表实施修复：`REVOKE ALL ON TABLE settings FROM anon, authenticated;`，改为仅通过 Edge Functions 使用 `supabaseAdmin` 查询，例如 `.from('settings').select('*').eq('key', 'stripe_webhook_secret').single()`。
22. 对内容表实施修复：创建策略 `CREATE POLICY "Public sees published posts" ON posts FOR SELECT USING (published = true);` 和 `CREATE POLICY "Authors see own posts" ON posts FOR SELECT USING (auth.uid() = author_id);`。
23. 处理常见问题：所有表返回 403 时，考虑 RLS 过严或 anon key 无效（安全角度可接受）；空结果但无错误时，认为 RLS 过滤了所有行、表结构暴露但无数据；大表超时时，改用 count 模式或降低 limit。
24. 按流程衔接相关技能：先用 `supabase-audit-tables-list` 列表，再用 `supabase-audit-rls` 深入检查 RLS，最后用 `supabase-report` 生成完整报告。

适用边界 · 注意事项

• 不适用于非 Supabase 项目，或目标没有暴露的 PostgREST/表 API 端点。
• 未获得对目标系统进行数据读取或安全测试授权时，不应执行主动读取。
• 需要完全避免读取任何业务数据时，应改用 Count/HEAD 或只做静态审查，而不是执行 SELECT 取样本。