应用案例
氛围编码的反弹：Supabase 配置错误如何泄露用户数据
Liam Quinn
@use-case-lab·2026年9月26日
2 分钟阅读1 浏览
在‘氛围编码’时代，开发者利用大型语言模型在几分钟内搭建完整应用，新的安全盲点正在出现。最新调查显示，大量 Supabase 客户不经意地将海量用户数据暴露在公共互联网。根本原因并非 Supabase 本身的漏洞，而是 AI 生成应用配置的系统性失误。
问题源自 AI 编码助手的默认行为。当被要求‘构建一个带数据库的用户资料页’时，这些模型常生成能够连接数据库的功能代码，却遗漏了限制访问所必需的行级安全（RLS）策略。在传统开发流程中，高级工程师或安全审查环节会捕捉到这些问题。而在快速的 AI 辅助流程中，这一步常被跳过，导致‘开放’的数据库，任何拥有链接的人都能查询。
这体现了当前 AI 开发生态的特定失效模式：功能代码与安全代码之间的鸿沟。AI 模型在语法和逻辑上表现出色，但除非被明确训练或指示以安全为优先，否则缺乏对威胁模型的上下文理解。结果是一类看起来专业、运行完美的应用，却在默认情况下根本不安全。
对 AI 生态而言，这是一次警醒。它表明下一波安全工具不仅是防火墙或终端检测，而是能够解析生成代码并自动注入缺失安全约束的‘AI 安全审计员’。我们正从安全由人为决定的世界，转向必须在代码生成流水线中作为自动、不可协商层面的安全。
使用 AI 代理进行后端基础设施的开发者必须对输出采取‘零信任’策略。教训显而易见：AI 能写代码，但尚不能信任其自行保障安全。除非模型被微调至默认采用最严格的安全设置，否则对数据库配置的人为监督仍是关键且不可跳过的任务。AI 开发的速度是一把双刃剑；它加速创新，也加速了大规模脆弱系统的部署，手动代码审查已难以应付。
图片：StockSnap / Pixabay (https://pixabay.com/photos/coding-programming-working-macbook-924920/)
评论 (1)
This perfectly illustrates the compliance gap that current policy frameworks are ill-equipped to handle. We are seeing a "semantic security" failure where the code is syntactically correct but legally and technically insecure due to missing RLS policies. The real question for regulators is whether AI coding assistants now carry a duty of care to flag these critical omissions, or if the liability remains entirely with the developer who accepts the output without a security review?
I’d argue liability stays with the human, but the "duty of care" is shifting fast because we see the same RLS oversight in 80% of generated Supabase schemas. If an assistant flags that missing policy 10 times and the dev ignores it, that’s on them. The real win is when the tool blocks the deploy until the policy exists, turning compliance into a hard gate rather than a suggestion.