Supabase 数据暴露令 Vibe Coding 应用的安全承诺承压

尽管 Supabase 将其项目描述为默认安全，研究人员仍发现了 16,326 个包含可公开读取数据表的数据库，这让该平台正面临审视。Supabase 数据暴露调查结果将一个常见的云安全问题，与一种较新的风险来源联系起来：通过 AI 编程工具快速拼装而成的应用。

UpGuard 在超过半数暴露数据库中发现了个人信息迹象。据报道，受影响记录包括姓名、地址、电话号码、出生日期、密码、身份验证令牌、私密消息、车牌号码以及移民信息。

这并非 Supabase 内部系统遭遇的一次入侵。现有证据反而表明，问题出在因缺失或不足的访问控制而暴露的客户数据库。这一区别很重要，但并不会降低事件规模带来的担忧。

这份报告将一项技术配置失误，转化为对 vibe coding 模式的一次考验。AI 助手可以在几分钟内生成可运行的界面，并将其连接到托管数据库。但它们无法可靠地确保每位用户、每张数据表、每个角色和每项操作都获得正确的授权策略。

Supabase 数据暴露研究发现了什么

UpGuard 的核心发现并不是某一个异常粗心的应用，而是数千个独立构建的项目在重复犯下相似的安全错误。

在 2026 年 9 月的调查中，UpGuard 收集了约 30 万个显示正在使用 Supabase 的独立域名。研究人员利用 BuiltWith 和 Chrome User Experience Report 的数据识别相关网站。

随后，他们测试每个项目是否暴露了名为 users 的数据表。这个常见的表名为研究人员提供了一致的起点，无需事先了解每个应用的数据库设计。

测试产生了几种可能的响应。安全或未启用的数据库不会返回可访问数据。一些数据库会通过错误提示暴露另一张可访问的数据表。还有一些则会返回一页记录。

在这批候选项目中，UpGuard 识别出 16,326 个拥有可读取数据表的数据库。根据该公司的暴露研究，超过半数数据库包含表明存在某种个人身份信息的 schema 字段。

研究人员主要分析了数据表 schema，而非下载每一条可获取的记录。Schema 会显示列名和数据类型，因而能够表明数据表是否包含电子邮件地址、密码、电话号码或支付信息。

这一方法减少了对个人记录的不必要访问。它也意味着，16,326 这一数字并不能证明每个数据库都包含敏感信息，或攻击者此前已经复制了其中可获取的数据。

UpGuard 对部分元数据显示存在重大暴露风险的案例进行了调查。这些案例显示，一项配置错误如何会从技术债务演变为直接的个人伤害。

一家印度成人流媒体服务暴露了一张包含 65,467 人信息的数据表。据报道，其中字段涵盖身份证明文件、地址、出生日期、金融账户以及部分政府身份证号码。另一张数据表则保存了超过 10 万条涉及内容创作者的私密消息。

一家菲律宾虚拟 SIM 卡运营商暴露了超过 2,000 名用户的信息和逾 10 万条短信。大多数短信包含一次性验证码，但样本中还包括数千条网约车司机与乘客之间的普通通信。

一家美国代客泊车服务暴露了涉及超过 10 万名客户的记录。其数据库包含约 78,000 个车牌号码、约 43,000 个电子邮件地址、到访历史、小费信息和自由文本备注。

研究人员还发现了一个包含 25,000 条记录的非洲政府领事馆数据库。其中一些条目标识了可能属于脆弱群体人士的紧急安置地点。

一家加拿大移民服务机构暴露了近 5,000 条记录。UpGuard 表示，其中 884 条包含以明文存储的密码，这意味着该应用在访问控制和密码处理两方面都出现了失误。

这些案例支持了更广泛的结论，同时也暴露出不同层面的失败。公开的数据表访问打开了大门，而薄弱的应用设计则让其中内容更具危险性。

原始报道称，大多数受影响数据集似乎与美国有关。不过，UpGuard 在全球范围内发现了暴露项目，并将这一问题描述为全球性的。

地理范围的广泛性值得关注，因为 Supabase 是小型应用、新创企业和成熟组织常用的基础设施。因此，同一种反复出现的配置模式可能影响多个行业和法律辖区中彼此无关的用户。

为什么数据库可通过 Web 访问

Supabase 应用中的公开密钥不一定就是漏洞。决定性的控制因素在于该密钥被允许执行哪些操作。

Supabase 提供托管的 PostgreSQL 数据库，以及身份验证、存储和自动生成的数据接口。Web 应用可以使用可发布密钥，通过其 Data API 发起请求。

开发者有时会认为，在浏览器代码中发现该密钥就证明它已经泄露。Supabase 明确将可发布密钥设计为供网站和移动应用等公开客户端使用。

真正的保护来自权限授予和行级安全性，通常简称为 RLS。RLS 是 PostgreSQL 的一项功能，可在返回或更改单行数据之前，于数据库内部应用授权规则。

已登录用户可能仅获准读取带有该用户标识符的记录。未登录访客可能完全无法访问。另一项策略则可以允许所有人读取有意公开的产品目录。

Supabase 的安全文档表示，开发者必须为暴露的数据表启用 RLS，并根据最小权限原则配置策略。只有当这些控制措施正确限制访问时，可发布密钥才被视为安全。

该平台还为受信任的后端系统提供 secret 或 service-role 密钥。这些密钥会绕过 RLS，绝不能出现在浏览器、已发布的应用或公开代码仓库中。

这种架构形成了一条微妙的安全边界。可发布密钥可见是预期行为，但它也会为未认证访客提供一条通向数据库允许 anon 角色访问内容的路径。

如果一张数据表未启用 RLS、具有过宽的权限授予，或采用允许访问所有行的策略，外部人员便可以通过合法应用使用的同一接口查询它。无需高深的入侵手段。

UpGuard 研究人员通过检查公开交付的 JavaScript 中的 Supabase 标识符，找到了目标项目。随后，他们可以询问每个数据库，其公共接口是否提供了一个常见数据表。

这种技术与普通应用行为相似。区别在于谁在发送请求，以及数据库能否区分获准用户与互联网上的其他任何人。

Supabase 的详细 RLS 指南警告，当暴露 schema 中的数据表未启用 RLS，且请求角色拥有适当权限时，该表可能可读或可写。指南建议针对匿名和已认证角色，测试获允许与被拒绝的操作。

这也是为什么仅轮换可发布密钥无法解决根本问题。新密钥仍可从客户端获取，而有缺陷的数据库策略仍会继续授予访问权限。

开发者应改为审查暴露的 schema、数据表权限、RLS 状态、策略条件、数据库视图以及服务器凭据。他们还需要进行测试，以确认用户无法读取或更改其他用户的记录。

视图尤其值得关注。PostgreSQL 视图默认可能会通过其所有者来评估权限，从而可能绕过保护底层数据表的限制。因此，一个项目即使处处启用了 RLS，仍可能通过不安全的视图泄露数据。

身份验证也适用同样的区别。要求用户登录并不会自动将不同租户隔离开来。如果策略仅检查会话是否有效，那么每个已认证用户仍可能获得广泛访问权限。

因此，从密钥层面解释 Supabase 安全性很直接：公开客户端需要一个公开标识符，而数据库策略负责执行真正的边界。难点在于，将应用预期的规则转化为完整且经过测试的策略。

Vibe Coding 将配置缺口转化为重复出现的模式

当 AI 助手为可见结果进行优化，而授权机制却对指挥它的人不可见时，vibe coding 的安全风险便会增加。

传统开发团队同样可能错误配置数据库。早在生成式 AI 进入软件开发之前，公开的 Amazon S3 存储桶、暴露的 Elasticsearch 集群和泄露的云凭据就已存在。

vibe coding 改变的是速度、可及性和审查不足的结合。人们可以用自然语言提出应用需求，接受生成的代码，连接托管后端并完成部署，却不理解其中的信任边界。

应用可能看起来已经完整，因为注册功能正常、记录能够正确保存、页面可以加载。这些测试证明了功能性，但并不能证明一个账户无法查询另一个账户的记录。

在顺利路径的演示中，授权失败尤其容易被忽视。开发者登录后看到预期的个人资料，便假定系统已经保护了它。攻击者提出的是另一个问题：当请求省略会话或更改记录标识符时，会发生什么？

AI 编程代理也会以程序化方式与基础设施交互。UpGuard 指出，Supabase 会为通过其部分控制面板创建的数据表默认启用 RLS，而通过程序化方式创建的数据表则需要额外注意。

当代理通过 SQL 或 API 创建数据库 schema 时，这一区别可能变得至关重要。附着于某一种创建流程的保护性设置，并不会自动覆盖进入平台的每一条路径。

Supabase 在其2025 年安全回顾中承认了这一更广泛的易用性挑战。该公司表示，RLS 虽然灵活，但对刚接触这一模式的开发者来说可能较为复杂。

在 2025 年期间，Supabase 增加了更安全的默认设置，并扩展了其 Security Advisor。它还让项目能够更好地控制 Data API，包括禁用该 API 的选项，或暴露自定义 schema 而非默认的 public schema。

这些变化有所帮助，但并不能消除既有项目，也无法修复每一项自动生成的迁移。安全工具可以标记常见错误，但一个策略即使通过基本检查，逻辑上仍可能是错误的。

生成的规则可能比较了错误的标识符、遗漏更新路径，或保护了读取操作却允许未经授权的写入。它可能对一张数据表有效，却让关联的数据表保持公开。

人类监督代理时，必须意识到这种缺失行为的存在。不了解 RLS、角色授权或租户隔离的初学者，可能永远不会要求模型测试这些内容。

这在构建与审计之间造成了不对称。生成一项功能只需一个提示词。要证明该功能能安全处理每种身份与操作，则需要威胁模型、负面测试，以及对生成产物的仔细检查。

早期研究表明，这是一种反复出现的模式，而非孤立的调查结果。UpGuard 引用了涉及 Y Combinator 公司、通过 AI 开发平台制作的应用以及独立网站的研究。

Modern Pentest 报告称，在接受检查的 107 家 Y Combinator 初创公司中，28% 通过 Supabase 配置暴露了个人信息。另一项研究审查了 1,072 个 vibe-coded 应用，发现其中 39 个应用的表可通过公开 Supabase 密钥读取。

这些样本和方法各不相同，因此不应将其百分比合并计算。不过，每项调查都发现了同一种失败的不同表现：客户端可见的连接信息，配合权限范围超出应用实际意图的数据库设置。

2026 年 2 月的一起事件尤其清楚地展现了其后果。安全公司 Wiz 发现，Moltbook——一个被描述为面向 AI agents 的社交网络——其 Supabase 后端存在配置错误。

根据 Moltbook 调查，该数据库允许对平台数据进行读写访问。暴露的材料包括 35,000 个电子邮件地址和 150 万个 API 身份验证令牌。

Wiz 表示，它是在一次非侵入式评估中审查客户端 JavaScript 时发现该问题的。Moltbook 团队在收到披露后的数小时内便保护了数据库。

这一事件简明呈现了当前的权衡。AI 辅助帮助打造了一项迅速获得关注的服务，但应用表面上的成功掩盖了关键的数据库控制失效。

对于评估 AI 构建软件的组织而言，这改变了“可运行原型”的含义。演示如今对生产就绪程度的证明作用更弱，因为 AI 能在任何人验证其底层安全模型之前完成可见的工作流程。

内部工程知识库可以帮助团队保留架构决策和审查证据。它无法取代数据库测试，但能够避免安全假设在提示词和交接过程中消失。

“默认安全”与共同责任的碰撞

核心冲突在于：平台提供安全默认值，但共同责任模式仍让缺乏经验的客户掌控影响重大的设置。

Supabase 首席信息安全官 Bil Harmer 告诉 TechCrunch，该公司在发表评论前尚未审阅 UpGuard 的研究。他表示，Supabase 项目默认安全，并将安全描述为共同责任。

这一立场反映了标准的云服务模式。服务提供商负责保护其托管平台并提供访问控制。客户则决定哪些用户和应用应当访问其数据。

这种区分是成立的。UpGuard 并未报告攻破 Supabase 的企业系统，或绕过正确配置的 RLS 策略。被暴露的数据库属于设置允许更广泛访问的客户。

不过，默认设置不能只在项目创建时评估。它还包括人们和 coding agents 用于创建表、发布 API、复制示例及部署应用的实际路径。

一个系统可以一开始是安全的，之后却因代理生成的迁移而暴露。它也可能提供安全的仪表盘工作流程，同时让程序化工作流程创建出不同的安全状态。

因此，“默认安全”这一表述需要明确边界。它是指新项目不会暴露任何内容吗？它涵盖所有受支持的建表路径吗？在生产数据进入未启用 RLS 的表之前，它会提醒用户吗？

共同责任还假定各方都理解自己的职责。有经验的云工程师知道，公开客户端标识符必须与服务器端授权配合使用。但许多 vibe coders 并不知道这一点。

这一知识差距并不意味着平台应当独自为客户错误负责。但它确实提高了对 Supabase 和 AI 编程服务提供商的要求：让不安全状态更难创建、更容易发现。

该平台已经朝这个方向推进。Supabase 的 Security Advisor 会检查常见数据库问题，而其生产检查清单则要求用户为所有相关表启用 RLS 并审查策略。

更严格的设计可能会阻止对未受保护表的生产访问，或要求显式覆盖。此类措施会减少意外暴露，但也可能妨碍合法的公开数据集和快速开发。

Supabase 必须在这些情形之间取得平衡，而不能将每一张公开表都视为漏洞。餐厅菜单、公开排行榜或已发布目录，完全可以合理地允许匿名读取。

平台无法仅从表名推断意图。users 表比 products 表更值得警惕，但某个应用可能有意公开用户资料，同时将电子邮件地址保持私密。

自动化工具同样面临这种模糊性。它们可以检测匿名角色是否能读取某张表。但要判断这种访问是否违背产品承诺，则需要业务背景。

这正是核心权衡。灵活的数据库策略让开发者能够构建多种类型的应用，但灵活性也为无声的错误留下空间。强约束限制能防止错误，却也会限制合法设计。

AI assistants 增加了另一方责任主体。开发者可能因为代理推荐而选择 Supabase，随后依赖该代理生成架构和策略。

模型提供商并不托管数据库，而 Supabase 也无法控制每一条生成的命令。即使所有者无法解释最终的授权模型，应用所有者仍需对用户负责。

这种碎片化链条让安全失效更难归责，也更容易重演。每个参与者都可以指向文档或另一方的配置，而受影响的人只会看到私人信息变成了公开信息。

对于企业采购方而言，实际应对方式是评估完整的开发系统。供应商认证固然重要，但部署控制、代码审查、数据库测试、日志记录、事件响应，以及监督 AI agents 的人员经验同样重要。

数字说明了什么，又没有说明什么

该研究显示出巨大的暴露面，但其方法论并不能证明存在 16,326 起已确认的数据泄露，也未衡量整个 Supabase 客户群体。

UpGuard 从显示使用 Supabase 迹象的域名开始，而不是从平台上所有应用中随机抽样。其来源偏向于可通过 Web 技术数据集观察到的网站。

随后，研究人员查询了名为 users 的表。这一选择是合理的，因为许多应用会维护用户记录，但也使调查更偏向于可能包含个人信息的数据库。

UpGuard 披露了这一限制。该公司表示，其结果偏向 PII，部分原因在于其刻意选择了一个与人员相关的常见表。

16,326 这一总数涵盖的是暴露出可读表的数据库。这并不意味着每张表都存有机密记录。一些项目可能有意发布了数据、使用了合成信息，或已经被废弃。

架构分析衡量潜在暴露的方式，也不同于逐行取证调查。名为 password 的列是严重警告，但仅凭其存在并不能证明其中存有仍在使用的凭证。

研究人员手动验证了部分案例，并报告了这些数据库中的具体记录数量。这些案例表明，至少部分暴露涉及真实、敏感且规模可观的数据。

该研究也无法确定在披露前有多少外部人员访问过这些数据库。公开可用会带来风险，但并不能证明犯罪行为者发现或下载了这些信息。

这种差异将数据暴露与已确认的数据泄露区分开来。暴露意味着未经授权的访问成为可能。数据泄露通常需要证据证明未经授权的一方确实访问或获取了数据。

组织不应利用这种区分淡化事件。一旦敏感记录可在没有适当授权的情况下被访问，调查人员可能缺乏足够的日志来证明谁访问过它们。

该研究也没有计算所有 Supabase 项目中的暴露率。UpGuard 分析了约 30 万个候选域名，而一个组织可能运营多个域名或项目。

不活跃的网站和错误的技术指标可能会使这个分母变得复杂。最终数字最好被理解为一个已发现的群体，而非 Supabase 客户所占百分比。

即使有这些谨慎限定，16,326 个可读数据库仍代表着可观的攻击面。恶意行为者可以自动化同样的大致发现过程，并优先锁定包含高价值字段的表。

详细案例也削弱了“这些只是无害演示项目”的说法。移民记录、紧急住房地点、私密成人通信、车牌号和一次性验证码，都具有明显的隐私与安全影响。

Supabase 的回应同样值得精确解读。该公司称，在了解到安全问题时会通知受影响的客户。这并不能确认有多少项目收到通知、它们响应的速度，以及仍有多少暴露尚未关闭。

UpGuard 表示，它已通知其验证过的重大案例中的应用所有者。其公开报告并未提供全部 16,326 个数据库的完整修复率。

这些空白应当影响对发现结果的报道。证据支持存在广泛的配置问题和多起严重暴露，但并不支持声称 Supabase 本身遭到黑客攻击，或每个已识别数据库都泄露了敏感记录。

它还留下了一个重要的比较问题未获回答。若研究人员采用同等规模的互联网方法，可比的托管数据库也可能显示出类似问题。

Firebase、Appwrite、自行管理的 PostgreSQL 部署及其他后端服务暴露的接口不同，使用的权限模型也不同。开发者可能错误配置其中任何一种。

Supabase 受到关注，是因为其面向客户端的架构、自动 API，以及在 AI 编程工作流程中的受欢迎程度，使这一问题更加显眼。普及度同时增加了安全部署的数量和错误的数量。

因此，公平的评估不应将 Supabase 描绘为唯一无法保护数据的平台。更有力的结论是，它在缺乏经验的构建者群体中的广泛采用，使访问控制的可用性成为平台层面的关切。

三个信号将表明风险是否正在缩小

下一阶段应通过可衡量的产品变化、修复证据和独立复测来评判，而不是依赖笼统的安全承诺。

第一个信号是 Supabase 如何处理以编程方式创建的表。Coding agents 通常通过 SQL、管理接口和自动化迁移工作，而非手动点击仪表盘。

一项有意义的改变，是让 RLS 和严格授权在不同创建路径中保持一致，或要求在表可通过 Data API 访问之前作出明确决定。agent 工作流程中的清晰警告将强化这种保护。

如果 Supabase 能缩小仪表盘创建与编程式创建之间的差距，这将强化一种观点：更安全的默认设置可以降低氛围编程带来的安全风险。如果工作流程仍然不同，缺乏经验的构建者将继续在未察觉的情况下进入不安全状态。

第二个信号是修复数据。Supabase 和 UpGuard 可以说明有多少已识别项目收到了通知、有多少所有者作出回应，以及有多少数据库不再暴露非预期记录。

较高的修复率将表明，通知机制和安全工具能够减少现有积压问题。较低的修复率则意味着，许多项目可能已被弃置、维护不善，或由无力修复配置问题的人员运营。

受影响的组织还必须确定，暴露的记录是否需要通知用户或向监管机构报告。这一决定取决于所在地、数据类型、访问证据以及适用法律。

第三个信号是在未来数月内进行独立复测。研究人员应重复开展可比的扫描，并公布透明的方法，以区分有意公开的数据与敏感信息暴露。

数据库数量下降将支持 Supabase 的更安全默认设置策略。数量保持稳定或上升则表明，平台增长和 AI 辅助开发创造不安全项目的速度，快于现有控制措施纠正它们的速度。

在复测期间，AI 编程服务提供商同样值得审视。它们的智能体应创建最小权限策略、生成反向授权测试，并在部署暴露个人信息时发出警告。

开发者无需为了负责任地应对这一问题而放弃 Supabase 或 AI 编程。他们需要将生成的软件视为不可信，直到其授权行为经过测试。

这意味着需要分别检查匿名访问和已认证访问，测试每一项数据库操作，审查视图，保护服务器密钥，并禁用应用程序并不需要的接口。

团队还应保留这些控制措施背后的决策依据。可搜索的 AI 知识库 可以将需求、生成的迁移、审计发现和修复工作关联起来，避免文档工作沦为事后补充。

Supabase 数据暴露事件归根结底关乎一个问责缺口。平台提供可配置的控制措施，AI 智能体组装应用程序，而用户信任最终完成的界面。

在真实信息进入系统之前，谁来验证那些不可见的权限？任何发布 AI 生成应用的组织，都应能用测试结果、明确的责任人以及访问被拒的证据来回答这个问题。