Supabase RLS 安全最佳实践：从 AI 生成代码到生产级防护

它解决什么问题 / 适用场景

Supabase 的 Row Level Security（RLS）是保护多租户数据隔离的核心机制，但 AI 编码工具（如 Cursor、Lovable、Bolt、v0）生成的 Supabase 代码中，RLS 策略往往存在严重安全漏洞。最常见的问题包括：

• 策略中使用 USING(true) 导致所有用户可访问任意数据
• service_role 密钥意外暴露在前端代码中
• 缺少必要的 WITH CHECK 子句导致数据篡改

本指南专门解决这些由 AI 工具引入的安全隐患，适用于：

• 多租户 SaaS 应用的数据隔离
• 用户个人数据管理（如笔记、文件、设置）
• 金融、医疗等合规性要求高的场景
• 任何需要严格行级访问控制的 Supabase 项目

安装与快速上手

本方案不涉及额外安装，而是基于 Supabase 内置的 RLS 机制。你需要准备：

1. Supabase 项目：在 Supabase Dashboard 创建或已有项目
2. 项目凭证：从项目设置 → API 获取以下信息：
   • Project Ref（项目引用 ID）
   • Anon Key（匿名密钥）
   • Service Role Key（服务角色密钥）

初始化 Supabase 客户端

JAVASCRIPT
// 前端代码 - 仅使用 anon key
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'https://your_project_ref.supabase.co',
  'your_anon_key'  // 仅使用 anon key，严禁使用 service_role key
)

启用 RLS

SQL
-- 对每个需要保护的表执行
ALTER TABLE your_table_name ENABLE ROW LEVEL SECURITY;

核心配置 / 参数说明

关键环境变量

RLS 策略模板

SQL
-- 基本 SELECT 策略：用户只能读取自己的数据
CREATE POLICY "users_can_read_own_data"
ON your_table_name
FOR SELECT
TO authenticated
USING (auth.uid() = user_id);

-- INSERT 策略：用户只能插入自己的数据
CREATE POLICY "users_can_insert_own_data"
ON your_table_name
FOR INSERT
TO authenticated
WITH CHECK (auth.uid() = user_id);

-- UPDATE 策略：用户只能更新自己的数据
CREATE POLICY "users_can_update_own_data"
ON your_table_name
FOR UPDATE
TO authenticated
USING (auth.uid() = user_id)
WITH CHECK (auth.uid() = user_id);

-- DELETE 策略：用户只能删除自己的数据
CREATE POLICY "users_can_delete_own_data"
ON your_table_name
FOR DELETE
TO authenticated
USING (auth.uid() = user_id);

常见错误策略及修复

与同类方案对比

本方案的独特优势：

• 提供针对 AI 生成代码的安全审计清单
• 明确指出 USING(true) 和 service_role 密钥泄露等最危险的错误
• 完全控制策略逻辑，不受框架限制

在 AI 客户端中的集成配置

如果你使用 MCP（Model Context Protocol）服务器来自动审计 RLS 策略，可以配置以下 JSON：

JSON
{
  "mcpServers": {
    "supabase-rls-auditor": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-supabase",
        "--project-ref",
        "your_project_ref",
        "--anon-key",
        "your_anon_key",
        "--service-role-key",
        "your_service_role_key"
      ],
      "env": {
        "SUPABASE_URL": "https://your_project_ref.supabase.co",
        "SUPABASE_ANON_KEY": "your_anon_key",
        "SUPABASE_SERVICE_ROLE_KEY": "your_service_role_key"
      }
    }
  }
}

安全警告：此配置中的 SUPABASE_SERVICE_ROLE_KEY 具有最高权限，仅应在受信任的开发环境中使用，切勿提交到公开仓库。

生产环境实践与注意事项

1. 并发冲突处理

RLS 策略本身不处理并发写入冲突。对于高并发场景，需要结合数据库行锁或乐观锁：

SQL
-- 使用行锁防止并发更新
BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;
-- 执行更新操作
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

2. 存储桶 RLS 策略

Supabase 存储桶的 RLS 策略不涉及文件系统锁定。对于需要独占写入的场景，需要在应用层实现锁机制。

3. 权限控制边界

RLS 策略仅控制通过 Supabase 客户端（使用 anon key 和 JWT）的访问。以下情况会绕过所有 RLS：

• 使用 service_role 密钥
• 直接数据库连接（如通过 psql）

务必确保 service_role 密钥仅用于受信任的后端服务。

4. 网络安全补充

RLS 策略不提供网络层面的安全。应结合 Supabase 的网络限制功能（如 IP 白名单）来限制对数据库的直接访问。

5. 性能优化

复杂的 RLS 策略可能严重影响查询性能：

SQL
-- 使用 EXPLAIN ANALYZE 分析策略性能
EXPLAIN ANALYZE SELECT * FROM your_table_name WHERE user_id = auth.uid();

-- 添加必要索引
CREATE INDEX idx_your_table_user_id ON your_table_name(user_id);

6. 策略调试

RLS 策略的错误信息通常不够直观。建议：

• 在开发环境中使用 supabase 本地 CLI 进行策略测试
• 利用 Supabase 的日志功能监控被拒绝的查询

常见报错与排查

错误 1：INSERT/UPDATE 被拒绝

错误信息：new row violates row-level security policy for table "table_name"

解决方案：检查对应表的 INSERT 或 UPDATE 策略的 WITH CHECK 子句。确保 WITH CHECK 条件允许新插入或更新后的行数据。例如，如果策略要求 user_id = auth.uid()，则新行的 user_id 必须等于当前用户的 ID。

错误 2：表访问被拒绝

错误信息：permission denied for table table_name 或 relation "table_name" does not exist

解决方案：

1. 确认该表已启用 RLS：ALTER TABLE table_name ENABLE ROW LEVEL SECURITY;
2. 确认存在至少一条 SELECT 策略。如果 RLS 启用但无策略，则所有非 service_role 的请求都会被拒绝
3. 检查策略中的 TO 角色是否正确。如果策略指定了 TO authenticated，则未登录的 anon 用户将无法访问

错误 3：auth.uid() 函数不存在

错误信息：column "auth.uid" does not exist 或 function auth.uid() does not exist

解决方案：确保在 RLS 策略中正确使用了 auth.uid() 函数。该函数是 Supabase 提供的，用于获取当前认证用户的 ID。常见错误是将其写为字符串或使用了错误的命名空间。正确的用法是 auth.uid()。如果是在自定义函数或触发器中，可能需要设置 search_path 或使用 auth.uid() 的完整路径。

错误 4：service_role 密钥泄露

错误信息：在客户端代码中使用了 service_role 密钥，导致所有 RLS 策略被绕过，数据完全暴露。

解决方案：

1. 立即在 Supabase 仪表盘中轮换（rotate）service_role 和 anon 密钥
2. 检查所有前端代码、环境变量和 Git 历史，确保 service_role 密钥已被移除
3. 将前端代码中的 Supabase 客户端初始化改为仅使用 anon 密钥
4. 对于需要管理员权限的操作，应通过后端 API 或 Edge Function 进行，并在其中安全地使用 service_role 密钥

常见问题 FAQ

Q: 我的应用是使用 Cursor 生成的，它自动创建了 RLS 策略，但我发现 anon 用户可以读取所有数据。我该如何快速修复？

A: 这是最常见的问题，通常是因为策略中使用了 USING(true) 而没有指定 TO authenticated。修复步骤：

1. 找到所有使用了 USING(true) 的策略
2. 将这些策略修改为 FOR SELECT TO authenticated USING (auth.uid() = user_id) 或根据你的业务逻辑添加更具体的条件
3. 确保所有表都已启用 RLS
4. 使用 Supabase 的 SQL 编辑器或 supabase CLI 测试新策略，确保 anon 用户无法访问数据，而 authenticated 用户只能访问自己的数据

Q: 我需要在 Edge Function 中执行管理员操作（如删除用户），但不想暴露 service_role 密钥。最佳实践是什么？

A: 最佳实践是创建一个专用的、受信任的 Edge Function，它只接受来自你后端服务的请求（例如，通过一个共享的 API 密钥或 IP 白名单进行验证）。在这个 Edge Function 内部，你可以安全地使用 service_role 密钥来执行任何操作。前端永远不应该直接调用这个函数。另一种方法是，在 Edge Function 中验证调用者的 JWT，并检查该用户是否具有 admin 角色（例如，在 user_metadata 或一个单独的 roles 表中），然后使用 service_role 密钥执行操作。但这种方法仍然存在风险，因为 JWT 可能被伪造或泄露。

Q: 我的 RLS 策略在开发环境中工作正常，但在生产环境中却导致查询超时或性能极差。可能的原因是什么？

A: 性能问题通常由以下原因导致：

1. 策略中使用了复杂的子查询，例如 user_id IN (SELECT ...)。这些子查询会对每一行执行，导致全表扫描。解决方案是使用 JOIN 或 EXISTS 来重写策略
2. 策略中调用了自定义函数，这些函数可能执行了昂贵的操作
3. 缺少必要的数据库索引。例如，如果策略中经常使用 auth.uid() = user_id，则必须在 user_id 列上创建索引
4. 数据量增长后，原有的策略设计不再高效

建议使用 EXPLAIN ANALYZE 分析生产环境中的慢查询，并根据执行计划优化策略和索引。