Supabase表审计列表Skill：一键盘点暴露的数据表，先摸清攻击面再谈安全
- 它是做什么的：通过 Supabase PostgREST 的 OpenAPI 模式端点，一次性枚举项目中所有对外暴露的数据库表，并列出列名、主键、风险等级。
- 它解决什么问题：很多 Supabase 项目上线后并不知道哪些表对外可见，等到发现
orders、api_keys这类敏感表可以被匿名访问时已经晚了。这个技能把“看不见的表”变成一张可审阅的清单。 - 输出很实用：给出“表清点 + 风险分级（高/中/低）+ 后续动作建议”，直接告诉你要先查哪张表。
- 过程可追溯：执行过程中会渐进写入上下文文件与审计日志，并产出证据文件，中途中断也不会丢失已发现的结论。
- 它是安全审计链条的第一环：先枚举表，再用配套技能测试实际数据读取与 RLS 策略，形成完整的 API 攻击面排查路径。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
这个技能的中文名是 Supabase表审计列表Skill，英文名为 supabase-audit-tables-list，技能 ID 为 11151。
它要解决的问题非常具体：Supabase 默认会把 public 模式下的表通过 PostgREST 暴露成一套 REST 接口，路径形如 https://[项目引用].supabase.co/rest/v1/。只要表存在于暴露的模式中、没有被显式 REVOKE、并且 PostgREST 能看见它，它就会出现在接口清单里。问题在于，绝大多数开发者从来没有认真看过这份清单——于是“哪些表对外可见”成了一个没人回答的问题，而这恰恰是攻击面的起点。
这个技能的价值就是把这个动作自动化：调用 https://[项目引用].supabase.co/rest/v1/?apikey=[anon-key] 的 OpenAPI 模式端点，把表、列、主键、风险标签一次性整理成人类可读的报告和机器可读的 JSON。
关于「一键安装」的思路，可以按下面的通用路径来理解（具体命令、入口与平台名称请以官方说明为准）：
- 准备前提：你需要在支持 AI 技能（Skill）的客户端或 Agent 环境中使用它；同时准备目标 Supabase 项目的 URL 与 Anon 密钥。技能详情中说明，如果这两个信息尚未提供，技能会自动调用相关步骤去提取，但提前准备好能减少来回确认。
- 获取技能：在技能市场或技能列表中检索技能 ID 11151 或英文名 supabase-audit-tables-list，按平台提供的一键安装入口添加（安装命令与入口地址以官方说明为准）。
- 触发验证：安装后直接对 AI 说一句「列出我的 Supabase 项目上暴露的表」。如果技能生效，你会看到以「暴露的表」为标题、包含项目域名、模式、发现表数、逐表列的格式化输出。
- 确认写入能力：再检查工作目录下是否生成了
.sb-pentest-context.json与.sb-pentest-audit.log。这两个文件存在，说明技能的执行链路是完整的。
需要说明的是，安装环节的具体命令、是否需要付费、支持哪些客户端，本文无法替代官方文档，请以官方说明为准。
该技能的主要功能和特点
- 全量表枚举：基于 PostgREST 的 OpenAPI 模式端点列出所有暴露的表，而不只是你记得的那几张。
- 列级细节：每张表会列出字段清单与主键类型（例如
id (uuid)），部分表还会标注外键关系（如user_id → auth.users）。 - 自动风险分级：按表可能承载的内容分为三档——🔴 高风险（财务、机密、认证类，如
orders、payments、api_keys、secrets）、⚠️ 中风险（用户 PII 与配置类，如users、profiles、settings）、ℹ️ 低风险（公共内容，如posts、products）。 - 给出后续动作建议：报告结尾会直接推荐下一步，例如运行
supabase-audit-tables-read测试实际数据访问、运行supabase-audit-rls验证行级安全策略，并提示先审查高风险表。 - 隐藏表探测：除了 OpenAPI 中出现的表，还会检查常见的未列出表（如
_prisma_migrations、schema_migrations、audit_log、internal_config）是否存在，并提示「存在但可能访问受限」，避免漏判。 - 模式暴露检查：除了
public，还会检查auth、storage、extensions以及自定义模式是否被意外暴露，例如custom_schema: ⚠️ 暴露 (3 表)。 - 渐进式上下文写入（强制要求）：技能明确要求「每次发现后立即」写入
.sb-pentest-context.json、「每次操作前后」记录到.sb-pentest-audit.log，而不是等全部跑完再一次性落盘。这样即使中途崩溃或超时，已经发现的表也不会丢。 - 证据留痕：会在
.sb-pentest-evidence/03-api-audit/tables/下产出tables-list.json、tables-metadata.json、openapi-schema.json，并把枚举用的 curl 命令追加到curl-commands.sh，方便复现。
和「打开 Supabase 控制台手动点一遍」相比，它强在三点：输出是结构化且带风险判断的、过程是可追溯可复现的、结论是可以直接交给下一步技能消费的。
如何使用该技能？
第 1 步：确认输入信息。 准备好目标项目的 Supabase URL 和 Anon 密钥。技能详情说明这两项如需自动提取会自行调用，但明确给出能减少中间环节。
第 2 步：发出自然语言指令。 两种最基础的用法：
- 基础版：
列出我的 Supabase 项目上暴露的表 - 详细版：
列出所有暴露的表及其列详细信息
第 3 步：阅读输出报告。 报告分为四个区块：项目信息（域名、模式、发现表数）、表清点（逐表列出列、主键、关联关系、风险标签）、摘要（总表数、高/中/低风险数量）、后续步骤。例如摘要会写成「总表数: 8 / 高风险: 2 (orders, api_keys) / 中风险: 3 (users, profiles, settings) / 低风险: 3 (posts, comments, products)」。
第 4 步：确认上下文与证据落盘。 检查 .sb-pentest-context.json 中的 tables 字段，它应当包含 count、list（每项含 name、schema、columns、primary_key、risk_level、risk_reason）以及按风险分组的 by_risk。同时确认证据目录下三个 JSON 文件已生成。
第 5 步：按建议推进审计链。 优先人工复核高风险表，然后交给 supabase-audit-tables-read 验证是否真的能读到数据，再用 supabase-audit-rls 检查策略是否生效。
第 6 步：针对问题表做处置。 技能详情给出了三类处置范式：用户表启用 RLS 并限定「用户只能查看自己的数据」；订单/支付表对财务数据实施严格 RLS，管理操作走 Edge Functions 而非公共 API；机密表考虑完全不暴露（REVOKE ALL ON TABLE api_keys FROM anon, authenticated;）或改用只暴露安全列的视图。若发现暴露面过宽，可限制模式暴露范围，例如 ALTER ROLE anon SET search_path TO public;。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| supabase-audit-tables-list（本技能） | 面向 AI 工作流的 Supabase 表暴露面枚举 | OpenAPI 模式枚举、列级信息、三级风险分级、隐藏表探测、模式暴露检查、证据与上下文落盘 | 安装技能后在对话中一句话触发，需准备 URL 与 Anon 密钥 | 上线前自查、渗透测试前期信息收集、安全审计取证 | 优势：输出结构化、带风险判断、可被后续技能直接消费；不足：RLS 状态本身标注为「未知」，需配合其他技能才能定论 |
| Supabase 控制台手动查看 | 官方可视化后台 | 浏览表结构、查看策略配置、执行 SQL | 零安装，但需登录并有项目权限 | 日常开发、单次结构确认 | 优势：官方、直观；不足：不生成风险分级，不做暴露面汇总，结果无法直接进入 AI 审计流程 |
| 直接 curl PostgREST 模式端点 | 手工命令行探测 | curl -s "$SUPABASE_URL/rest/v1/" -H "apikey: $ANON_KEY" 返回原始 OpenAPI JSON |
需要命令行基础，需自行解析大段 JSON | 快速验证单个项目 | 优势：最轻量、最可控；不足：原始 JSON 可读性差，需人工判断哪些表涉敏，无证据管理 |
| 通用 API 安全扫描器 | 面向多框架的通用安全扫描 | 接口发现、鉴权测试、漏洞规则匹配 | 部署与配置成本较高，常需授权与目标清单 | 企业级安全评估、合规检查 | 优势：覆盖面广；不足：对 Supabase/PostgREST 的语义理解不如专用技能细，输出偏通用漏洞项而非数据模型风险 |
选型建议：只想知道「有哪些表」，curl 就够；想顺手拿到风险排序和可追溯证据，用本技能；需要覆盖 Supabase 之外的资产时，再考虑通用扫描器。
该技能的典型应用场景与实际体验情况
场景一：独立开发者上线前的自查。 一位做 SaaS 的独立开发者，用 Supabase 快速搭完产品后准备上线。痛点是自己也说不清哪些表被暴露了，尤其是早期为了跑通流程临时关掉过 RLS。用这个技能跑一遍，报告直接标出 orders 为高风险、api_keys 含机密，摘要里写清高/中/低风险各几张表，于是优先处理这两张，而不是凭感觉挨个点开看。
场景二：安全工程师做攻击面梳理。 在做授权渗透测试时，第一步需要确认攻击面范围。手工 curl 拿到的 OpenAPI JSON 字段冗长，整理成报告很费时。使用技能后，输出直接按表罗列列名和主键，并在「额外发现」区块标出 audit_log: ✅ 存在但不在 OpenAPI 中，这类信息在原始 JSON 里根本看不到，却能显著影响后续测试方向。
场景三：外包项目交接验收。 接手他人 Supabase 项目时，最需要快速建立数据模型认知。技能输出的表清点天然就是一份数据模型清单，配合外键标注（如 user_id → auth.users）能快速画出表间关系，同时把「哪些表可能被匿名读到」这个隐患提前暴露给甲方。
实际体验情况：上手难度低，指令是自然语言，不需要背命令。输出的格式化文本可读性强，风险分级省去了大量人工判断。需要注意三点：一是 Anon 密钥必须正确，否则会出现「未找到表」的假阴性，此时应先检查密钥有效性、项目 URL 是否正确、API 是否在项目设置中被禁用；二是报告中的 RLS 状态被明确标为「未知」，这意味着它只是暴露面的体检，不是最终结论，必须接着跑 supabase-audit-rls；三是技能强制要求渐进式写入上下文与日志，执行时应确认 .sb-pentest-context.json 确实在过程中被持续更新，而不是只在末尾出现。
该技能能为用户带来的价值
把「不知道」变成「有清单」。 安全问题的第一步从来不是修复，而是发现。这个技能把 Supabase 表暴露面从一种模糊的感觉，变成一份带风险标签、可交付、可复现的清单。
风险优先级被前置。 传统做法是逐表排查，时间成本高且容易漏。技能直接按「财务/机密/认证 → 用户 PII/配置 → 公共内容」三档分类，并在摘要里统计高风险表数量，让有限的修复时间先花在最要紧的两三张表上。
证据可追溯，适合团队协作。 .sb-pentest-evidence/03-api-audit/tables/ 下的三类证据文件加上 curl-commands.sh 中追加的命令，任何人拿到都能重跑一遍验证结论，这在安全评审、合规检查和外包验收中价值很高。
为后续审计铺路。 结构化 JSON 上下文让 supabase-audit-tables-read、supabase-audit-rls、supabase-audit-rpc 等后续技能可以直接复用已有发现，不必重复枚举，整条审计链的边际成本大幅下降。
长期可复用的安全习惯。 一次安装，之后每次大版本上线前跑一遍，等于给项目加了一个「暴露面体检」的常规动作，把安全从一次性事件变成持续流程。
常见问题 FAQ
Q1：这个技能怎么安装？需要什么前提？ 在支持 AI 技能的环境中检索技能 ID 11151 或英文名 supabase-audit-tables-list，通过平台的一键安装入口添加即可（具体安装命令与入口以官方说明为准）。使用前建议准备好 Supabase 项目 URL 与 Anon 密钥；技能详情说明这两项如需可自动提取。
Q2：它是收费的吗？ 技能本身的功能描述中不涉及定价信息，是否收费、如何计费取决于所在技能平台的政策，请以官方说明为准。可以确定的是，它执行的是对你自己项目 PostgREST 模式端点的查询，不额外引入第三方服务成本。
Q3：它会不会修改我的数据库？
从技能描述看，它的核心动作是通过 GET https://[项目引用].supabase.co/rest/v1/?apikey=[anon-key] 读取 OpenAPI 模式来做枚举，属于发现类操作；对数据的实际访问测试被明确交给后续的 supabase-audit-tables-read 技能。报告中也只给出 SQL 建议（如启用 RLS、创建策略），是否执行由你决定。
Q4：报告显示「RLS 状态: 未知」，是不是技能不够强？
不是。这是职责划分：本技能负责回答「有哪些表暴露了」，RLS 是否生效需要 supabase-audit-rls 来验证。报告结尾的后续步骤已经明确写了这一点，按链条依次执行即可拿到完整结论。
Q5：适合谁用？和直接手点控制台怎么选？ 适合 Supabase 项目的后端开发者、独立开发者、安全工程师和需要做交接验收的技术负责人。如果只是临时确认某张表的结构，控制台或一行 curl 更快；如果你需要一份带风险分级、可归档、可被后续自动化流程复用的暴露面清单，这个技能更省时间。