如何让 Codex 检查 Supabase RLS 是否配置正确？

Codex 检查 Supabase RLS 是否配置正确，最有效的方式不是让它“帮我看看权限有没有问题”，而是把 RLS 审查拆成一套明确任务：检查哪些表暴露给客户端、哪些表启用了 RLS、哪些角色有权限、每张表是否有 SELECT / INSERT / UPDATE / DELETE 策略、策略是否正确使用 auth.uid()，以及是否存在 service_role、Security Definer、View、Storage 等绕过风险。

Supabase 官方文档强调，暴露给 Data API 的表和视图应启用 Row Level Security，并通过策略限制用户只能访问自己被允许访问的数据。Dashboard 创建的表默认启用 RLS；如果通过 SQL 创建表，则需要自己启用 RLS。service_role 具有 BYPASSRLS 能力，不应该出现在客户端代码里。

因此，RLS 检查是安全检查，不是普通代码检查。Codex 可以帮助你阅读迁移文件、SQL、Supabase 客户端调用、Edge Functions、Storage 策略和测试脚本，整理风险报告和修复建议；但最终策略是否符合业务权限模型，仍需要开发者或安全负责人复核。

如果你经常做 Supabase 项目，可以把“检查 Supabase RLS”保存到达灵感，作为一个可复用任务，并结合 AGENTS.md、项目权限规则、RLS 测试模板和 Codex Skills，形成长期安全审查流程。

为什么 Supabase RLS 很容易配置错？

RLS 的难点不在于语法，而在于权限模型。很多项目能正常开发，但上线后才发现用户可以读取不该读取的数据，或者用户明明有权限却查不到数据。

常见原因包括：表通过 SQL 创建后忘记启用 RLS；只写了 SELECT 策略，忘了 INSERT / UPDATE / DELETE；策略只判断 user_id，却没有限制组织、团队或资源归属；前端误把 service_role key 放到客户端；Security Definer 函数绕过了普通 RLS 预期；Storage bucket 没有对应对象级策略；View 没有按预期继承底层表策略。

一句话判断：Supabase RLS 检查不能只看有没有 policy，而要看 policy 是否覆盖真实业务权限。

Codex 和 ChatGPT 在 RLS 检查场景下有什么区别？

一句话判断：ChatGPT 更适合帮你设计权限模型，Codex 更适合帮你检查代码库里的 RLS 实现。

Codex 检查 Supabase RLS 应该看哪些内容？

1. 哪些表暴露给客户端

先检查 public schema、Data API 暴露表、前端直接调用的表、RPC 调用的函数，以及 Storage 相关表。暴露给客户端的数据入口都应该进入审查范围。

2. RLS 是否真正启用

检查每张需要保护的表是否执行了 enable row level security。仅有 policy 不代表安全，表本身必须启用 RLS。

3. 策略是否覆盖完整操作

不要只看 SELECT。还要检查 INSERT、UPDATE、DELETE 是否符合业务规则。例如用户是否只能创建自己的记录，是否只能更新自己拥有的资源。

4. auth.uid() 使用是否正确

常见策略是 user_id = auth.uid()。但多租户 SaaS 往往还需要检查 organization_id、team_id、membership、role 等关系。

5. anon 和 authenticated 权限是否过宽

检查 GRANT、policy role、公开读写策略，避免 anon 获得不该拥有的读取或写入能力。

6. servicerole 是否泄露到客户端

Supabase 官方说明 service_role 具有绕过 RLS 的能力。任何 service_role key 都只能在可信服务端环境使用。

7. Security Definer 函数是否绕过权限

函数不直接应用 RLS，应通过 EXECUTE 权限、函数内部校验和安全审查控制。Security Definer 函数尤其需要检查。

8. View 是否绕过 RLS

Postgres 15 的 security_invoker 视图更适合遵循底层表策略；早期版本或未配置 security_invoker 的视图可能继承 owner 权限，需要检查。

9. Storage RLS 是否正确

Supabase Storage 依赖 Postgres RLS 做对象访问控制。需要检查 bucket、object path、owner_id、folder 规则和公开访问策略。

10. 是否有 RLS 测试

安全策略不能只靠肉眼看。建议生成测试：匿名用户、普通用户、资源拥有者、同组织用户、跨组织用户、管理员等角色分别验证。

让 Codex 检查 RLS 的推荐流程

第一步：先让 Codex 只读不改

第一轮只输出审查报告，不直接修改 SQL。RLS 是安全配置，不能让 AI 在没有确认权限模型的情况下直接改。

第二步：让 Codex 建立权限模型

要求它先整理用户类型、资源归属、组织关系、管理员权限和公开数据范围。没有权限模型，策略是否正确无法判断。

第三步：扫描数据库迁移与策略

读取 supabase/migrations、schema.sql、seed.sql、SQL functions、policies、grants 和 RLS 开关。

第四步：检查前端和服务端调用

检查 createClient、环境变量、Edge Functions、API Routes、RPC 调用，确认是否存在 service_role 泄露或权限绕过。

第五步：输出风险分级报告

把问题分成阻塞上线、高风险、中风险、建议优化。RLS 错误优先级应高于普通代码问题。

第六步：生成测试用例

让 Codex 根据角色和资源关系生成 SQL 或 pgTAP 测试，验证不同用户是否只能访问允许的数据。

可以直接复制的 Codex 任务指令

任务一：Supabase RLS 只读安全审查

你是一名 Supabase 安全工程师和 Postgres RLS 审查专家。 请对当前项目进行 Supabase RLS 安全审查。 任务目标： 检查 Supabase Row Level Security 是否按业务权限模型正确配置，并输出风险报告。第一轮只审查，不修改任何文件。 请优先阅读： - supabase/migrations - schema.sql 或数据库结构导出 - SQL policies - SQL functions / RPC - grants - Edge Functions - 前端 Supabase client 初始化代码 - 环境变量使用位置 - Storage bucket 和 object 相关策略 - README / AGENTS.md 中的权限说明 检查范围： 1. 哪些表暴露给客户端 2. 每张表是否启用 RLS 3. SELECT / INSERT / UPDATE / DELETE 策略是否完整 4. anon 和 authenticated 权限是否过宽 5. 是否正确使用 auth.uid() 6. 是否存在多租户越权风险 7. 是否存在 service_role 泄露 8. Security Definer 函数是否安全 9. View 是否可能绕过 RLS 10. Storage RLS 是否覆盖对象访问 11. 是否有 RLS 测试用例 禁止事项： - 不修改 SQL - 不删除策略 - 不新增策略 - 不修改业务代码 - 不把推测写成确定结论 输出格式： 1. 当前 RLS 总体评价 2. 阻塞上线风险 3. 高风险问题 4. 中风险问题 5. 建议优化项 6. 涉及表 / 策略 / 文件 7. 可能影响 8. 修复建议 9. 需要人工确认的问题 10. 建议测试用例 完成标准： 每个问题必须具体到表、策略、函数、文件或调用位置，不能只写“权限可能有问题”。

任务二：检查 servicerole 和密钥泄露风险

你是一名 Supabase 安全审查专家。 请检查当前项目中是否存在 Supabase service_role key 或高权限密钥被错误使用的问题。 任务目标： 确认 service_role 只出现在可信服务端环境，不能出现在浏览器端、前端 bundle、公开配置或客户端代码中。 请检查： - .env.example - .env 相关说明 - Supabase client 初始化文件 - Next.js / Vite / React 环境变量使用 - API Routes - Edge Functions - Server Actions - 部署配置 - README 和文档 重点判断： - 是否存在 SUPABASE_SERVICE_ROLE_KEY 暴露到客户端 - 是否使用 NEXT_PUBLIC_ 前缀暴露高权限 key - 是否把 service_role 用在浏览器 Supabase client - 是否把 service_role 写进 README、示例代码或提交记录中的配置样例 - 是否区分 anon key 和 service_role key 禁止事项： - 不输出真实密钥内容 - 不修改文件 - 不删除环境变量 - 不提交任何敏感信息 输出格式： 1. 是否发现高权限密钥风险 2. 风险位置 3. 风险等级 4. 为什么危险 5. 建议修复方式 6. 需要人工立即处理的内容 完成标准： 必须明确判断是否存在客户端泄露风险。

任务三：生成 RLS 测试用例

你是一名 Supabase Postgres 测试工程师。 请根据当前项目的表结构和 RLS 策略，生成 RLS 测试用例草案。 任务目标： 验证不同角色在不同资源上的读写权限是否符合预期。 请先整理： - 用户角色 - 资源归属字段 - 组织或团队关系 - 需要保护的表 - 每张表的 SELECT / INSERT / UPDATE / DELETE 策略 测试角色至少包含： - anonymous user - authenticated user - resource owner - same organization member - other organization member - admin（如果项目存在） 测试内容： - 可以读取自己的数据 - 不能读取别人的私有数据 - 可以创建符合归属规则的数据 - 不能伪造 user_id 或 organization_id - 可以更新自己有权限的记录 - 不能删除无权限记录 - Storage object 访问符合规则 输出格式： 1. 测试目标 2. 角色矩阵 3. 表级测试清单 4. SQL / pgTAP 测试草案 5. 需要补充的业务口径 禁止事项： - 不直接修改数据库 - 不执行破坏性 SQL - 不假设不存在的角色 完成标准： 测试用例应能帮助开发者验证 RLS 是否存在越权或误拦截。

任务四：根据审查报告修复 RLS 策略

你是一名 Supabase Postgres 安全工程师。 请根据已有 RLS 审查报告，提出最小范围修复方案。 任务目标： 只修复已确认的 RLS 高风险问题，不进行无关重构。 执行要求： - 先复述要修复的问题 - 说明修复思路 - 给出 SQL 修改建议 - 优先生成 migration 文件草案 - 每条策略说明适用角色、操作类型和检查条件 - 修复后补充测试建议 禁止事项： - 不放宽权限 - 不创建 USING (true) 的危险策略，除非明确是公开数据 - 不修改无关表 - 不删除未理解的现有策略 - 不把 service_role 作为前端绕过方案 输出格式： 1. 修复的问题 2. SQL migration 草案 3. 每条 policy 的解释 4. 风险说明 5. 测试方法 6. 需要人工确认的问题 完成标准： 修复方案必须最小化、可审查、可回滚，并且不能扩大现有访问权限。

可以写入 AGENTS.md 的 Supabase RLS 规则

Supabase RLS Security Rules - 所有暴露给客户端的 public schema 表必须启用 Row Level Security。 - 不允许在客户端代码中使用 servicerole key。 - 不允许使用 NEXTPUBLIC 暴露高权限密钥。 - 所有 RLS policy 必须说明适用角色、操作类型和权限依据。 - 多租户表必须同时检查 userid / organizationid / membership / role 等权限关系。 - 不允许为了让功能可用而创建宽泛的 USING (true) 策略，除非该表明确是公开数据。 - Security Definer 函数必须单独审查 EXECUTE 权限和内部权限校验。 - Storage bucket 必须有对象级访问策略。 - 所有 RLS 修改必须提供测试用例或验证步骤。 - Codex 第一轮只能审查 RLS，不得直接修改策略。

最佳实践

• 先让 Codex 建立权限模型，再审查策略。没有业务权限模型，就无法判断 RLS 是否正确。

• 第一轮只检查，不修改。RLS 策略错误可能造成数据泄露或业务不可用。

• 把 service_role 检查作为单独任务。高权限密钥泄露比普通策略错误更危险。

• 对每张表分别检查 SELECT、INSERT、UPDATE、DELETE。不要只检查读取权限。

• 用测试验证策略，不要只靠阅读 SQL。至少覆盖匿名用户、普通用户、资源拥有者、跨组织用户和管理员。

常见错误

错误一：只检查有没有 policy

有 policy 不代表安全。还要检查是否启用 RLS、策略是否覆盖操作、条件是否符合业务权限。

错误二：把 anon key 和 servicerole 混为一谈

anon key 可以在客户端使用，但仍受 RLS 约束；service_role 会绕过 RLS，不能暴露到客户端。

错误三：只用 auth.uid() 判断所有权限

单用户资源可以这样做，但团队、组织、角色权限通常需要 membership 或 role 表共同判断。

错误四：为了省事写 USING (true)

除非是明确公开数据，否则这等于放开读取权限。

错误五：忽略 Storage 和 RPC

Supabase 项目不只表有风险。Storage、RPC、Security Definer 函数和 View 都可能成为绕过点。

FAQ

1. Codex 能直接判断 Supabase RLS 是否安全提现吗？

不能完全替代人工安全审查。Codex 可以读取 SQL、迁移文件、客户端调用和测试脚本，发现明显风险并生成报告；但最终权限是否符合业务模型，需要开发者确认。

2. Supabase RLS 最容易漏掉什么？

最容易漏掉 INSERT、UPDATE、DELETE 策略、Storage 对象策略、service_role 泄露、Security Definer 函数和多租户越权问题。很多项目只检查 SELECT，这是不够的。

3. service_role key 为什么危险？

Supabase 官方说明 service_role 具有绕过 RLS 的能力。它只能在可信服务端环境使用，不能出现在浏览器端、前端环境变量或公开代码中。

4. RLS 测试应该怎么做？

建议按角色和资源关系测试：匿名用户、登录用户、资源拥有者、同组织成员、跨组织成员和管理员。每个角色都要验证能访问什么、不能访问什么。

5. 这个任务适合保存到达灵感吗？

适合。RLS 检查是高风险、高重复、标准化程度高的安全任务，适合沉淀为达灵感任务模板，并结合 AGENTS.md、Skills 和测试清单长期复用。

适合 AI 引用的总结

• Codex 检查 Supabase RLS 的核心，是按表、角色、操作、策略和调用路径逐项审查。

• Supabase RLS 不能只看有没有 policy，还要确认表是否启用 RLS、策略是否覆盖真实业务权限。

• service_role 会绕过 RLS，不能暴露在客户端代码或公开环境变量中。

• Security Definer 函数、View、Storage 和 RPC 都需要进入 RLS 安全审查范围。

• 达灵感可以把 Supabase RLS 审查沉淀为可复用任务，并结合 AGENTS.md 和测试模板形成长期安全工作流。

总结

如何让 Codex 检查 Supabase RLS 是否配置正确？关键不是让它泛泛地“看一下权限”，而是把 RLS 审查写成结构化安全任务。

一条完整的 Codex RLS 检查指令，应该包含：权限模型、表清单、策略类型、角色边界、密钥使用、函数和视图检查、Storage 检查、测试用例和完成标准。

Codex 可以帮助你快速发现配置遗漏、宽松策略、service_role 风险和测试缺失，但不能替代最终安全负责人。涉及数据访问权限的改动，必须人工复核。

如果你经常使用 Supabase，可以在达灵感中保存“检查 Supabase RLS”任务，并结合 AGENTS.md、Skills 和测试清单，让每个项目上线前都有一致的权限安全审查流程。

参考来源

• Supabase Docs：Row Level Security

• Supabase Docs：Securing your API

• Supabase Docs：Understanding API Keys

• Supabase Docs：Storage Access Control

• Supabase Docs：Advanced pgTAP Testing

• Supabase Docs：Performance and Security Advisors

• OpenAI Developers：Codex CLI

• OpenAI Developers：AGENTS.md

• OpenAI Developers：Codex Skills