安全審計與機密管理：在 Cloudflare 中保護你的 API 金鑰與環境變數

在現代 Web 開發中，「代碼洩漏」往往不可怕，可怕的是「機密 (Secrets) 洩漏」。一旦你的 OAuth Client Secret 或資料庫金鑰在 GitHub 上曝光，整個應用的安全性將瞬間瓦解。

由於 DueWise 是一個結合了多種雲端服務（Google Auth, Push APIs, D1 DB）的應用程式，機密管理是我們工作的重中之重。這篇文章將分享我們在 Cloudflare 與 GitHub 上的零安全風險實務。

1. 絕不將 .env 提交到版本控制

這是最基礎、也最常被忽視的一條。我們在 .gitignore 中明確排除了所有的 .env 檔案。

# .gitignore
.env
.env.*
!.env.example # 僅保留一個範本供開發者參考

我們提供了一個 .env.example 檔案，裡面僅包含鍵名而不包含實際數值，這讓新加入的開發者能快速知道需要配置哪些環境變數。

2. Cloudflare Pages 的機密注入

在生產環境中，機密是不應該存在於伺服器磁碟上的。我們直接在 Cloudflare Pages 的儀表板中管理這些敏感數據：

• 環境變數 (Environment Variables): 這裡存放如 VAPID_PUBLIC_KEY 這類可以公開但需配置的內容。
• 機密 (Secrets): 這裡存放如 GITHUB_CLIENT_SECRET 或 PUSH_TRIGGER_SECRET。

這些數值在編譯與執行時，會透過 Astro.locals.runtime.env (在 SSR 模式下) 安全地注入到我們的程式碼中，駭客即便入侵了託管平台，也難以直接讀取這些加密存儲的數值。

3. JWT 的安全簽署

DueWise 的 Session 管理使用了 JWT。這依賴於一個核心金鑰：AUTH_SECRET。

我們強制要求這組金鑰必須是經由加密算法產生的長隨機字串。我們在部署流程中加入了一道審計腳本，如果偵測到 AUTH_SECRET 的長度不足或太過簡單，CI 會自動拒絕發布。

4. API 的存取控制：推送觸發金鑰

為了防止推播 API 被濫用，我們實作了 PUSH_TRIGGER_SECRET 的二段式驗證：

1. 用戶端: 必須具備有效的登入 Session。
2. 觸發者: 如果是系統自動觸發（如每日提醒），必須在 Header 帶上極高權限的金鑰。

這種架構確保了即使有人知道了我們的推播 API 端點，沒有這組金鑰也無法發送任何訊息給用戶。

5. D1 資料庫的安全邊界

Cloudflare D1 天然具備安全性，因為它只能被同一個 Account 下的 Worker/Pages 直接調用。外部網路無法直接通過 TCP 連接到我們的 SQLite 資料庫。

這極大地減少了 SQL 注入以外的攻擊面。在代碼層面，我們嚴格遵守 參數化查詢 (Parametric Queries)，絕不直接拼接 SQL 字串，從根本上杜絕了 SQL 注入風險。

6. 個人見解：安全是開發者的直覺

作為開發者，我們應該養成一個習慣：「任何時候，只要你手動輸入一個 Secret 到代碼檔案裡，你就已經做錯了。」

在 DueWise 的開發過程中，我們建立了一種開發紀律：新功能的環境變數必須先在開發端的系統層級配置好，代碼中只能引用。這種對安全的敬畏之心，讓我們在快速迭代功能時，能始終保持後防線的穩固。

結論

安全不是一個功能，它是一系列持續不斷的實踐。透過完善的機密管理與 Cloudflare 同樣高等級的安全架構，DueWise 為用戶提供了一個不僅好用、而且絕對可信賴的隱私空間。

這是 DueWise 技術系列文章的最後一篇。感謝您與我們一同探索現代 PWA 的奧秘，希望這些實戰經驗能啟發您開發出更棒的應用。