數位果子 BLOG
本站是數位果子的部落格網站。

API Key 不小心出現在網站原始碼、GitHub、公開文件、聊天群組或教學影片中,是否一定要重新產生?
原則上,只要 API Key 已經離開原本受控制的使用環境,或無法確定是否曾被第三方取得,最安全的處理方式就是建立新的 API Key、更新系統,再刪除舊金鑰。
Google Cloud 官方針對疑似遭入侵的 API Key,建議建立新的金鑰、套用與舊金鑰相符的必要限制、將新金鑰更新至所有使用位置,最後刪除舊金鑰。Google 也建議定期輪替 API Key,而不是長期使用同一組金鑰。
不過,並不是所有「在畫面上看見 API Key」的情況,都代表金鑰已遭入侵。
例如 Google Maps JavaScript API 使用於網站前端時,金鑰原本就可能被瀏覽器載入,訪客也可能透過開發者工具看到。這類前端金鑰的安全重點,不是讓金鑰完全不可見,而是正確設定網站來源限制與 API 使用限制。
因此,是否一定要重新產生,要先判斷金鑰的用途、公開範圍、限制設定及是否出現異常使用。



讓更多人搜尋到你的產品?現在有機會免費行銷 20 天!
現在越來越多品牌開始透過 內容行銷,讓產品被 Google 搜尋到。
我們現在開放 20 天免費內容行銷體驗,透過搜尋曝光與內容推廣,幫助你的產品被更多人看見。
外洩情況 | 是否建議重新產生 | 風險程度 | 建議處理 |
|---|---|---|---|
出現在公開 GitHub | 一定要 | 極高 | 建立新金鑰、更新系統、刪除舊金鑰 |
貼到公開論壇或社群 | 一定要 | 極高 | 立即輪替並檢查使用量 |
出現在後端程式原始碼 | 一定要 | 極高 | 重新產生並改用環境變數 |
寄給不應取得金鑰的人 | 建議一定要 | 高 | 視為已外洩並立即輪替 |
收到 Google 外洩警示 | 一定要 | 極高 | 依官方程序重建與撤銷 |
已出現陌生流量或費用 | 一定要 | 極高 | 先止損,再輪替金鑰 |
前端地圖金鑰可被看到 | 不一定 | 中 | 檢查網域與 API 限制 |
金鑰只出現在私人內部文件 | 視權限而定 | 中 | 確認存取紀錄與分享範圍 |
金鑰短暫顯示於線上會議 | 建議重新產生 | 高 | 無法確認是否被錄影或截圖 |
金鑰完全沒有限制 | 建議重新產生 | 高 | 建立有限制的新金鑰取代 |
測試金鑰已停止使用 | 建議刪除 | 中 | 不需要保留未使用金鑰 |
金鑰名稱或用途無法確認 | 建議重建 | 中 | 盤點用途後重新分配 |
只要 API Key 曾提交到公開 GitHub、GitLab 或其他公開程式碼儲存庫,就應視為已經外洩。
即使後來刪除程式碼,金鑰仍可能存在於:
因此,只把該行程式碼刪除並不足以恢復安全。
Google 官方建議在公開程式碼前先確認其中沒有 API Key 或其他私人資訊,並定期建立替代金鑰、更新應用程式後刪除舊金鑰。
正確處理方式是:
如果在 Google Cloud 中發現以下情況,代表金鑰可能已被第三方實際使用:
這種情況不能只修改金鑰限制後繼續使用,因為第三方可能已經保存原金鑰。
應直接將舊金鑰視為遭入侵,建立替代金鑰並撤銷舊金鑰。Google 官方的遭入侵憑證處理文件,也明確建議重新建立 API Key、更新所有使用位置,再刪除舊金鑰。
伺服器端 API Key 原本不應被一般使用者看到。
如果後端金鑰出現在:
通常都應立即重新產生。
原因是後端 API Key 往往沒有瀏覽器網域限制,而是透過伺服器 IP 或其他方式限制。若完全沒有設定限制,取得金鑰的人可能從自己的伺服器發送請求。
Google Cloud 可能在偵測到 API Key 被公開於程式碼儲存庫或其他公開位置時,向專案擁有者或安全聯絡人發出通知。
Google 官方指出,偵測到遭入侵 API Key 的警示,可能表示組織不慎將相關金鑰發布在公開儲存庫中。
收到通知後,不應只刪除公開頁面,建議立即:
例如:
即使目前沒有異常流量,也很難確認金鑰是否被保存、轉傳或截圖。
這種情況最好直接輪替,不要等到產生費用才處理。
網站使用 Google Maps JavaScript API 時,API Key 通常會隨前端程式載入,所以使用者可能在瀏覽器開發者工具看到。
這並不一定代表金鑰已經遭到盜用。
應檢查該金鑰是否有設定:
例如只允許:
https://example.com/*
https://www.example.com/*
而不是允許:
*
https://*
如果前端金鑰一直都有正確限制、沒有異常流量,也沒有被放到其他不相關位置,可以不一定立即更換。
但若無法確認限制是否完整,建立新的受限金鑰通常仍是較穩妥的做法。
例如 API Key 只存在於:
這種情況通常不算公開外洩。
但仍應確認:
Google 官方仍建議定期輪替 API Key,以降低長期憑證遭洩漏後的風險。
如果外部人士只看到:
而沒有取得完整、可使用的 API Key,通常不需要立刻重新產生。
但應確認截圖或文件中沒有其他位置顯示完整金鑰。
可以降低風險,但不能保證解決已外洩的問題。
假設原本未受限制的 API Key 已被第三方取得,後來才加入網站網域限制,攻擊者可能暫時無法繼續使用。
但仍有以下問題:
因此:
若只是預防性強化安全,可以直接增加限制;若已確認或高度懷疑外洩,應重新產生。
Google 官方表示,如果要輪替 API Key,可以建立新金鑰並套用相同限制,將應用程式更新為新金鑰,最後刪除舊金鑰。
前往 Google Cloud 憑證頁面:
確認:
不要在完全不知道用途時直接刪除,否則可能造成網站、App或後端服務中斷。
在 Google Cloud Console 中選擇:
API 與服務
→ 憑證
→ 建立憑證
→ API 金鑰
新金鑰建立後,先不要立即放入正式環境,應先完成限制設定。
依照使用情況選擇:
使用「網站」或 HTTP 參照網址限制。
例如:
https://example.com/*
https://www.example.com/*
使用固定 IP 位址限制。
限制:
限制:
不要選擇允許所有 API。
應限制為真正需要的服務,例如:
不同用途最好使用不同 API Key,不要將網站地圖、後端地址查詢和 App 共用同一把金鑰。
常見需要替換的位置包括:
.env 檔案應建立一份清單,避免遺漏某個舊系統。
確認以下功能是否正常:
常見錯誤包括:
API_KEY_INVALID
REQUEST_DENIED
RefererNotAllowedMapError
ApiNotActivatedMapError
IpRefererBlocked
如果新金鑰無法運作,通常是網域、IP或 API 限制設定不完整。
確認所有正式系統都已更新後,應刪除舊金鑰。
Google 官方的輪替流程就是先建立替代金鑰、更新應用程式,再刪除舊金鑰。
不要因為舊金鑰暫時沒有流量,就長期保留作為備用。
一般 API Key 的主要處理方式通常是建立新金鑰並刪除舊金鑰。
如果異常費用正在快速增加,可以先採取緊急措施:
這可能造成網站或 App 部分功能短暫中斷,但在費用持續增加時,應優先止損。
API Key 一旦刪除,通常不應期待能以原字串繼續使用。
因此刪除前應先確認:
不過,若金鑰已確認遭到濫用,即使仍有部分舊系統尚未完成替換,也不應為了維持舊系統而長時間保留外洩金鑰。
不會。
輪替或刪除 API Key 的作用,是阻止後續請求繼續使用舊金鑰,不會自動取消已經產生的 API 使用費。
如果已出現異常費用,應:
是否能調整或減免費用,仍需由 Google 依個案審核。
刪除前可先觀察:
但如果金鑰已確認外洩,不建議為了觀察而保留太久。
更安全的做法是:
後端金鑰應放在:
Google 官方建議避免將 API Key 直接寫入原始碼,並在公開程式碼前檢查是否含有憑證。
建議分開建立:
若其中一把外洩,只需要處理單一環境。
至少設定:
Google Cloud 官方也建議限制能使用金鑰的網站、IP 位址或應用程式,並限制能存取的 API。
測試完成、網站下線或 App 停止維護後,應刪除不再使用的 API Key。
保留大量用途不明的金鑰,會增加盤點及資安管理難度。Google 官方建議刪除不需要的 API Key,以縮小遭受攻擊的範圍。
即使沒有明確外洩事件,也可以制定輪替週期,例如:
Google 官方並未要求所有一般 API Key 必須使用完全相同的固定天數,但明確建議定期建立新金鑰、更新應用程式並刪除舊金鑰。
建議更換。
沒有費用可能只是:
既然無法收回已公開的完整金鑰,重新產生通常是最安全的選擇。
不行。
修改金鑰名稱只會改變管理介面中的標籤,不會改變實際的 API Key 字串。
外部人士仍可繼續使用原有金鑰。
通常不會。
加入網域、IP或 API 限制,只會改變金鑰可被使用的範圍,不等於產生新的金鑰。
若金鑰已經外洩,最完整的處理方式仍是建立新金鑰並刪除舊金鑰。
可以短時間並行,以便完成系統切換。
建議流程:
不要無期限保留。
若金鑰只用於前端網站、限制正確、沒有異常使用,也沒有出現在其他不適當的位置,可以不必因為訪客能在瀏覽器看到而立即輪替。
但如果它曾被公開到 GitHub、文件或其他不受控制的位置,仍建議重新產生。
不一樣。
API Key 主要用來識別應用程式或專案;服務帳戶金鑰則可能代表一個具備 IAM 權限的身分。
若外洩的是服務帳戶 JSON 金鑰,風險通常更高。Google 官方建議懷疑服務帳戶金鑰遭入侵時立即輪替。
此時還應檢查:
以下網址請使用一般文字超連結、按鈕或直接顯示網址,不要使用 WordPress「嵌入內容」區塊。
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
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、論壇、文件、影片或非受控人員手中,就應重新產生。
第二,是否能證明金鑰仍然安全。
如果無法確認誰曾看過、是否被下載、是否被轉傳,最安全的做法就是輪替。
單純修改限制可以降低風險,但無法讓已被他人保存的舊金鑰消失。完整處理流程應是:
網站使用 Google Maps、Google API、GA4或 Google Ads 時,除了完成 API 功能串接,也應建立清楚的使用權限、流量追蹤及行銷轉換架構,避免網站營運數據與 API 使用狀況無法對照。
數位果子科技有限公司 提供:
本公司服務重點為網站建置、數位行銷、SEO內容與廣告投放,不代理 Google Cloud 帳單申訴、帳號救援或 Google 官方客服。涉及 API 異常帳單、退款或帳戶權限問題,仍應透過 Google Cloud 官方支援管道處理。
數位果子科技有限公司
合作專線:0970-357-535
LINE:cherng65