API Key 外洩後是否一定要重新產生?判斷標準、輪替步驟與例外情況

API Key 不小心出現在網站原始碼、GitHub、公開文件、聊天群組或教學影片中,是否一定要重新產生?

原則上,只要 API Key 已經離開原本受控制的使用環境,或無法確定是否曾被第三方取得,最安全的處理方式就是建立新的 API Key、更新系統,再刪除舊金鑰

Google Cloud 官方針對疑似遭入侵的 API Key,建議建立新的金鑰、套用與舊金鑰相符的必要限制、將新金鑰更新至所有使用位置,最後刪除舊金鑰。Google 也建議定期輪替 API Key,而不是長期使用同一組金鑰。

不過,並不是所有「在畫面上看見 API Key」的情況,都代表金鑰已遭入侵。

例如 Google Maps JavaScript API 使用於網站前端時,金鑰原本就可能被瀏覽器載入,訪客也可能透過開發者工具看到。這類前端金鑰的安全重點,不是讓金鑰完全不可見,而是正確設定網站來源限制與 API 使用限制。

因此,是否一定要重新產生,要先判斷金鑰的用途、公開範圍、限制設定及是否出現異常使用。


讓更多人搜尋到你的產品?現在有機會免費行銷 20 天!
現在越來越多品牌開始透過 內容行銷,讓產品被 Google 搜尋到。

我們現在開放 20 天免費內容行銷體驗,透過搜尋曝光與內容推廣,幫助你的產品被更多人看見。

API Key 外洩後處理方式快速對照表

外洩情況
是否建議重新產生
風險程度
建議處理
出現在公開 GitHub
一定要
極高
建立新金鑰、更新系統、刪除舊金鑰
貼到公開論壇或社群
一定要
極高
立即輪替並檢查使用量
出現在後端程式原始碼
一定要
極高
重新產生並改用環境變數
寄給不應取得金鑰的人
建議一定要
視為已外洩並立即輪替
收到 Google 外洩警示
一定要
極高
依官方程序重建與撤銷
已出現陌生流量或費用
一定要
極高
先止損,再輪替金鑰
前端地圖金鑰可被看到
不一定
檢查網域與 API 限制
金鑰只出現在私人內部文件
視權限而定
確認存取紀錄與分享範圍
金鑰短暫顯示於線上會議
建議重新產生
無法確認是否被錄影或截圖
金鑰完全沒有限制
建議重新產生
建立有限制的新金鑰取代
測試金鑰已停止使用
建議刪除
不需要保留未使用金鑰
金鑰名稱或用途無法確認
建議重建
盤點用途後重新分配

哪些情況一定要重新產生 API Key?

一、API Key 曾經出現在公開 GitHub

只要 API Key 曾提交到公開 GitHub、GitLab 或其他公開程式碼儲存庫,就應視為已經外洩。

即使後來刪除程式碼,金鑰仍可能存在於:

  • Git commit 歷史紀錄
  • Fork 儲存庫
  • Pull Request
  • 搜尋引擎快取
  • CI/CD 執行紀錄
  • 自動憑證掃描工具
  • 其他人已下載的程式碼

因此,只把該行程式碼刪除並不足以恢復安全。

Google 官方建議在公開程式碼前先確認其中沒有 API Key 或其他私人資訊,並定期建立替代金鑰、更新應用程式後刪除舊金鑰。

正確處理方式是:

  1. 建立新的 API Key。
  2. 設定應用程式限制。
  3. 設定 API 限制。
  4. 更新所有正式與測試系統。
  5. 確認新金鑰正常運作。
  6. 刪除舊金鑰。
  7. 清理 Git 歷史紀錄。

二、已出現陌生流量或異常費用

如果在 Google Cloud 中發現以下情況,代表金鑰可能已被第三方實際使用:

  • API 請求量突然暴增
  • 出現不認識的來源
  • 費用突然增加
  • 出現未使用過的 API
  • 深夜仍持續有大量請求
  • 流量與網站訪客數不成比例
  • Google 寄來異常使用警示

這種情況不能只修改金鑰限制後繼續使用,因為第三方可能已經保存原金鑰。

應直接將舊金鑰視為遭入侵,建立替代金鑰並撤銷舊金鑰。Google 官方的遭入侵憑證處理文件,也明確建議重新建立 API Key、更新所有使用位置,再刪除舊金鑰。


三、後端伺服器金鑰曾被公開

伺服器端 API Key 原本不應被一般使用者看到。

如果後端金鑰出現在:

  • 網站 HTML
  • JavaScript 檔案
  • 公開 API 回應
  • 錯誤訊息
  • GitHub
  • WordPress 公開頁面
  • 教學文件
  • 截圖或影片
  • 可公開下載的設定檔

通常都應立即重新產生。

原因是後端 API Key 往往沒有瀏覽器網域限制,而是透過伺服器 IP 或其他方式限制。若完全沒有設定限制,取得金鑰的人可能從自己的伺服器發送請求。


四、收到 Google 的憑證外洩通知

Google Cloud 可能在偵測到 API Key 被公開於程式碼儲存庫或其他公開位置時,向專案擁有者或安全聯絡人發出通知。

Google 官方指出,偵測到遭入侵 API Key 的警示,可能表示組織不慎將相關金鑰發布在公開儲存庫中。

收到通知後,不應只刪除公開頁面,建議立即:

  1. 確認通知中的專案及金鑰。
  2. 查看 API 使用量及帳單。
  3. 建立替代金鑰。
  4. 套用正確限制。
  5. 更新正式系統。
  6. 刪除舊金鑰。
  7. 檢查是否還有其他憑證外洩。

五、API Key 傳給無法信任或無法追蹤的人

例如:

  • 傳給已離職的工程師
  • 傳給不再合作的廠商
  • 貼到多人聊天群組
  • 透過未加密方式寄送
  • 上傳至公開雲端資料夾
  • 放入任何知道連結就能查看的文件
  • 顯示在線上會議錄影中

即使目前沒有異常流量,也很難確認金鑰是否被保存、轉傳或截圖。

這種情況最好直接輪替,不要等到產生費用才處理。


哪些情況不一定要重新產生?

一、Google Maps 前端金鑰可在瀏覽器看到

網站使用 Google Maps JavaScript API 時,API Key 通常會隨前端程式載入,所以使用者可能在瀏覽器開發者工具看到。

這並不一定代表金鑰已經遭到盜用。

應檢查該金鑰是否有設定:

  • HTTP 參照網址限制
  • 正確的正式網域
  • 正確的子網域
  • 僅允許必要的 Google Maps API
  • 合理的 API 配額

例如只允許:

https://example.com/*
https://www.example.com/*

而不是允許:

*
https://*

如果前端金鑰一直都有正確限制、沒有異常流量,也沒有被放到其他不相關位置,可以不一定立即更換。

但若無法確認限制是否完整,建立新的受限金鑰通常仍是較穩妥的做法。


二、金鑰只在受控的內部環境中顯示

例如 API Key 只存在於:

  • 權限嚴格控管的公司密碼管理工具
  • 僅少數工程師可查看的 Secret Manager
  • 私有 Git 儲存庫
  • 權限受控的內部文件
  • 正式主機的環境變數

這種情況通常不算公開外洩。

但仍應確認:

  • 是否有人員離職
  • 私有儲存庫是否曾誤設為公開
  • 文件分享權限是否正確
  • 是否有不明登入紀錄
  • 是否有大量下載或轉寄
  • 金鑰是否已使用太久

Google 官方仍建議定期輪替 API Key,以降低長期憑證遭洩漏後的風險。


三、只是金鑰名稱或部分字元被看到

如果外部人士只看到:

  • API Key 名稱
  • Google Cloud 專案名稱
  • 金鑰 ID
  • 前後部分遮蔽的金鑰
  • 帳單中的憑證識別碼

而沒有取得完整、可使用的 API Key,通常不需要立刻重新產生。

但應確認截圖或文件中沒有其他位置顯示完整金鑰。


只修改 API Key 限制可以嗎?

可以降低風險,但不能保證解決已外洩的問題。

假設原本未受限制的 API Key 已被第三方取得,後來才加入網站網域限制,攻擊者可能暫時無法繼續使用。

但仍有以下問題:

  • 舊金鑰已經存在於外部
  • 未來限制可能被管理者誤改
  • 不知道金鑰已被多少人保存
  • 可能還有其他允許來源設定錯誤
  • 同一把金鑰可能被不同系統共用
  • 難以確認所有異常使用是否已停止

因此:

若只是預防性強化安全,可以直接增加限制;若已確認或高度懷疑外洩,應重新產生。

Google 官方表示,如果要輪替 API Key,可以建立新金鑰並套用相同限制,將應用程式更新為新金鑰,最後刪除舊金鑰。


API Key 正確輪替流程

步驟一:先確認舊金鑰用途

前往 Google Cloud 憑證頁面:

https://console.cloud.google.com/apis/credentials

確認:

  • 金鑰名稱
  • 所屬專案
  • 使用中的 API
  • 應用程式限制
  • API 限制
  • 正式站或測試站
  • 哪些程式正在使用
  • 是否連結付款帳戶

不要在完全不知道用途時直接刪除,否則可能造成網站、App或後端服務中斷。


步驟二:建立新 API Key

在 Google Cloud Console 中選擇:

API 與服務
→ 憑證
→ 建立憑證
→ API 金鑰

新金鑰建立後,先不要立即放入正式環境,應先完成限制設定。


步驟三:設定應用程式限制

依照使用情況選擇:

網站前端

使用「網站」或 HTTP 參照網址限制。

例如:

https://example.com/*
https://www.example.com/*

伺服器後端

使用固定 IP 位址限制。

Android App

限制:

  • Android 套件名稱
  • SHA-1 憑證指紋

iOS App

限制:

  • Bundle ID

步驟四:設定 API 限制

不要選擇允許所有 API。

應限制為真正需要的服務,例如:

  • Maps JavaScript API
  • Places API
  • Geocoding API
  • Routes API
  • YouTube Data API
  • Generative Language API

不同用途最好使用不同 API Key,不要將網站地圖、後端地址查詢和 App 共用同一把金鑰。


步驟五:更新所有使用位置

常見需要替換的位置包括:

  • WordPress 外掛
  • WordPress 佈景主題
  • JavaScript 程式
  • PHP 程式
  • Node.js
  • Python
  • Java
  • .env 檔案
  • 主機環境變數
  • Cloud Run
  • App Engine
  • Firebase
  • GitHub Actions
  • Make
  • Zapier
  • Android App
  • iOS App
  • 公司內部系統

應建立一份清單,避免遺漏某個舊系統。


步驟六:測試新金鑰

確認以下功能是否正常:

  • 地圖顯示
  • 地址搜尋
  • 地理編碼
  • 路線規劃
  • App 載入
  • 後端排程
  • 自動化流程
  • API 回應
  • 錯誤紀錄

常見錯誤包括:

API_KEY_INVALID
REQUEST_DENIED
RefererNotAllowedMapError
ApiNotActivatedMapError
IpRefererBlocked

如果新金鑰無法運作,通常是網域、IP或 API 限制設定不完整。


步驟七:刪除舊 API Key

確認所有正式系統都已更新後,應刪除舊金鑰。

Google 官方的輪替流程就是先建立替代金鑰、更新應用程式,再刪除舊金鑰。

不要因為舊金鑰暫時沒有流量,就長期保留作為備用。


可以先停用舊金鑰,再慢慢更換嗎?

一般 API Key 的主要處理方式通常是建立新金鑰並刪除舊金鑰。

如果異常費用正在快速增加,可以先採取緊急措施:

  1. 對舊金鑰加入嚴格限制。
  2. 調低相關 API 配額。
  3. 停用不需要的 API。
  4. 必要時立即刪除舊金鑰。
  5. 再建立新金鑰恢復服務。

這可能造成網站或 App 部分功能短暫中斷,但在費用持續增加時,應優先止損。


刪除舊 API Key 後可以復原嗎?

API Key 一旦刪除,通常不應期待能以原字串繼續使用。

因此刪除前應先確認:

  • 新金鑰已部署
  • 正式站已測試
  • App 已更新
  • 後端排程正常
  • 所有自動化流程正常
  • 沒有舊版系統仍依賴該金鑰

不過,若金鑰已確認遭到濫用,即使仍有部分舊系統尚未完成替換,也不應為了維持舊系統而長時間保留外洩金鑰。


API Key 輪替後,舊費用會消失嗎?

不會。

輪替或刪除 API Key 的作用,是阻止後續請求繼續使用舊金鑰,不會自動取消已經產生的 API 使用費。

如果已出現異常費用,應:

  1. 保存帳單明細。
  2. 保存 API 流量紀錄。
  3. 記錄發現外洩的時間。
  4. 記錄輪替及刪除時間。
  5. 檢查專案權限。
  6. 聯絡 Google Cloud Billing 支援。

是否能調整或減免費用,仍需由 Google 依個案審核。


如何確認舊 API Key 已經沒有被使用?

刪除前可先觀察:

  • API 與服務資訊主頁
  • Google Cloud Monitoring
  • 帳單報表
  • 伺服器紀錄
  • 網站錯誤紀錄
  • App 錯誤回報
  • 自動化流程紀錄

但如果金鑰已確認外洩,不建議為了觀察而保留太久。

更安全的做法是:

  1. 建立新金鑰。
  2. 更新所有已知系統。
  3. 測試核心功能。
  4. 刪除舊金鑰。
  5. 再從錯誤紀錄找出遺漏的舊系統。

如何避免下一把 API Key 再次外洩?

1. 不要把後端金鑰直接寫在程式碼中

後端金鑰應放在:

  • 環境變數
  • Secret Manager
  • CI/CD Secret
  • 主機商的祕密設定
  • 權限受控的設定檔

Google 官方建議避免將 API Key 直接寫入原始碼,並在公開程式碼前檢查是否含有憑證。


2. 每個環境使用不同金鑰

建議分開建立:

  • 正式網站金鑰
  • 測試網站金鑰
  • 開發環境金鑰
  • 後端伺服器金鑰
  • Android App 金鑰
  • iOS App 金鑰

若其中一把外洩,只需要處理單一環境。


3. 每把金鑰都加入限制

至少設定:

  • 應用程式限制
  • API 使用限制

Google Cloud 官方也建議限制能使用金鑰的網站、IP 位址或應用程式,並限制能存取的 API。


4. 定期刪除不使用的金鑰

測試完成、網站下線或 App 停止維護後,應刪除不再使用的 API Key。

保留大量用途不明的金鑰,會增加盤點及資安管理難度。Google 官方建議刪除不需要的 API Key,以縮小遭受攻擊的範圍。


5. 定期輪替 API Key

即使沒有明確外洩事件,也可以制定輪替週期,例如:

  • 高風險系統每3個月
  • 一般正式系統每6至12個月
  • 人員離職或廠商更換時立即輪替
  • 專案移交後立即輪替
  • 權限異動後重新檢查

Google 官方並未要求所有一般 API Key 必須使用完全相同的固定天數,但明確建議定期建立新金鑰、更新應用程式並刪除舊金鑰。


常見問題

API Key 外洩但沒有產生費用,也要換嗎?

建議更換。

沒有費用可能只是:

  • 尚未超過免費用量
  • 攻擊者只進行測試
  • 帳單尚未更新
  • 金鑰限制暫時阻擋請求
  • 目前尚未被自動程式掃描到

既然無法收回已公開的完整金鑰,重新產生通常是最安全的選擇。


把 API Key 改名可以解決外洩嗎?

不行。

修改金鑰名稱只會改變管理介面中的標籤,不會改變實際的 API Key 字串。

外部人士仍可繼續使用原有金鑰。


修改限制後,API Key 字串會改變嗎?

通常不會。

加入網域、IP或 API 限制,只會改變金鑰可被使用的範圍,不等於產生新的金鑰。

若金鑰已經外洩,最完整的處理方式仍是建立新金鑰並刪除舊金鑰。


可以建立新金鑰,但暫時保留舊金鑰嗎?

可以短時間並行,以便完成系統切換。

建議流程:

  1. 建立新金鑰。
  2. 設定相同或更嚴格的限制。
  3. 更新正式系統。
  4. 觀察核心功能。
  5. 在明確期限內刪除舊金鑰。

不要無期限保留。


金鑰已設定網域限制,還需要輪替嗎?

若金鑰只用於前端網站、限制正確、沒有異常使用,也沒有出現在其他不適當的位置,可以不必因為訪客能在瀏覽器看到而立即輪替。

但如果它曾被公開到 GitHub、文件或其他不受控制的位置,仍建議重新產生。


Google API Key 和服務帳戶金鑰一樣嗎?

不一樣。

API Key 主要用來識別應用程式或專案;服務帳戶金鑰則可能代表一個具備 IAM 權限的身分。

若外洩的是服務帳戶 JSON 金鑰,風險通常更高。Google 官方建議懷疑服務帳戶金鑰遭入侵時立即輪替。

此時還應檢查:

  • 服務帳戶 IAM 權限
  • Cloud Audit Logs
  • 是否建立陌生資源
  • 是否存取資料庫或儲存空間
  • 是否新增其他憑證

Google 官方重要連結

以下網址請使用一般文字超連結、按鈕或直接顯示網址,不要使用 WordPress「嵌入內容」區塊。

Google Cloud 管理入口

Google Cloud Console
https://console.cloud.google.com/

API 與服務資訊主頁
https://console.cloud.google.com/apis/dashboard

API 憑證管理
https://console.cloud.google.com/apis/credentials

Google Cloud Billing
https://console.cloud.google.com/billing

Google 官方說明文件

API Key 管理說明
https://cloud.google.com/docs/authentication/api-keys

API Key 安全管理最佳做法
https://cloud.google.com/docs/authentication/api-keys-best-practices

API Keys 總覽
https://cloud.google.com/api-keys/docs/overview

處理遭入侵的 Google Cloud 憑證
https://cloud.google.com/docs/security/compromised-credentials

回應 Google Cloud 濫用通知
https://cloud.google.com/docs/security/respond-to-abuse-misuse

限制 API Key 使用範圍
https://cloud.google.com/api-keys/docs/add-restrictions-api-keys

Google Cloud Billing 支援
https://cloud.google.com/support/docs/get-billing-support


結語:無法確認是否外洩,就應採取輪替

API Key 外洩後是否一定要重新產生,可以依兩個原則判斷:

第一,金鑰是否已離開可控制的環境。
只要完整金鑰出現在公開 GitHub、論壇、文件、影片或非受控人員手中,就應重新產生。

第二,是否能證明金鑰仍然安全。
如果無法確認誰曾看過、是否被下載、是否被轉傳,最安全的做法就是輪替。

單純修改限制可以降低風險,但無法讓已被他人保存的舊金鑰消失。完整處理流程應是:

  1. 查看使用量與帳單。
  2. 建立新的 API Key。
  3. 設定應用程式限制。
  4. 設定 API 限制。
  5. 更新網站、App及後端系統。
  6. 測試新金鑰。
  7. 刪除舊金鑰。
  8. 持續觀察異常流量。

需要規劃網站 API 串接、流量追蹤與數位廣告嗎?

網站使用 Google Maps、Google API、GA4或 Google Ads 時,除了完成 API 功能串接,也應建立清楚的使用權限、流量追蹤及行銷轉換架構,避免網站營運數據與 API 使用狀況無法對照。

 數位果子科技有限公司 提供:

  • 網站與 API 串接需求規劃
  • GA4 與 Google Search Console 數據整合
  • SEO關鍵字及內容策略規劃
  • Google Ads 關鍵字廣告投放
  • Facebook、Instagram 社群廣告投放
  • 網站轉換追蹤與行銷流程規劃
  • AI內容產製與行銷自動化規劃

本公司服務重點為網站建置、數位行銷、SEO內容與廣告投放,不代理 Google Cloud 帳單申訴、帳號救援或 Google 官方客服。涉及 API 異常帳單、退款或帳戶權限問題,仍應透過 Google Cloud 官方支援管道處理。

數位果子科技有限公司
合作專線:0970-357-535
LINE:cherng65

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *