爆雷预警16,326 个 Supabase 数据库正裸露公网快查你家的表【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase安全研究机构 UpGuard 近期发布调查结论全球有16,326 个 Supabase 数据库正处于可公开读取状态任何人无需登录、无需任何凭据就能通过 REST 接口拉取其中的表数据TechCrunch 等多家媒体跟进报道称其中相当一部分直接暴露了姓名、邮箱、手机号等个人信息。更值得警惕的是这并非 Supabase 平台的漏洞被攻破而是一系列默认权限设计 开发者配置疏忽叠加的结果——这也意味着任何正在使用 Supabase无论托管版还是自托管的团队都可能已经在不知情的情况下裸奔了数月甚至数年。本文结合 Supabase 官方仓库源码还原这 1.6 万个可读数据库是怎么被扫出来的拆解数据裸露的真实威胁并给出可立即执行的三步自检与修复方案。一、1.6 万个可读数据库是怎么被扫出来的先厘清一个关键事实这次事件里没有0day没有数据库被暴力破解。UpGuard 的切入点正是 Supabase 产品形态的两个天生公开的组成部分。第一项目 REST 端点是公网可达的。每个 Supabase 项目都会暴露形如https://project-ref.supabase.co的域名其 Data API 基于 PostgREST 构建——所有表、视图、函数都会自动映射为 REST 资源。UpGuard 的做法本质上是全网扫描这类端点再用公开渠道能拿到的密钥去探测这张表能不能读。第二anon匿名密钥本身就是设计为公开的。官方文档在 API keys 指南 里写得很直白publishable key以及旧版anonkeySafe to expose online它会被打进网页 JS 包、移动 App 安装包里任何人都能逆向提取。密钥本身不设防设防的是它背后的 Postgres 权限体系——而问题恰恰出在这里。仓库中的 Securing your API 文档 记录了一个历史遗留炸弹在已有项目上publicschema 里新建的表会自动获得SELECT、INSERT、UPDATE、DELETE全部权限分别授予anon、authenticated、service_role三个角色。这意味着什么只要开发者新建了一张表却没有手动收紧权限任何持有anonkey 的人也就是每一个访问过网站的人就拥有了这张表的完整读写能力。而更隐蔽的是第二层默认授予的权限并不会因为写了 RLS 策略而自动收回。官方 Row Level Security 文档 用一段危险警告级措辞点明A table in an exposed schema without RLS is readable and writable by any role with a grant on it. Enable RLS on every table in an exposed schema. On projects that still grantanonandauthenticatedby default, revoke those grants. Adding policies doesnt remove them.翻译过来就是在暴露的 schema 中没有启用 RLS 的表对任何持有授权的角色都是可读可写的必须对每张暴露的表启用 RLS若你的项目仍默认给anon/authenticated授权请立即撤销——添加策略并不会移除这些授权。把这两条事实串起来UpGuard 的扫描路径就完全清晰了遍历公网 Supabase 端点 → 用公开的anonkey 对常见表名users、profiles、orders…发起GET /rest/v1/table?select*→ 凡是返回 200 且带数据行、且表未启用 RLS 的项目即被标记为可读取。16,326 个数据库的规模说明这不是个别开发者的疏忽而是默认配置与文化惯性共同作用下的系统性现象。二、暴露表里的数据有多危险要评估危害先看暴露面下到底躺着什么。Supabase 的权限模型里anon角色映射所有未登录请求也就是说任何人指的不是黑客而是任何一个能打开你网站的人。对一张未启用 RLS 的表这个任何人能做什么不止是读。因为默认授权包含完整的四个 DML 权限读取批量select全表个人资料、订单、聊天记录、埋点数据一次性导出拿去撞库、钓鱼或转卖篡改update任意行把商品价格改成 0、把余额改到自己账上、给任何账号植入管理员标记删除delete清空整张表——这是最致命的一次误配置叠加一个扫描器就可能让整个业务的数据库被蒸发。很多团队的直觉是反正表里都是测试数据——但 UpGuard 的调查结果恰恰相反被标记的库中包含大量真实用户个人信息。原因也不难理解绝大多数 Supabase 项目都是从官方 Quickstart 模板起步的模板里的profiles表存的就是用户注册时的真实姓名、头像、联系方式开发者随后往里堆了业务表却很少有人回头检查 RLS 开关。还需要警惕一个次生风险授权是传染的。如果一张内部表通过视图View暴露给 API而视图基于未保护的表创建——官方文档明确指出视图默认绕过 RLSsecurity definer特性它会把手伸向本应被策略隐藏的全部行。也就是说即使主表加了策略一个疏忽的视图也能把整层防线击穿。当然也有必要说清楚责任边界。Supabase 官方在生产清单中反复强调 Shared Responsibility Model共享责任模型平台负责基础设施与默认安全能力安全顾问、警告邮件、网络隔离而每一张表是否对anon开放最终由开发者负责。这 1.6 万个库的悲剧正是平台能力完备、开发者没启用的典型样本。三、三步自检RLS 是否开启、anon key 是否裸奔、公网访问是否收敛好消息是修复路径官方早已给出完整工具链且全部能在仓库中找到源码级佐证。按以下三步走十分钟内就能完成一轮体检。第一步RLS 是否开启——最核心的一步Supabase 的 Security Advisor安全顾问会在 Dashboard 中直接标红未启用 RLS 的表如下图所示想用 SQL 亲自验证可以查询 Postgres 系统目录——RLS 状态记录在pg_class的relrowsecurity字段-- 列出 public schema 中未启用 RLS 的表高危清单 select c.relname as table_name, c.relrowsecurity as rls_enabled from pg_class c join pg_namespace n on n.oid c.relnamespace where n.nspname public and c.relkind r and c.relrowsecurity false order by c.relname;凡是被这条查询命中的表都在裸奔名单上。修复的标准动作官方 RLS 文档 给了完整范式——启用 RLS、撤销多余授权、按需最小授权、逐个操作写策略四件事缺一不可-- 1. 启用 RLS开启后未写策略前所有数据对 API 不可见 alter table public.reports enable row level security; -- 2. 撤销客户端角色的全部授权关键默认授权不会自己消失 revoke all on table public.reports from anon, authenticated; -- 3. 按最小权限原则重新授权登录用户才可管理匿名者什么都不给 grant select, insert, update, delete on table public.reports to authenticated; -- 4. 为每个操作写一条策略select 用 usinginsert/update 用 with check create policy Users can view their own reports. on public.reports for select to authenticated using ( (select auth.uid()) user_id );为了防止下张新表又裸奔仓库还提供了根治方案——用事件触发器在每张新表创建时自动启用 RLS。仓库中的rls_auto_enable()函数监听CREATE TABLE事件自动执行ALTER TABLE ... ENABLE ROW LEVEL SECURITY彻底消灭忘了开的人为因素CREATE OR REPLACE FUNCTION rls_auto_enable() RETURNS EVENT_TRIGGER LANGUAGE plpgsql SECURITY DEFINER SET search_path pg_catalog AS $$ DECLARE cmd record; BEGIN FOR cmd IN SELECT * FROM pg_event_trigger_ddl_commands() WHERE command_tag IN (CREATE TABLE, CREATE TABLE AS, SELECT INTO) AND object_type IN (table, partitioned table) LOOP IF cmd.schema_name public THEN EXECUTE format(alter table if exists %s enable row level security, cmd.object_identity); END IF; END LOOP; END; $$; CREATE EVENT TRIGGER ensure_rls ON ddl_command_end WHEN TAG IN (CREATE TABLE, CREATE TABLE AS, SELECT INTO) EXECUTE FUNCTION rls_auto_enable();最后把策略写成可验证的测试——官方推荐的supabase test db流程RLS 文档中的测试范式可以断言anon无授权、authenticated只能操作自己的行让安全不再依赖记忆而是每次部署都自动回归的资产。第二步anon key 是否裸奔——区分可公开与绝密自检要点一句话publishable/anon key 公开不可怕可怕的是它没有 RLS 兜底secret/service_role key 一旦公开就是灭顶之灾。API keys 文档 中的对应关系表写得一清二楚密钥类型能否进前端映射的 Postgres 角色绕过 RLSPublishable key含旧版anon可以设计如此anon/authenticated否Secret key含旧版service_role绝不可以service_role是BYPASSRLSservice_role角色自带BYPASSRLS属性意味着它无视你写的每一条策略。文档用醒目的危险警告强调A leaked secret key exposes all of your projects data。请立刻做两件事全局搜索代码库包括 git 历史是否出现过sb_secret_、service_role或eyJ开头的长 JWT——一个都不允许出现在前端代码、.env提交记录或 CI 日志里检查service_rolekey 是否仍在启用——官方建议项目里没人用就不需要创建任何 secret key用不到就删减少一枚核弹级凭证的存量。第三步公网访问是否收敛——从默认全开改为显式开放即便每张表都上了 RLS从纵深防御的角度暴露面依然应当收敛。仓库 Securing your API 文档 提供了三把闸刀闸刀一撤销默认授权让暴露变成 opt-in。官方正在推动平台默认行为改为新对象默认不可达但在那之前老项目需要手动执行alter default privileges for role postgres in schema public revoke select, insert, update, delete on tables from anon, authenticated, service_role; alter default privileges for role postgres in schema public revoke execute on functions from anon, authenticated, service_role;执行后新建的任何表、函数、序列都必须显式grant才会暴露——这正是最小暴露面的根基。闸刀二启用网络限制Network Restrictions。生产清单going-into-prod明确要求为数据库配置网络白名单只允许公司出口 IP 直连 Postgres把数据库连接这一层从公网剥离。闸刀三不需要就干脆关掉。如果应用只通过 Edge Functions 或后端直连访问数据直接禁用 Data API如果 API 面相对固定把业务表迁移到专用apischema让暴露面一眼可审计。写在最后16,326 这个数字是给整个 Supabase 生态以及所有后端即服务用户敲响的一记警钟托管平台替你解决了数据库运维却替不了你做访问控制决策。好在这一轮暴露几乎全部可逆——RLS 一行alter table就能开启密钥一次轮换就能重置默认权限一套revoke就能收回。现在打开你的 Dashboard跑一遍上面的 SQL看看 Security Advisor 的红点——今晚动手永远不晚。【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考