大多數團隊把 API 安全當成身分驗證問題：發放權杖，在每一條路由上檢查它，然後認為事情已經做完了。直到某天，一位測試人員把網址裡的一個數字改掉，就讀到了另一位客戶的發票。

「已通過身分驗證」和「已獲得授權」之間的這道縫隙，正是絕大多數真實 API 外洩事件棲身的地方，而且它並不是掃描器能夠穩定發現的那類問題。自動化工具看到一個有效的權杖和一個 200 回應，就回報成功。只有理解你業務規則的人，才會注意到那個回應裡裝的是別人的資料。

核心區別： 身分驗證證明的是誰在呼叫。授權決定的是這個特定呼叫方可以看到什麼、可以修改什麼，而且它必須落實到每一個物件、每一次請求，並在資料層強制執行。幾乎所有嚴重的 API 漏洞，都是第一件事運作完美、第二件事失守的結果。

物件層級授權失效為什麼佔了絕大多數

最常見的嚴重 API 缺陷，也是最容易描述的那一個。

你的端點是 /api/invoices/48213。呼叫方已經通過身分驗證，於是處理常式取出發票 48213 並把它回傳。沒有人檢查這張發票是否屬於該呼叫方。換個數字，就拿到別人的發票。API 完全按照寫出來的樣子執行了，寫錯的是那段程式碼本身。

這個缺陷的規模效應對你不利，對攻擊者有利。連續遞增的識別碼讓人只用一個迴圈就能列舉出你的整個資料集。改用難以猜測的識別碼略有幫助，但那不是修正，因為識別碼仍會透過其他端點、匯出檔案和郵件外洩出去。

修正必須是結構性的，而不是順手補一刀。所有權要在查詢本身裡檢驗：取出屬於這位客戶、且具有這個識別碼的發票，而不是先把發票取出來，再指望後面某段程式碼會做檢查。把這項強制放進資料存取層，這樣六個月後某個從沒讀過這段話的人寫新控制器時，也不可能把它忘掉。

同樣的失效不只適用於物件，也適用於功能。如果一個管理端點唯一的保護，只是一般使用者的後台介面沒有連結到它，那麼它根本沒有受到保護。

真正會被查出來的 API 安全缺陷

除授權之外，還有少數幾類問題佔了大部分發現。這裡的標準參考是 OWASP API Security Top 10，OWASP 會定期修訂它，所以請查閱目前版本，而不是某份摘要。

回傳的東西比介面顯示的更多。 某個端點圖省事回傳了完整的使用者物件，前端只顯示其中三個欄位。其餘十二個，包括密碼重設權杖和內部風險分數，仍然留在回應裡。任何打開網路面板的人都能拿到它們。序列化要有意為之：用逐個點名的欄位拼出回應，而不是把一個模型整個倒出去。

入站方向的大量指派。 這是上一個問題的鏡像。一個資料更新端點來什麼欄位就收什麼、並寫進紀錄，於是呼叫方加上一句 "role": "admin" 就把自己升成了管理員。請明確繫結到允許欄位清單，而不是整份接收請求主體。

消耗沒有上限。 沒有限制的話，一個呼叫方可以每頁請求一百萬筆紀錄，在迴圈裡跑昂貴的搜尋，或者觸發上千次密碼重設。這不只是阻斷服務的問題：當每一次請求都在花你的錢，例如端點背後接著一個語言模型時，這就是一場針對帳單的攻擊。速率限制應當按呼叫方、按端點分別設定，昂貴的操作要比廉價的操作勒得更緊。

資產清單與對第三方的信任

沒有文件、被遺忘的端點。 第二版已經上線並有文件，第一版卻還帶著舊的授權邏輯在跑，而一套裝著正式資料的測試環境 API 從公網就能存取。攻擊者要找的正是這些。請為每一個已部署的 API、每一個版本、每一套環境維護清單，並且有意識地下線，而不是任其荒廢。

信任你所呼叫的系統。 你的 API 會使用別人的 API，而它們的回應會直接落進你的資料庫和輸出畫面裡。不要因為對方是合作夥伴就假定安全，請檢驗回來的內容。上游的故障或規格變更，最後往往以你這邊的缺陷形式浮現出來。同一段關係裡可靠性的一面，我們在第三方 API 整合 的指南裡談過。

把身分驗證做對

身分驗證是多數團隊大致做對了的部分，所以這一節談的是那些會把它毀掉的細節。

使用帶更新機制的短期存取權杖，而不是永不過期的長期金鑰。一份永遠有效的憑證一旦外洩，就是一次永久性的入侵；一份十五分鐘後失效的憑證外洩了，那是一起有明確終點的事件。

把權杖的範圍收窄。核發給報表整合的權杖，不應該有建立使用者的能力。有了範圍，你就能在中心位置強制這一點，而不必依賴每個處理常式自己去檢查。

正確地驗證權杖，這多半意味著不要接受權杖自己宣稱的演算法。固定你預期的簽章演算法，檢驗簽發者和受眾，並檢查到期時間。預設就這樣做的函式庫是存在的；錯誤幾乎都住在手寫的驗證邏輯裡。

按計畫輪換憑證，並給呼叫方提供一條不停機的輪換路徑，通常是在切換期間同時接受兩把有效金鑰。如果輪換會造成停機，那就沒有人會去輪換。

最後，永遠不要把憑證放進網址。查詢字串最終會出現在伺服器記錄、瀏覽器歷史、代理伺服器記錄和 referrer 標頭裡。請使用請求標頭。

滲透測試實際會發現什麼

自動掃描和人工測試發現的東西不同，你出於不同的理由需要兩者。

掃描器擅長找出已知有漏洞的相依套件、缺少的安全標頭、TLS 設定錯誤和明顯的注入。請讓它們在管線裡持續執行，因為它們便宜，而且能抓住退步。

它們做不到的，是理解你的業務。測試人員會發現優惠碼端點可以反覆呼叫來疊加折扣，會發現付費功能在免費方案下直接呼叫 API 就能用，會發現出貨之後取消訂單會在不核對庫存的情況下觸發退款。這些才是真正讓人賠錢的發現，而它們只有在有人真正明白這套 API 是做什麼用的時候才會浮出水面。

具體到 API，請要求測試範圍包含跨角色的授權測試，也就是測試人員同時持有兩個不同客戶的憑證，有系統地嘗試用其中一方的權杖去存取另一方帳戶的資料。單這一項練習，找出的問題就比其餘全部加起來還多。我們關於滲透測試類型 的文章說明了應該給測試人員多少存取權限，而把文件和憑證交給他們，效果遠好過一次盲測。

預算方面，以 API 為核心的測試通常從一個小而文件齊備的 API 約 £3,000 起，到一個角色眾多、整合眾多的大面積介面 £15,000 甚至更高。我們的滲透測試費用指南 拆解了推動這個區間的因素。

記錄足夠多，事後才查得清

一起事件和一場災難之間的差別，通常就在於你能否還原當時到底發生了什麼。

請記錄身分驗證事件、授權失敗，以及每一次改變狀態的操作，並附上呼叫方身分、目標物件和一個關聯識別碼。授權失敗尤其是你的預警訊號：一個正常的整合幾乎不會產生它們，所以一串密集的授權失敗意味著有人正在試探。

不要把敏感值本身寫進記錄。權杖、卡號和個人資料一旦進入記錄檔，就會把一次被控制住的外洩，變成一次必須通報的外洩。

對模式告警，而不是對總量告警。一個呼叫方在大量物件識別碼上產生授權失敗，說明列舉正在進行，這值得把人從床上叫起來；整體錯誤率則不值得。

保留時間要長到有用為止。入侵常常在開始數週之後才被發現，而三十天的記錄往往太短，不足以找到最初的入口。

去測試你真正發布出去的那套 API

Mecanik 提供應用程式安全測試 ，重點放在自動化工具漏掉的授權與業務邏輯缺陷上，其中包括使用多個角色的真實憑證進行跨帳戶測試。

我們從你的規格說明和文件出發，而不是靠猜測攻擊面，因此順帶就會發現沒有文件的端點和被落下的舊版本。當工作延伸到基礎架構與網路測試時，我們的滲透測試服務 涵蓋那一塊。如果你還在設計 API，我們關於客製化 API 開發成本 的指南講清楚了授權、速率限制和記錄應該放在建置的哪個位置，而不是事後補裝。

把規格說明和角色描述寄給我們，我們會告訴你風險集中在哪裡。

相關文章: 英國滲透測試 - 2026年應期待什麼 、2026年英國開發者GDPR技術合規指南 、Cloudflare Zero Trust：企業存取安全指南 、為企業主講解 OWASP Top 10 。

常見問題

最常見的 API 安全漏洞是什麼？ 是物件層級授權失效，也就是一個已通過身分驗證的呼叫方，只要改掉請求裡的一個識別碼，就能讀到另一位使用者的資料。身分驗證本身運作正常，但沒有任何環節檢驗被請求的物件是否屬於該呼叫方。因此所有權必須在查詢本身裡強制執行。

只用 API 金鑰的安全性夠嗎？ 單靠它並不夠。永不過期的長期金鑰會把任何一次外洩變成永久性入侵。請使用帶更新機制的短期存取權杖，按呼叫方實際需要收窄範圍，支援不停機輪換，並且始終透過請求標頭而不是網址傳遞它們。

自動掃描能保障 API 安全嗎？ 不能，但仍然值得持續執行。掃描器能找出已知有漏洞的相依套件、缺少的回應標頭和明顯的注入。它們無法理解你的業務規則，因此會漏掉折扣疊加、免費方案下可存取的付費功能，以及跨帳戶的資料存取。

API 滲透測試的費用是多少？ 一個小而文件齊備的 API 通常從約 £3,000 起，一個角色眾多、整合眾多的大面積介面則可達 £15,000 甚至更高。費用主要取決於端點數量、不同角色的數量，以及是否提供文件和憑證。

基於安全目的，API 應該記錄什麼？ 身分驗證事件、授權失敗，以及每一次改變狀態的操作，每筆都要帶上呼叫方身分、目標物件和一個關聯識別碼。永遠不要記錄權杖或個人資料。當一個呼叫方在大量識別碼上產生授權失敗時應當告警，那說明列舉正在進行。