快速摘要
用 AI 生成一個網站現在可能只要幾十分鐘，但 AI 生成的程式碼不會主動幫你考慮資安。這篇文章整理一份上線前的檢查清單，涵蓋前端、驗證機制、API、部署環境、套件依賴五大類，每一項都附上為什麼重要，以及怎麼檢查。清單最後附上幾個可以直接執行的指令和免費工具，方便你在上線前跑一輪。
為什麼 AI 生成的網站有特殊風險
AI 模型生成程式碼的方式，是根據訓練資料裡看過的程式碼模式來預測下一段合理的內容，它不是在幫你做資安風險評估。這代表幾件事。
模型看過的程式碼裡，有大量寫法本身就存在已知弱點，例如用 MD5 雜湊密碼、CORS 設成允許所有來源、把 API 金鑰直接寫在前端程式碼裡。這些寫法在網路上到處都是，模型學到了，也就可能生成出來。
模型的訓練資料有時間點，訓練截止之後出現的資安建議或新版函式庫的安全用法，模型不一定知道，可能還在用比較舊的做法。
更關鍵的是，用 AI 生成網站的人，很多時候本身不是工程背景，看到程式碼能跑就覺得沒問題，不會意識到裡面藏著資安風險。這種情況在 Vibe Coding 場景特別常見，因為整個流程的賣點就是不用懂程式碼也能做出網站，但資安風險不會因為你不懂程式碼就不存在。
以下清單就是為了補上這一段落差設計的，每個項目都盡量寫成不需要深厚工程背景也能自己檢查的方式。
前端安全
第一項，沒有使用者可控資料的 inline JavaScript。如果網站的某個地方會把使用者輸入（表單內容、網址參數）直接組進 HTML 或 JavaScript 裡輸出，就有 XSS（跨站腳本攻擊）風險，攻擊者可以注入自己的腳本，在其他使用者的瀏覽器裡執行。檢查方式是搜尋程式碼裡有沒有把使用者輸入直接塞進 innerHTML、document.write、或是字串拼接後直接輸出成 HTML。
第二項，設定 Content Security Policy（CSP）標頭。CSP 可以限制網頁只能載入你指定來源的腳本和資源，就算真的被注入了一段惡意腳本，CSP 也能擋下它執行或對外連線。檢查方式是打開瀏覽器開發者工具的 Network 分頁，看 Response Headers 有沒有 Content-Security-Policy 這個欄位，或是用指令：
curl -I https://yoursite.com
看回應標頭裡有沒有這一項。
第三項，外部腳本要加上 SRI（Subresource Integrity）驗證。如果你的網站從 CDN 載入第三方 JavaScript，加上 integrity 屬性可以確保萬一 CDN 被入侵、檔案內容被竄改，瀏覽器會拒絕執行，不會默默載入被動過手腳的程式碼。
第四項，HTML 註解和 data 屬性裡不能有敏感資料。AI 生成程式碼時，有時候會在註解裡留下除錯用的說明，甚至不小心把測試用的帳號密碼、內部 API 路徑寫進去。這些內容在瀏覽器檢視原始碼就看得到，等於公開給所有人看。上線前建議直接搜尋整份程式碼裡有沒有 TODO、password、secret、api_key 這類字眼。
第五項，表單要有 CSRF（跨站請求偽造）防護。沒有 CSRF token 的表單，攻擊者可以誘騙已登入的使用者在不知情的狀況下送出偽造請求，做出使用者原本沒打算做的操作，例如變更密碼或轉帳。
驗證機制（如果網站有登入功能）
第一項，密碼要用 bcrypt 或 Argon2 雜湊，不能用 MD5 或 SHA1。MD5 和 SHA1 運算速度太快，現代硬體可以用暴力破解或彩虹表快速反推密碼，bcrypt 和 Argon2 刻意設計得運算緩慢，大幅提高破解成本。
第二項，Session token 要設定 httpOnly、secure、sameSite 三個屬性。httpOnly 讓 JavaScript 無法讀取這個 cookie，降低 XSS 攻擊竊取 token 的風險。secure 確保 cookie 只在 HTTPS 連線下傳輸。sameSite 可以降低 CSRF 攻擊的效果。三個屬性都應該同時設定，缺一個都會留下漏洞。
第三項，登入端點要有速率限制（Rate Limiting）。沒有限制的登入表單，攻擊者可以寫程式無限次嘗試帳號密碼組合，也就是暴力破解攻擊。合理的做法是同一個帳號或同一個 IP 短時間內失敗次數過多就暫時鎖定。
第四項，前端程式碼裡不能出現任何真實帳密或金鑰。這聽起來是常識，但 AI 生成的範例程式碼經常會示範性地寫死一組帳密方便測試，如果沒有清乾淨就直接上線，等於把測試帳號公開給所有人。
API 安全
第一項，API 金鑰不能出現在前端程式碼裡。任何在瀏覽器裡執行的 JavaScript 都可以被使用者打開開發者工具看到原始碼，如果你的第三方服務金鑰（地圖 API、AI 模型 API、金流 API）寫在前端，等於直接公開給所有訪客，可能被盜用產生你的帳單。正確做法是這類呼叫要透過你自己的後端伺服器轉發，金鑰只存在伺服器端環境變數裡。
第二項，CORS 設定要指定明確的來源，不能用萬用字元 *。CORS 設成 * 代表任何網站都可以呼叫你的 API，如果你的 API 需要驗證身分或處理敏感資料，這樣設定會讓其他惡意網站也能夾帶使用者的登入狀態發送請求。
第三項，所有端點都要做輸入驗證。不管是表單資料還是 API 參數，都要在伺服器端驗證格式、長度、型別，不能只信任前端做的驗證，因為前端驗證可以被繞過，攻擊者可以直接對 API 發送請求，跳過網頁介面。
第四項，API 呼叫要有速率限制，避免被大量重複呼叫拖垮伺服器資源，或是被用來做資料爬取。
部署環境
第一項，HTTPS 要啟用並強制導向。沒有 HTTPS，使用者和伺服器之間傳輸的所有資料，包含帳號密碼，都可能在傳輸過程被攔截讀取。現在大部分主機和 CDN 服務（Cloudflare、Vercel、Netlify）都能免費申請並自動更新憑證，沒有理由不開。
第二項，.env 檔案不能進到 git 版本控制裡。.env 通常存放資料庫密碼、API 金鑰等機密資訊，一旦提交進 git，即使之後刪除，舊的 commit 紀錄裡還是找得到，尤其如果這個 repo 是公開的，等同直接外洩。檢查方式：
git log --all --full-history -- .env
cat .gitignore | grep .env
確認 .env 有被列在 .gitignore 裡，而且沒有任何一次 commit 紀錄包含過這個檔案。
第三項，正式環境要關閉除錯模式（Debug Mode）。開發框架的除錯模式通常會在出錯時顯示詳細的錯誤堆疊、檔案路徑、甚至環境變數內容，這些資訊對攻擊者來說是很好用的偵查線索，正式環境一定要關閉。
第四項，錯誤頁面不能洩漏堆疊追蹤（Stack Trace）。使用者觸發錯誤時看到的應該是一般化的錯誤訊息，而不是完整的程式碼路徑和技術細節。
第五項，目錄列表功能要關閉。如果伺服器設定沒有處理好，使用者直接瀏覽某個資料夾路徑時，可能會看到該資料夾底下所有檔案的清單，包含不應該被公開存取的檔案。
套件依賴
第一項，跑一次套件的資安掃描，確認沒有嚴重等級的已知漏洞：
npm audit
或是 Python 專案：
pip-audit
第二項，套件版本要鎖定在 lockfile 裡（package-lock.json、poetry.lock 或同等檔案），確保每次部署安裝到的套件版本一致，不會因為某個依賴套件無預警更新而引入未知風險。
第三項，移除不必要的套件。AI 生成專案時有時候會多裝一些其實用不到的函式庫，每多一個依賴套件，就多一分潛在的供應鏈風險，定期清理沒在用的套件是好習慣。
Vibe Coding 情境下額外要注意的事
如果整個網站是透過和 AI 對話生成，而你自己並不完全理解每一段程式碼在做什麼，風險會比一般開發情境更高，因為你沒辦法用經驗直接判斷「這段看起來怪怪的」。這種情況下，建議至少做兩件事。
第一，把生成出來的程式碼拿去問另一個 AI 對話「這段程式碼有沒有資安風險，逐項列出來」，用不同的角度交叉檢查一次，比只信任第一次生成的結果安全得多。
第二，把這份清單當成上線前的固定流程，而不是憑印象覺得「這次應該沒問題」。清單存在的意義，就是在你不確定該檢查什麼的時候，還是有一個可以照著做的步驟。
快速自動化檢查指令
搜尋程式碼裡有沒有硬寫的金鑰或機密字串：
grep -rniE "api_key|secret|password\s*=|token\s*=" --include="*.js" --include="*.py" --include="*.env*" .
檢查套件漏洞：
npm audit --audit-level=high
檢查正式環境的回應標頭是否有安全設定：
curl -I https://yoursite.com
看回應裡有沒有 Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options 這幾個標頭。
推薦工具
Lighthouse 內建在 Chrome 開發者工具裡，除了效能分數，也會標出一部分基本的安全建議，是最容易上手的第一步。
OWASP ZAP 是免費的開源安全掃描工具，可以對網站做自動化的弱點掃描，包含 XSS、SQL Injection 等常見弱點類型，快速掃描模式幾分鐘就能跑完，適合上線前做一次基本檢查。
Mozilla Observatory 是線上工具，輸入網址就能檢查 HTTP 安全標頭設定得完不完整，並給出評分和具體改善建議，操作起來比架設 OWASP ZAP 簡單很多，適合不熟工具的人優先使用。
安全性考量
這份清單的目的是覆蓋大部分常見情境，但不代表跑完清單就萬無一失。清單型檢查適合抓出已知類型的問題，沒辦法取代真正的滲透測試或程式碼審查，如果網站會處理付款、個資或企業內部資料，建議在清單之外，額外找專業資安人員或團隊做一次正式的安全測試。另外，清單需要跟著技術演進更新，今天列出的項目，幾年後可能有新的攻擊手法或新的防護標準需要補進來，不建議把這份清單當成一次性檢查，而是每次網站有重大改版時都重新跑一遍。
知識檢測
讀完文章後，測試一下你對這個主題的理解。
常見問題
用 AI 生成的網站一定比較不安全嗎
不一定，關鍵在於有沒有做上線前的檢查。AI 生成的程式碼品質取決於訓練資料和提示方式，有問題的模式確實比較容易出現，但只要照清單檢查過一輪，風險可以降到和人工開發相近的水準。
這份清單要花多久跑完
如果是一個中小型的靜態網站或簡單的表單型網站，熟悉流程後大概三十分鐘到一小時可以跑完前四大類，加上套件掃描通常幾分鐘就有結果。
沒有工程背景，看不懂程式碼怎麼辦
可以把整份程式碼貼給 AI，直接問「這段程式碼有沒有資安風險，請逐項列出並解釋原因」，再對照這份清單確認每一項有沒有被涵蓋到。工具部分（Lighthouse、Mozilla Observatory）都是圖形化介面，不需要看懂程式碼也能操作和判讀結果。
個人小型網站也需要做這麼完整的檢查嗎
視網站有沒有收集使用者資料或處理登入而定。純展示型的網頁（沒有表單、沒有登入），可以優先做前端安全和部署環境兩類，API 和驗證機制相關項目可以之後有需要再補。只要網站開始收集任何使用者資訊，就建議完整跑一次清單。
延伸閱讀
想了解輸出過濾如何補上 AI 應用回應內容的資安缺口，可以參考 AI 輸出過濾的介紹。想了解 AI 生成程式碼常見弱點的成因，可以搭配 AI 護欄與 Prompt Injection 相關文章一起閱讀。