AI 建置應用程式的安全檢查清單：上線前該檢查什麼

在真實使用者使用你用 AI 建置的應用程式之前，請檢查七件事：每個頁面和 API 都要確認使用者是誰、可以做什麼；密鑰只能存放在伺服器上，絕不能出現在瀏覽器或對話中；所有輸入都要在伺服器端驗證；每位使用者只能存取自己的紀錄；登入與高成本的端點都要設定速率限制；相依套件保持更新；而且如果出了問題，你能夠還原資料。以下的檢查清單，把每一件事都轉化為具體的測試，讓你不需要讀程式碼也能執行。

AI 應用程式建置工具很擅長讓功能運作，但它們不會自動變得謹慎，因為「謹慎」很少出現在提示中。以下大多數問題，都是來自沒有人要求過的事情，所以解決方法通常就是去要求。

如何使用這份檢查清單

請依順序逐項完成，每一項都要做兩件事：請 AI 確認這件事已經處理，以及自己親自測試。AI 可以寫出權限檢查，但只有測試能證明它真的有效。各項目的標記如下：

• 必做 — 在其他人使用應用程式之前完成。
• 應做 — 在你有真實使用者或真實資料之前完成。
• 之後再做 — 隨著應用程式成長再處理也值得。

如果你只有一小時，請完成所有必做項目。

1. 身分驗證：這是誰？

身分驗證是確認某人的身分，通常就是登入。基本概念請參見什麼是身分驗證，登入方式的選項請參見如何為應用程式加入登入功能。

• 必做： 每個顯示私人資料的頁面都必須要求登入。測試方式：登出後，把私人頁面的網址直接貼到瀏覽器中。
• 必做： 這些頁面背後的每個 API 端點也都必須要求登入，而不只是頁面本身。測試方式：登出後，打開瀏覽器的網路分頁，重新發送你登入時應用程式發出的一個請求。
• 必做： 密碼必須使用緩慢的密碼雜湊演算法加密儲存，絕不能以純文字儲存。OWASP 的密碼儲存指南首推 Argon2id，其他替代方案包括 scrypt、bcrypt 或 PBKDF2。請詢問：「密碼是如何儲存的？」
• 應做： 密碼重設連結會過期，且只能使用一次。
• 應做： 工作階段 Cookie 標示 Secure、HttpOnly 與 SameSite，並且登出時會在伺服器端結束工作階段。
• 之後再做： 提供雙重驗證，或透過支援該功能的供應商登入。

檢查每一個會回傳使用者資料的 API 路由與頁面。每一個都必須在伺服器端拒絕未登入使用者的請求，而不只是依賴頁面程式碼。請列出你檢查過的路由。

2. 授權：他們被允許做什麼？

授權是登入之後的步驟：決定這位特定使用者可以檢視與修改哪些內容。AI 建置的應用程式最常在這裡出現嚴重漏洞，因為應用程式看起來正確，每位使用者的儀表板只顯示自己的資料，但只要有人直接提出要求，伺服器就會毫不猶豫地交出任何人的資料。

• 必做： 每一次讀取、更新與刪除，都要在伺服器端確認該紀錄屬於目前的使用者（或其團隊）。
• 必做： 進行測試：建立兩個帳號 A 與 B。以 A 的身分開啟 A 的某筆紀錄，記下網址或網路請求中的 ID。改以 B 登入，並請求同一個 ID。B 必須收到錯誤，而不是 A 的資料。
• 必做： 管理頁面與管理 API 端點必須在伺服器端檢查使用者的角色。隱藏管理連結並不是保護。
• 必做： 使用者不能透過修改請求來變更自己的角色、價格、餘額或擁有者欄位。測試方式：在網路分頁中查看一次個人資料更新送出的內容。如果其中包含 role 或 isAdmin 之類的欄位，請要求 AI 在伺服器端忽略來自用戶端的這些欄位。
• 應做： 網址中的 ID 很難猜測（使用隨機 ID，而不是 1、2、3）。這不能取代權限檢查，但在權限檢查遺漏時能降低損害。

對於每個讀取或變更紀錄的端點，都要在伺服器端確認已登入的使用者擁有該紀錄或有權存取。若不符合，回傳 404。然後向我展示你會如何用兩個帳號測試這一點。

3. 資料庫中的列級存取

「列級存取」是指資料表中的每一列（例如一筆預約、一張發票）只對屬於它的使用者可見。常見的實現方式有兩種：

兩種做法都能做好。重點在於：

• 必做： 如果瀏覽器會直接與資料庫溝通（某些託管資料庫產品允許這樣做），每個資料表都必須啟用列級規則。沒有這些規則，任何持有公開金鑰的人都可以讀取整個資料表。
• 必做： 查詢必須依照目前的使用者或團隊過濾，而不是依照瀏覽器傳來的 ID 過濾。
• 應做： 共用資料（例如團隊專案）要有明確的規則說明誰屬於該團隊，並且只在一個地方強制執行。

4. 密鑰與 API 金鑰

API 金鑰就是服務的密碼。Stripe、電子郵件與 AI 供應商都使用這種金鑰。相關背景請參見什麼是環境變數與密鑰。

• 必做： 金鑰必須儲存在專案的環境變數或密鑰設定中，絕不能寫進程式碼。
• 必做： 可以花錢或讀取私人資料的金鑰只能在伺服器端使用。測試方式：開啟你的正式網站，在開發者工具中查看頁面原始碼與 JavaScript 檔案，並搜尋你金鑰的開頭（例如 sk_）。它不應該出現。
• 必做： 金鑰從未貼到對話、公開儲存庫或截圖中。如果曾經貼過，請在供應商處輪換該金鑰（建立新的，刪除舊的）。
• 應做： 如果供應商提供，請使用受限或限定範圍的金鑰。例如 Stripe 建議使用受限金鑰，只授予整合所需的權限。
• 應做： 測試金鑰與正式金鑰要分開，且只有在準備好時，正式應用程式才使用正式金鑰。

有些金鑰本來就設計為公開使用，例如 Stripe 的可發布金鑰（pk_…），或是限制在你網域內使用的地圖金鑰。這條規則針對的是具有實際權限的金鑰，而不是所有看起來像金鑰的字串。

5. 輸入驗證

使用者傳送的任何內容（表單欄位、檔案上傳、網址參數）都可能是任何東西，而不只是你的表單允許的內容。

• 必做： 驗證必須在伺服器端進行，而不只是在瀏覽器中。瀏覽器端的檢查只是為了方便，任何人都可以跳過。
• 必做： 資料庫查詢使用參數，而不是把使用者輸入的文字直接拼接進去（這可以防止 SQL 注入）。請要求 AI 確認。
• 必做： 使用者輸入的文字應以純文字顯示，而不是當作 HTML 執行。測試方式：把 <b>hello</b> 輸入為你的名字。你應該看到標籤本身，而不是粗體文字。
• 應做： 檔案上傳要檢查類型與大小，而且上傳的檔案不能從你應用程式的主要網域以可執行頁面的形式提供。
• 應做： 顯示給使用者的錯誤訊息要簡單（「發生錯誤」）；詳細的錯誤只寫入伺服器紀錄。
• 應做： 來自 Stripe 等服務的 Webhook，在採取行動前要先驗證供應商的簽章。參見什麼是 Webhook。

為每個表單與 API 端點加上伺服器端驗證：必填欄位、長度、格式與允許的值。其他一律拒絕，並給出清楚的訊息。不要向使用者顯示內部錯誤細節。

6. 速率限制與濫用

速率限制是限制某人在一段期間內可以發出的請求數量。沒有它，任何人都可以整天猜測密碼、洗版你的註冊表單，或在付費 API 上耗盡你的帳單。

• 必做： 登入、註冊與密碼重設都必須依 IP 位址與依帳號進行速率限制。
• 必做： 任何每次呼叫都會讓你花錢的功能（AI 模型請求、簡訊、電子郵件）都要有每位使用者的限制，並且需要登入。
• 應做： 公開表單（聯絡表單、候補名單）要有防垃圾訊息機制：速率限制、隱藏的蜜罐欄位，或 CAPTCHA。
• 應做： 在付費供應商處設定消費上限或警示，這樣程式錯誤或攻擊者就無法製造無上限的帳單。

7. 相依套件

應用程式是由開源套件組成的，而套件有時會有已知的漏洞。

• 應做： 請 AI 檢查已知漏洞（對 JavaScript 專案來說，是 npm audit 或你的套件管理工具的對應指令），並更新受影響的套件。
• 應做： 移除應用程式已不再使用的套件。
• 應做： 對於使用者很少的套件，或名稱看起來像熱門套件拼字錯誤的套件，要保持警覺。
• 之後再做： 每一到兩個月重新檢查一次；如果你的程式碼放在 GitHub 上，可以開啟自動警示。

8. 備份與復原

安全也包括從錯誤中復原的能力，無論錯誤來自你、AI，或是攻擊者。

• 必做： 知道你的資料存放在哪裡，以及是否有備份。不要想當然，請查看你的主機文件。
• 應做： 定期自行匯出重要資料（例如 CSV 匯出功能或資料庫傾印檔），並存放在不同的地方。
• 應做： 將你的程式碼放入版本控制，以便還原任何版本。
• 應做： 破壞性操作（刪除帳號、刪除專案）要求確認，並考慮採用「軟刪除」，讓資料在一段時間內可以復原。
• 之後再做： 實際測試一次還原。從未還原過的備份只是希望，不是計畫。

9. 上線前

• 必做： 正式網站全面使用 HTTPS。
• 必做： 移除開發時留下的範例資料、測試帳號與除錯頁面。
• 應做： 隱私權政策要說明你收集哪些資料以及原因。如果你收集個人資料，許多地區都會要求這項政策。不要聲稱你沒有的認證（例如 SOC 2、HIPAA）。
• 應做： 你有一個管道可以接收安全問題的回報，並且知道如何快速輪換所有金鑰。

如果想在安全以外，做更全面的上線前檢查，請參見如何將 AI 原型推進到正式上線。

何時該請專業人員審查

檢查清單能抓出常見錯誤，但無法取代專家。以下情況可以考慮付費進行審查：你自行處理信用卡號，而不是透過託管的結帳頁面；你儲存健康、金融或兒童資料；你的客戶會要求填寫安全問卷；或是資料外洩會造成嚴重傷害。如果你的程式碼可以匯出，審查會容易許多。

在 Mythex 上建置時的安全性

Mythex 沒有內建安全掃描面板，因此你應該遵循上述的檢查清單。以下幾點有助於提升安全性：

• 專案密鑰。 將金鑰儲存在專案設定 → 密鑰中，或透過代理在對話中顯示的密鑰卡片儲存，這樣金鑰就不會出現在你的程式碼或訊息中。變更正式應用程式的密鑰後，請重新發布。
• 計畫模式與詢問模式。 請代理在不編輯的情況下檢查權限：「在詢問模式下，列出每個 API 路由，以及它執行的權限檢查。」
• /test 會讓代理以使用者身分在你的預覽中操作，適合用來進行第 2 節中的雙帳號測試。
• 檢查點讓你可以回復導致問題的變更。

更多資訊請參見文件中的為你建置的應用程式設定安全性與環境變數與密鑰。如果你接下來要新增使用者帳號，請先閱讀如何為應用程式加入登入功能。

常見問題