今年 2 月，OpenAI 前创始成员 Andrej Karpathy 凭一己之力，带火了一个词——“氛围编码”（Vibe Coding）。
简单说，就是“你说想法，AI 写代码”。就算完全不懂编程，只要有个点子，借助像 Cursor、ChatGPT 这样的 AI 工具，也能快速做出一个应用、小游戏之类的。这种“说着就能写程序”的方式吸引了不少开发者尝试。
不过，看起来轻松高效的背后，也藏着不小的安全隐患。并不是每个人、每个项目都适合靠“氛围”上代码。
这不，一位开发者 Harley Kimball 就在 X 上分享了自己使用“氛围编码”而后“掉坑”的经历。他用了三天不到的时间开发并上线了一个聚合网站的应用，殊不知，却在随后短短两天内接连遭遇两次安全漏洞攻击。
幸运的是，这两次攻击都由白帽黑客（负责任的安全研究员）在没有恶意破坏的前提下发现并反馈。为此，Harley Kimball 将自己的遭遇进行了总结与复盘，希望为更多的初创项目和个人开发者敲响警钟。
三天快速开发的网站
Harley Kimball 做的这个应用，说白了就是一个把各大安全研究员平台（像 HackerOne、Bugcrowd、GitHub 这些）上的公开资料集中到一块的网站。用户注册登录之后，可以一眼看到各路白帽黑客的公开档案。
Kimball 的初衷，是想给整个漏洞赏金圈搞一个“查号宝典”，方便大家快速找到相关研究员的资料。
据 Kimball 自述，这款目录网站的前端是通过 Cursor 和 Lovable 等 AI 编程工具搭建的，并与 Supabase 提供的云数据库服务相连。Supabase 在开发者中颇受欢迎，提供开箱即用的认证、存储和数据库功能。
不过，整个系统中最关键的数据采集部分——也就是把各个平台的公开资料导入数据库的过程——是通过独立的自动化脚本来完成的，并没有集成在前端或用户操作中。这种“前后分离”的设计，虽然能让界面更轻便，也便于快速上线，但也意味着如果底层权限控制没做好，系统可能在开发者都没注意到的地方暴露风险。
起初，Harley Kimball 打算让用户使用 Supabase Auth 自行注册，并提交他们想要汇总的个人资料。但在开发过程中，他意识到，处理用户注册不仅涉及身份验证（Authentication），还涉及权限管理（Authorization）——如果管理不当，可能造成数据被恶意篡改。
因此，他放弃了自助注册功能，转而采用只读的数据视图...令他没想到的是，这也成为了第一个安全漏洞的导火索。
第一次被攻破：邮箱泄露引发的权限绕过
在开发测试阶段，Kimball 采用 Supabase 提供的用户认证功能，这意味着用户必须使用真实邮箱注册登录。
然而，他在检查前后端的数据传输时意外发现：用户邮箱信息会被一并返回给前端页面，存在泄露风险。虽然这些邮箱可能原本是公开的，但一旦用户对平台抱有隐私期待，这种行为就可能构成严重的问题。
为了修复这个漏洞，他采用了一个常见的处理方式：用 PostgreSQL 创建了一个“视图”（view），只提取所需字段，排除了邮箱信息，并让前端只访问这个视图。表面上看，这个做法更安全了——然而，问题也悄然埋下。
正式上线后不久，也就是在第一个版本发布不到 24 小时，一位安全研究员反馈称：尽管网站的前端并没有提供新增或修改数据的入口，他依然能在数据库中随意插入、修改和删除记录。这显然说明，系统的访问权限控制出了问题。
问题的根源，出在那个看似“安全”的数据库视图上。
Kimball 在创建视图时，使用的是默认设置——也就是说，这个视图运行时会继承其创建者（也就是管理员）的权限。而 PostgreSQL 的行级安全（Row-Level Security, RLS）机制，是需要额外配置才能在视图中生效的。如果没有手动启用“SECURITY INVOKER”或加上专门的安全限制，RLS 就会被绕过，导致权限失控。
这正是这次“首个安全漏洞”的核心原因。所幸，一位名为 @Goofygiraffe06 的研究员负责任地报告了这个问题，Kimball 随后紧急修复了访问权限，重新设计了数据的查询方式，堵上了这个漏洞。
第二次被攻破：关闭前端不等于关闭后台
就在首个安全漏洞修复的第二天，Kimball 又收到了另一位安全研究员 @Kr1shna4garwal 的提醒：攻击者依旧可以注册账号并创建数据。他们发现依然可以往数据库中添加新的“研究员档案”——虽然不能修改或删除已有数据，但这意味着系统的访问控制没有完全锁死。
这一次的问题，并不是出在前文提到的数据库视图上，而是另有隐情。
Kimball 虽然在前端界面上取消了“用户自助注册”入口，但后台使用的 Supabase 认证服务（Auth）依旧处于激活启动状态。换句话说，攻击者只要知道 API 的调用方式，就可以绕过前端，通过邮箱和密码注册一个新账号，成为系统“眼中”的合法用户，并按照既有的权限规则操作数据。
这种“前端没入口，但后端没封死”的配置，在不少使用现成后端服务的项目中很常见，也很容易被忽视。
最终，Kimball 通过彻底关闭 Supabase Auth 的注册功能，才完全堵上了这个权限漏洞。
经验教训：氛围编程虽快，安全不能缺位
Kimball 在总结这次“上线即被攻破”的经历时，也分享了几点关键反思，对依赖低代码或 AI 工具进行开发的开发者具有一定参考意义：
首先，“氛围编码”（vibe coding）虽然能让项目快速成型，但默认状态下往往忽略了安全配置，一不小心就会留下严重漏洞。
其次，Supabase 和 PostgreSQL 这对组合功能强大，但它们的权限模型也相对复杂。特别是在使用数据库视图（view）和行级安全策略（Row-Level Security，RLS） 时，如果开发者不了解其背后的默认行为，就很容易配置失误，导致权限失控。
比如，PostgreSQL 中的视图默认是以创建者（通常是管理员）的权限运行的，这意味着 RLS 策略会被绕过，除非显式指定为 SECURITY INVOKER，或另行设置安全策略。
此外，如果项目并未真正使用 Supabase 的认证功能，务必在后台设置中彻底关闭注册入口——仅仅在前端页面隐藏相关功能远远不够。
Kimball 表示，他的应用主要聚合的是公开数据，因此这两次安全事件的实际影响有限。但如果系统涉及的是敏感信息，例如个人身份数据（PII）或健康信息（PHI），类似的配置漏洞可能会造成灾难性后果。
这起事件也提醒开发者，即便是看似简单的工具链和“只读数据”的项目，也必须进行基础的威胁建模与权限审查。快速上线不代表可以省略安全流程，尤其是在 AI 编码与自动化工具愈发普及的当下。
参考：
https://threadreaderapp.com/thread/1929017755136561402.html
https://x.com/infinitelogins/status/1929017766347993129
本文来自微信公众号“CSDN”，整理：屠敏 ，36氪经授权发布。
