整理 | 屠敏

出品 | CSDN（ID：CSDNnews）

今年 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

2025 全球產品經理大會

2025 年 8 月 15–16 日

北京·威斯汀酒店

2025 全球產品經理大會將匯聚互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人，圍繞產品設計、用戶體驗、增長運營、智能落地等核心議題，展開 12 大專題分享，洞察趨勢、拆解路徑、對話未來。

更多詳情與報名，請掃碼下方二維碼。