![[Vibe Coder #8] 接受使用者前的 6 項安全檢查 封面圖](/assets/images/posts/88a2c686-f9c2-4047-8809-30b6118aec87/launch-security-checklist-1.jpg)
App 已完成、也已部署，現在只剩把連結公開給全世界。系列最後一篇是公開前的最終檢查：接受使用者前必須確認的 6 項安全檢查，以及從第 1 篇延續至今的完整地圖總結。
開始前先釐清一個常見誤解：「我的 App 很小，也不出名，誰會攻擊它？」如第 2 篇所見，攻擊者不是人，而是機器人。機器人不挑選目標，而是撒網。 它們會自動掃描網路上所有公開位址，尋找敞開的入口。App 小並不代表安全，只代表沒有人替它把關。幸好，Vibe Coding App 常被突破的入口大多固定，以下 6 個就是這些入口。
公開前檢查清單 6 項
1. 是否有機密值外洩？ 這是第 2 篇的檢查。確認 API 金鑰沒有暴露在前端或 GitHub 公開儲存庫中。給 AI 的指令：「找出這個專案中所有 API 金鑰或機密值曾被傳送到前端，或曾提交到 Git 的地方。」
2. 後端是否有權限檢查？ 這是第 1 篇的原則。隱藏刪除按鈕只是裝飾，任何人都能送出請求。對文章的刪除、修改、查詢，後端都必須確認「這個使用者是否有資格執行」。給 AI 的指令：「稽核所有後端 API 是否確認登入狀態與擁有權，並列出遺漏處。」
3. 是否任何人都能進入 DB？ 倉庫（DB）有自己的存取規則。以 Supabase 來說，就是 RLS（Row Level Security，資料列層級安全性）：簡單說，是把「每一列資料誰能讀寫」的規則貼在倉庫門上。如果關閉，就會開啟不經過後端、直接闖入倉庫的路徑。在實際的 Vibe Coding App 事故案例中，這是最常被指出的項目。給 AI 的指令：「確認我的 DB 資料表中是否有任何人都能讀寫的表，並告訴我如何鎖定它們。」
4. 是否已準備好應對異常輸入？ 使用者會在輸入框中放入任何內容：10 萬字的文章、奇怪的程式碼片段、空值。如果後端不驗證輸入長度與格式，App 就可能故障或被突破。給 AI 的指令：「確認所有接收使用者輸入的地方是否都有長度限制與格式驗證。」
5. 是否設定了費用安全裝置？ 這是第 7 篇的 5 分鐘設定：支出上限與預算通知。從有使用者的那一刻起，呼叫量就不再由我掌控，因此公開前是最後的設定機會。
6. 是否有可以回復的地方？ 這是第 3 篇的存檔點。先提交並推送公開前的狀態，再確認 DB 備份已開啟。公開後第一次發生事故時，能否回到「原本運作正常的時點」會決定復原速度。
如果覺得逐一確認 6 項很麻煩，至少執行這一個最後手段的提示詞：「你是安全稽核員。在公開這個專案前，請從機密值外洩、權限檢查遺漏、DB 存取規則、輸入驗證等角度，找出所有危險處，並依嚴重程度排序告訴我。」即使是製作時犯過錯的 AI，要求它稽核時也能找得很好。但不要直接相信 AI 的「現在安全了」，對照上述清單逐項確認，才算完成檢查。
系列總整理：一張地圖
把 8 篇折疊成一張，就是這樣。
- 第 1 篇 — 結構：App 是大廳（前端）、廚房（後端）與倉庫（DB）。前端是公開空間，因此不要在裡面放機密。
- 第 2 篇 — API 金鑰：金鑰就是公司信用卡。位置只有兩個：
.env與部署儀表板。 - 第 3 篇 — Git：提交就是存檔。每次運作正常時，以及每次重大修改前，都要存檔。
- 第 4 篇 — 部署：部署就是搬到伺服器。
.env不會跟著搬家行李一起上車，因此要另外登錄到儀表板。 - 第 5 篇 — 錯誤：錯誤訊息就是自白書。連同情境完整交給 AI。如果 AI 不斷繞圈，就換個做法。
- 第 6 篇 — 神秘問題：「明明什麼都沒改」的犯人是快取、相依性、外部服務，以及昨天的自己。從成本最低的確認開始，依序排查。
- 第 7 篇 — 費用：帳單來自 Token、讀寫與流量。支出上限和通知是 5 分鐘設定的保險。
- 第 8 篇 — 公開前檢查：鎖好上面的 6 道門再出發。
結語
這個系列沒有教你寫程式，而是畫出了地圖：我的 App 由哪些元件組成、每個元件會在哪裡造成什麼事故，以及發生事故時該看哪裡、要對 AI 說什麼。Vibe Coding 真正的實力不是閱讀程式碼的能力，而是拿著這張地圖向 AI 提出精確問題的能力。
地圖現在已經在你們手上。做出好東西，讓全世界看見。