拒絕資料裸奔！Vibe Coding 必備 Firebase App Check 安全防護指南

開始透過 Vibe Coding 搭配 Firebase Realtime Database 作為資料庫之後，最令人擔心的莫過於資料變更、被惡意爬取或非法寫入，這篇教學會介紹 Firebase 的超強防護機制：「App Check」，App Check 不僅能維持 Vibe Coding 的開發節奏，還可以同時確保「資料安全」，為雲端資料庫加上一層最強防護罩。

快速導覽：

• Firebase 常見的保護資料方式
• 認識 App Check 與 reCAPTCHA
• 為什麼 Realtime Database 不使用基本 API Token 進行保護？
• 為什麼 Realtime Database 要使用 App Check 進行保護？
• 前往 Google Cloud Platform 啟用 reCAPTCHA
• 使用 App Check 保護雲端資料庫
• Vibe Coding 測試 App Check 是否運作
• Vibe Coding 保護指定網域的讀寫

Firebase 常見的保護資料方式

下方列出開發者在保護 Firebase 雲端資料時，最常用到的幾種「防線」，了解它們各自的角色與侷限性，就會明白為什麼 App Check 是維護安全性的最後一塊拼圖：

• 身分驗證 ( Authentication )

  要求使用者登入後才能存取資料，但許多網站都會希望不用登入就能顯示內容。

• 不登入但限制來源

  透過「網域、IP」等限制，讓資料庫只能在特定網域讀取或寫入，這需要仰賴後台的白名單機制或 API Key 的限制，但如果沒有設定好，極易被駭客透過工具偽造，難以完全阻擋有心的非法請求。

• 安全規則 ( Security Rules )

  Firebase 的核心安全性規則，但邏輯撰寫有時較為繁瑣。

• App Check 應用程式驗證

  不只驗證使用者「是誰」，更進一步驗證請求的「來源設備與程式」是否合法，從源頭杜絕了所有非法的模擬請求。

認識 App Check 與 reCAPTCHA

Firebase App Check 是一種強大的安全防護層，它將安全性的邊界從「身分驗證」（ 是誰 ）擴展到「請求來自哪裡」，簡單來說，App Check 能確保發往 Firebase 的請求並非來自自動化腳本、爬蟲或未經授權的第三方網頁，而是源自於使用者親手打造、且受認可的應用程式。

而 App Check 又與 reCAPTCHA 的關係密不可分，在 Web 環境中，reCAPTCHA ( v3 或 Enterprise 版 ) 會先擔任了關鍵的「證明提供者」( Attestation Provider ) 角色，只要通過 reCAPTCHA 驗證，App Check 才會確認身份，讓資料可以讀取，這種機制最迷人之處在於它對使用者幾乎是「隱形」的，不需要擾人的圖形驗證跳窗，完全符合 Vibe Coding 追求的無障礙與極速體驗。

下方 reCAPTCHA 的一些簡單介紹：

• 無聲的守門員

  當使用者與應用程式互動時，reCAPTCHA 會在背景分析這次行為，判斷這是一個真實的人類操作還是惡意腳本。

• 證明與授權

  一旦 reCAPTCHA 確認請求合法，它會向 App Check 提供一個證明，App Check 隨即簽發一個具時效性的「Token」( 金鑰 )。

• 自動驗證

  這個 Token 會自動附帶在 Realtime Database 請求中，請求抵達 Firebase 時，系統會檢查這個 Token，只有持有合法Token 的請求才會被允許通過。

為什麼 Realtime Database 不使用基本 API Token 進行保護？

由於 Google 的專案也提供了 API Token 的防護機制，所以大多數人在剛入門 Realtime Database 時，往往會先嘗試使用 API Token 保護資料，以為幫 API Key 設定了「網域綁定」就安全了，但實際上這卻是一個常見的誤會，單純依賴 API Token 有以下致命限制：

• API Key 僅用於識別而非授權

  Firebase 的 API Key 本質上是為了「讓 Google 知道要把帳單算在誰頭上」，它並不是用來保護資料內容的門票。

• Referer 標頭極易偽造

  網域綁定是基於瀏覽器發送的 Referer HTTP 標頭。然而，駭客只要使用簡單的腳本 ( 例如 Python 的 requests 或 Node.js ) 甚至是一個可以模擬 HTTP Request 的 Postman工具，就能輕易地在 Header 中加入假的 Referer。

• 瀏覽器網域限制仍然可能失效

  Realtime Database 主要是透過 WebSocket 進行通訊，而 API Key 的網域限制只對標準的 HTTP 請求有效，而且 Firebase SDK 在初始化後，資料流的傳輸往往能避開這些初級的標頭檢查，因此就算在 A 網域設定了限制，在 B 網域仍然能順利讀寫資料。

• 前端程式碼全公開

  任何打開網頁的人，都能在原始碼中找到 API Key。

為什麼 Realtime Database 要使用 App Check 進行保護？

由於單純使用 API Token 會有不少安全性的誤會，進而造成不利資料庫安全的狀況，因此需要改用 App Check 進行保護，使用 App Check 能有下列優勢：

• 後端加密驗證

  採用後端驗證機制，不再依賴前端容易被偽造的 Referer 標頭。

• 不可偽造的 Token

  檢查由 Google 簽署、具時效性且無法被第三方模擬的證明 ( Attestation Token )。

• 強制拒絕機制

  如果請求中缺乏經過 reCAPTCHA 認證的合法 Token，Firebase 資料庫端會直接拒絕連線，無視任何正確的 API Key 或偽造的標頭。

前往 Google Cloud Platform 啟用 reCAPTCHA

在進行所有安全性防護之前，需要先建立 Firebase 專案，參考「開始使用 Firebase Realtime Database」教學，註冊並登入 Firebase，建立一個 Firebase 專案，確認可以順利讀取和寫入資料。

使用 App Check 需要搭配 reCAPTCHA，reCAPTCHA 需要前往 Google Cloud Platform ( Google 雲端平台 ) 才能啟用，點擊下方網址，使用自己的 Google 帳號登入 Google Cloud Platform，第一次使用時會出現下方的畫面。

前往：https://console.cloud.google.com/

進入 Google Cloud Platform 之後點擊左上角「選取專案」，選取自己剛剛建立的 Firebase 專案。

進入專案之後，從左側選單選擇「安全性 > reCAPTCHA」。

進入 reCAPTCHA 啟用畫面後，點擊「啟用」。

完成後繼續點擊「設定 reCAPTCHA 防護機制」。

在防護機制中，加入要限制的網域，通常在測試階段會加入「localhost」，如果會將 Vibe Coding 的網頁部署到 Github，就要將 Github 的網址加入 ( 參考「使用 GitHub 部署你的網頁作品」 )。

完成後會出現下圖的畫面，點擊右上方「編輯金鑰」。

接著就能看到這個金鑰的 ID 和 Secret Key，ID 是金鑰的識別代碼，Secret Key 是要提供給 App Check 的認證碼，點擊 Reveal 可以看到完整代碼，這兩組代碼在後續的步驟都會用到。

使用 App Check 保護雲端資料庫

完成 reCAPTCHA 的設定並取得 ID 和 Secret Key 之後，接下來就要開始在 Vibe Coding 的過程中導入 App Check，參考「建立 Firebase 應用程式」，在剛剛剛啟用 Firebase 專案裡建立一個應用程式，並且可以看到這個應用程式的設定碼。

在 Firebase 專案裡，點擊左側選單「App Check」，點擊「開始使用」。

進入 App Check 介面後，切換到「應用程式」頁籤，在剛剛的應用程式後方點擊「註冊」，表示 App Check 會對這個應用程式進行寶檢查和防護的動作。

註冊時展開 reCAPTCHA 項目。

在 reCAPTCHA 密鑰的位置，填入剛剛在 Google Cloud Platform 中 reCAPTCHA 金鑰裡面的 Secret Key，完成後點擊儲存。

如果 reCAPTCHA 前方出現「打勾」圖案，右上方出現「已註冊」，表示 App Check 完成註冊應用程式。

切換回 API 頁籤，可以看見 Realtime Database 後方出現「未強制執行」的說明文字，表示 APP Check 已經開始運作，只是沒有「強制執行」防護動作。

Vibe Coding 測試 App Check 是否運作

如果 App Check 都設定完成，接下來就進入 Vibe Coding 的步驟，使用下列提示詞產生一個網頁，由於 AI 的自動保護機制，無法直接提供 Token、ID 等隱私資訊，因此可以先請 AI 產生假的資料，完成後自行替換成真實資料。

我已經使用 app check 和 reCAPTCHA 限制 Firebase Realtime Database，請幫我按照下列規則，用畫布幫我產生一個網頁：
- 使用基本的 html 和 js，不要套用任何框架和樣式。
- 畫面中有一個多行輸入欄位，以及一個「送出」按鈕和一個「重填」按鈕。
- 如果輸入欄位沒有內容，無法點擊按鈕。
- 如果輸入欄位有內容按下「送出」會把內容儲存到 Firebase realtime 資料庫。
- 如果輸入欄位有內容，按下「重填」會把輸入欄位清空。
- 下方輸入欄位和按鈕的下方有一個清單，顯示儲存後的資料。
- 不需要使用任何登入機制。
- 我會把資料存到我自己的 Firebase realtime database，請先用假的測試網址。
- 不要使用 Firebase Firestore。

如果 AI 已經可以正常產生網頁，參考「下載 Vibe Coding 網頁程式碼」教學的做法，下載並用編輯器打開程式碼，並把假資料換成自己的資訊。

• Firebase 設定區域：換成 Firebase 應用程式的設定代碼 ( 參考：建立 Firebase 應用程式 )
• reCAPTCHA 區域：換成 reCAPTCHA 的 ID 代碼。

完成後可以使用像是 JSBin 等線上編輯器測試網頁，因為網域並不是剛剛 reCAPTCHA 所設定的合法網域，所以雖然可以讀寫，在網頁開發模式卻會出現 App Check 的錯誤訊息，這表示 App Check 有正常運作，只是因為剛剛沒有強制執行，所以還是可以讀寫。

回到 App Check 的 API 頁籤，點擊 Realtime Database。

點擊 Realtime Database 後可以看見 App Check 對於這個資料庫的防護狀況，稍作等待後重新整理畫面 ( 此處的畫面並不是即時更新 )，就可以看見剛剛使用 JSBin 開啟的網頁，雖然可以讀寫，但是 100% 都是「未經驗證的要求」，這表示 App Check 有順利攔截到所有不合規定的連線。

Vibe Coding 保護指定網域的讀寫

確認 App Check 可以保護資料庫之後，接下來就可以點擊「強制執行」，正式啟用 App Check 防護。

強制執行後，大約等待幾分鐘，就會套用對應的保護措施。

完成後在右上角會看見「已強制執行」的圖示，表示開始強制執行防護。

等待幾分鐘讓強制執行生效 ( 約 3~5 分鐘 )，回到 JSBin 重新整理剛剛的網站內容，因為網域並不是剛剛 reCAPTCHA 所設定的合法網域，又強制執行 App Check，就無法正常讀寫資料，在網頁開發者工具裡也會看見被阻擋的錯誤訊息。

如果切換到 reCAPTCHA 所設定的合法網域，就可以讀寫資料，在開發者工具中也不會出現錯誤訊息。

過一段時間後再回到 App Check 裡觀察防護狀況，就可以發現有些是「已驗證的要求」，有些是「未驗證的要求」，表示 App Check 已經正式對資料庫進行「合法網域」的防護。

結語

在享受 Vibe Coding 帶來的靈感噴發與即時同步時，只要透過 Firebase App Check，就不再需要擔心資料庫淪為駭客的遊樂場，現在，就為 Vibe Coding 的資料庫加上這層最強防護，讓創意在安全的環境下自由流動！

意見回饋

如果有任何建議或問題，可傳送「意見表單」給我，謝謝～