用 AI 寫程式也要顧資安：我給自己的 10 項檢查表

這兩年有幾起新聞，某些靠 AI 快速做出來的服務把客戶名單外洩了。仔細看成因，幾乎都不是密碼學選錯演算法，而是非常基本的疏忽。我替自己的登入服務做了一次對照檢查，把結果整理成下面這份表。你也可以拿去檢查自己的專案。

十項檢查

1. 資料庫有沒有直接暴露給前端？ 用 Supabase 或 Firebase 這類服務時，如果公開金鑰搭配沒設好的存取規則，任何人都能直接查資料。我的做法是資料庫完全不對外，前端永遠只能打 Worker 的 API，資料存取全部寫在後端。

2. 密碼是不是明碼存放？ 使用者端我只留第三方登入，沒有密碼可以猜。必須存放的密碼一律經過加鹽的慢速雜湊，比對時用常數時間，絕不存明碼。

3. 金鑰有沒有寫在程式碼或 repo 裡？ 所有機密（JWT 簽章金鑰、Google Client Secret、管理密碼）只用 wrangler secret put 存在 Cloudflare，不出現在程式碼或 wrangler.toml。本機用的 .dev.vars 一定要放進 .gitignore。

4. 後台管理 API 有沒有驗證？ 管理介面要和一般使用者的身分完全分開，不接受一般使用者的憑證，也不對外開放跨網域呼叫。連續登入失敗要有鎖定機制，並且考慮加上第二道驗證。

5. 有沒有 SQL Injection？ 所有查詢都用 D1 的 prepared statement 搭配 bind()，沒有任何字串拼接組 SQL。讓 AI 寫查詢時，這一點要特別檢查，因為模型常常會為了方便直接拼字串。

6. CORS 是不是設成 *？ CORS 用白名單，只有自己的網域能帶憑證呼叫 API。設成 * 的話，任何網站都能借用使用者的登入狀態打你的 API。

7. Token 有沒有永久有效？ 存取憑證只給很短的效期，長效憑證在資料庫裡只存雜湊值，而且每次刷新就換發新的、撤銷舊的，單一憑證外洩可被利用的時間很短。

8. 有沒有頻率限制？ 登入與一般 API 都要有頻率限制，並且把被擋下的可疑請求記錄下來，事後才查得到。

9. Log 裡有沒有印出密碼或 token？ 程式碼裡沒有任何地方 log 密碼或 token 的明文。這點最容易在除錯時不小心犯：一行 console.log(req) 就可能把所有東西印出來。

10. 資料表會不會無限成長？ 每天排程清理過期的 refresh token、OAuth state 與舊紀錄，後台也看得到用量。D1 被塞爆之後所有寫入都會失敗，這種故障很容易被忽略，直到某天使用者突然登不進去。

這份表為什麼只寫原則

我刻意不寫具體的數值、路徑與設定名稱。防護機制的細節本身就是資訊，攻擊者知道門檻在哪裡，就知道該怎麼繞。這也是一條值得記住的習慣：公開分享做法，不公開參數。

給用 AI 寫程式的人

AI 能快速寫出可以運作的程式，但「可以運作」和「安全」是兩回事。我的習慣是把這份檢查表當成固定的收尾步驟：功能做完，逐項對照一遍，再上線。花不到一小時，換來的是不會上新聞。