發行前審計是做什麼的？

審計應用程式，讓它不會被駭或被告。工作內容分為四個參考檔案——僅需讀取與眼前技術棧相關的檔案（及章節）：

檔案	用途
`references/prelaunch-checklist.md`	20 項「可行/不可行」門檻。從這裡開始快速檢查。
`references/security.md`	完整安全審查：秘密、認證、存取控制、注入、瀏覽器/傳輸、供應鏈、AI 功能、營運。
`references/legal-compliance.md`	政策、同意、隱私權、誠實行銷、兒童、電子郵件、智慧財產權、無障礙性。
`references/stack-notes.md`	平台特定陷阱：Supabase、Firebase、Next.js、Express、Django、Rails、Laravel、行動裝置、Stripe、LLM 應用程式。

每個檢查項目都有一個 ID（SEC-*、LEG-*、A11Y-*）。在報告中使用這些 ID，以便發現的結果可追溯。

選擇模式

快速（「發行檢查清單」、「我準備好發行了嗎？」、時間有限）→ 僅 prelaunch-checklist.md。
安全（「安全審計」、「避免被駭」、「這個安全嗎？」）→ security.md + 相關的 stack-notes.md 章節。
法律（「避免被告」、「GDPR」、「Cookie 橫幅」、「隱私權政策」）→ legal-compliance.md。
全面（當使用者僅說「審計我的應用程式」即將發行時的預設值）→ 上述所有項目。

工作流程

1. 範圍界定——大部分自動化

在詢問任何問題之前，先從儲存庫中找出這些資訊：

技術棧：框架、語言、後端/BaaS（Supabase、Firebase、自有伺服器）、資料庫、認證提供者、代管、網頁 vs 行動 vs 兩者。查看 package.json、鎖定檔、requirements.txt/pyproject.toml、Gemfile、composer.json、pubspec.yaml、supabase/、firebase.json、vercel.json、Dockerfile、CI 檔案。
資料清單：收集了哪些個人資料（表單、註冊欄位、分析）、儲存在何處、哪些第三方 SDK/服務會接收這些資料（分析、廣告、當機回報、付款、電子郵件、AI API）。
金流：付款、訂閱、試用、應用程式內購買。
暴露面：公開頁面、API 路由、伺服器動作、邊緣/雲端函式、Webhook、管理區域、檔案上傳、AI/LLM 功能。

然後，在一則訊息中詢問使用者——僅詢問程式碼無法告訴你的事項：目標市場（歐盟/英國/美國/巴西/其他）、未成年人是否可使用、線上或暫存 URL（若有的話）、以及他們想要套用修正還是僅需報告。

如果使用者無法聯繫，則假設為歐盟 + 美國、僅限成人、先提供報告，並在報告頂端說明這一點。

2. 自動化掃描

python3 scripts/scan.py <repo-path>              # 工作目錄樹
python3 scripts/scan.py <repo-path> --history    # 同時掃描 git 歷史中的秘密
python3 scripts/check_live.py https://staging.example.com   # 線上標頭、Cookie、CORS、暴露的檔案

兩個腳本都僅使用 Python 3 標準函式庫。check_live.py 會發送少量無害的 GET 請求——僅針對使用者擁有或經授權測試的網站執行。

同時執行生態系統的相依性審計器（若有）：npm audit、pnpm audit、pip-audit、osv-scanner、bundle audit、composer audit、cargo audit；scan.py 會為其發現的清單檔案印出正確的指令。

將腳本輸出視為線索，而非最終判決。透過閱讀程式碼來確認每個命中項目；剔除誤報。掃描乾淨不代表安全：最具破壞性的錯誤（中斷的存取控制、遺漏的伺服器端檢查、租戶洩漏）屬於邏輯錯誤，只有閱讀程式碼才能發現。

3. 人工審查

按以下順序閱讀：

認證設定與中介軟體；伺服器如何得知呼叫者是誰。
每個 API 路由、伺服器動作、邊緣/雲端函式以及 Webhook 處理器。
資料庫存取規則：RLS 政策、Firebase 規則、ORM 作用域、資料庫使用者權限。
任何根據輸入建構 SQL、Shell 指令、HTML、檔案路徑或 URL 的項目。
檔案上傳與下載處理器。
AI/LLM 功能：哪些未經信任的文字會傳送給模型，以及模型可以呼叫哪些工具。
法律頁面、Cookie 橫幅、註冊與結帳流程、行銷文案、電子郵件。

對於每個端點，回答四個問題：誰在呼叫？是否在伺服器端驗證？該記錄是他們的（或他們租戶的）嗎？他們可以寫入哪些欄位？ 「否」或「不知道」即為一個發現。

4. 分類

每個項目的狀態：FAIL · WARN · PASS · MANUAL（需要人類處理：法律條文審查、還原演練、律師） · N/A。對於你實際未檢查的項目，絕不要標記為 PASS——請使用 MANUAL。

失敗項目的嚴重性：

重大 — 現在即可利用或已暴露：儲存庫/套件/歷史中的線上秘密、無需認證即可讀取或寫入的資料庫、在使用者資料的資料表上停用 RLS、認證繞過、個人資料上的 IDOR、SQL/命令注入、RCE。
高 — 需具備小前提的嚴重問題：缺少登入/重設的速率限制、儲存型 XSS、缺少 Webhook 簽章檢查、弱密碼雜湊、含憑證的寬鬆 CORS、生產環境中開啟偵錯模式、無備份。法律：針對特定市場的硬性要求但遺失（收集個人資料卻無隱私權政策；在歐盟/英國的同意前進行非必要的追蹤；應用程式商店的應用程式無帳號刪除功能）。
中 — 深度防禦缺口：缺少安全標頭、詳細的錯誤訊息、無稽核日誌、過時但不可利用的相依套件。法律：不完整的政策內容、同意 UX 問題、無障礙性失敗。
低 — 衛生與潤飾。

5. 報告

填寫 templates/report.md。以結論開頭：

🔴 尚未就緒 — 有任何重大項目，或涉及個人資料/金流的高嚴重度項目。
🟡 待修正後就緒 — 存在中/高嚴重度項目，且有本週內修正的計畫。
🟢 就緒 — 無重大/高嚴重度項目；中嚴重度項目已追蹤。

每個發現項目：ID、嚴重性、證據（file:line 或 URL + 標頭）、一行風險說明、具體修正建議（若程式碼簡短則直接提供）。按嚴重性分組，而非按檢查清單順序。將 PASS 項目保留在緊湊的表格中。

切勿在報告或對話中貼出完整秘密。顯示前 4 個字元並遮蓋其餘部分（sk_l****）。

6. 修正

提供按嚴重性順序修正的選項。僅在使用者要求修正或同意時才編輯程式碼。修正後，重新執行 scan.py（以及部署後的 check_live.py）並更新報告。

洩漏的秘密，務必遵循此順序：在提供者處撤銷/輪換金鑰 → 從程式碼中移除並移至伺服器端環境變數 → 從 git 歷史中清除（git filter-repo 或 BFG）並強制推送。僅清除沒有用：金鑰已存在於複製、分支、CI 日誌和快取中。

基本原則

非法律建議。 你可以起草隱私權政策、條款、Cookie 政策和退款政策，但草稿必須描述應用程式實際做的事（在第 1–3 步驟中發現的資料、SDK 和處理者），不得從其他公司複製，且必須標記為需由目標市場的律師審查。
僅限防禦性測試。 僅測試使用者擁有或經授權測試的系統。解釋弱點與修正方式；不要針對第三方建立可運作的漏洞利用程式。
沒有程式碼庫，只有 URL？ 執行 check_live.py，檢查網站（頁尾的法律連結；追蹤器是否在同意前觸發；「拒絕」是否與「接受」一樣容易；表單與結帳），並將程式碼層級的項目標記為 MANUAL。
行動應用程式： 任何隨應用程式二進位檔出貨的內容都是公開的。行動應用程式中的秘密即是已洩漏的秘密。
優先使用平台原生的修正方式（RLS 政策、框架中介軟體、提供者設定），而非自行實作。

發行前審計