今年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編碼與自動化工具愈發普及的當下。
本文來源：36氪
文章轉載于其他網絡，如有侵權請聯系我們及時刪除
