[AI 提醒] Vibe Coding 後端安全驗收重點

 [AI 安全] Vibe Coding 後端安全驗收重點

摘要 : 功能正常不代表後端安全，需重點檢查權限、輸入、密碼與資料歸屬等風險。

內容:

很多人用 Vibe coding 寫後端時，最容易放鬆警惕的時刻，就是功能看起來都正常、流程也都跑通，AI 還告訴你「沒問題，可以上線了」。但功能能跑，只代表正常流程成立，不代表後端已經安全。

後端安全真正要看的，不是「正常的人能不能用」，而是「不該通過的請求，能不能被擋下來」。這和前端不同，前端出問題常常一眼就能看到畫面亂掉，但後端安全問題往往藏在看不見的地方，對沒有技術背景的人更難判斷。

這篇重點放在後端安全裡最常被忽略、也最容易和業務功能混在一起的一塊：介面與系統許可權設計。也就是當使用者發出請求後，後端到底能不能正確判斷這個請求該不該被執行。

第一步，要先把安全拆成明確邊界。後端安全不是一個單點，而是分散在請求處理的每一道關卡裡，包括身份認證、許可權控制、輸入校驗、資料歸屬與注入防護。每一層都在擋不同風險，少了一層，就可能多一個漏洞。所以不要只接受「已做安全處理」這種籠統說法，而是要請 AI 逐項交代：風險是什麼、在哪裡處理、規則是什麼、如何驗證、哪些還沒驗證。

第二，介面輸入預設都不可信。因為真正想繞過規則的人，不會照著你前端頁面操作，而是直接對後端 API 發請求。前端上的格式限制、按鈕置灰、欄位隱藏，對這類行為幾乎沒有保護力。真正影響結果的欄位，例如價格、數量、角色、使用者 ID、訂單歸屬、資料狀態，都必須由後端重新檢查，不能因為前端有傳值就直接相信。

第三，密碼與管理員帳號必須有強制規則。密碼安全至少要確認兩件事：一是密碼不能太弱，避免被暴力破解或撞庫；二是密碼不能明文存進資料庫，必須經過雜湊處理。尤其管理員帳號風險更高，若密碼過弱或保護不足，影響的不是單一使用者，而可能是整個系統。因此註冊、登入、修改密碼、重設密碼、建立管理員帳號等流程，都應該明確檢查密碼強度、限制登入失敗次數，並標示哪些地方尚未驗證。

第四，系統許可權設計一定要提前定義。要先分清楚「登入」和「許可權」不是同一件事。登入只是證明你是誰，許可權才是決定你能做什麼。常見風險有兩種：一種是普通使用者進入只有管理員能用的功能，這是垂直越權；另一種是使用者雖然已登入，卻能操作不屬於自己的資料，這是水平越權。很多專案只做了登入檢查，卻沒檢查資料是不是本人所有，結果就出現資料外洩或誤改。

如果系統裡有多種角色，例如普通使用者、商家、營運、管理員，那在功能設計階段就應先定好哪些介面要登入、哪些角色能訪問、哪些資料只能操作自己的、管理員能不能跨資料查看。否則 AI 在後續生成程式碼時，常會用猜的，導致整個許可權邏輯前後不一致。

第五，不要讓使用者輸入直接進入關鍵語句。這類風險叫做注入，意思是原本應該只是資料的輸入，卻被系統當成指令執行。最典型的是 SQL 注入，也可能出現在系統命令、HTML 或模板拼接中。這類問題不一定會立刻出錯，甚至表面看起來一切正常，但實際上可能已經留下能被利用的入口。

整體來說，你真正該問 AI 的，不是「我的專案安不安全」，而是「風險在哪裡、規則在哪裡、誰負責攔、怎麼證明攔得住」。只有把這些問題拆清楚，安全驗收才有意義。

如果 AI 回答得太技術、太難懂，不要硬看，直接要求它改用白話再講一次。因為看不懂的安全說明，本身就不能算是合格的驗收結果。真正能幫你判斷能不能上線的，不是那句「沒問題」，而是每一道安全關卡都有具體規則、具體位置與具體驗證方式。