API 安全工具的兩大類
| 防護，在執行階段 | 閘道、網頁應用程式防火牆、速率限制、機器人流量防護、機密資訊管理。減少真正抵達你服務的東西。由平台團隊或資安團隊採購。 |
| 驗證，在發布之前 | 掃描工具、模糊測試工具，以及針對授權與邊界的行為檢查。告訴你你的服務會做出什麼反應。由工程團隊採購，或者根本沒有人採購。 |
只靠防護會在哪裡失效
閘道無法知道使用者 A 不該讀取使用者 B 的訂單。那是一條商業規則，寫在你的程式碼裡，而每一個觸及這條規則的請求，在傳輸層看起來都完全合法：方法正確、權杖有效、路徑格式無誤。
物件層級授權是真實 API 中最常被利用的缺陷，而它正好屬於任何防護層都看不見的那一類。它必須在服務內部驗證，而且要在發布之前。
每一類工具實際涵蓋什麼
閘道與防火牆： 已知的攻擊模式、格式錯誤的請求、流量規模。確實有價值，但對邏輯完全看不見。
速率限制： 以量取勝的濫用。對單一個格式完全正確的惡意請求毫無作用。
機密資訊管理： 憑證外洩。與這裡其他項目彼此獨立，值得導入。
掃描工具： 相依套件弱點、各類注入攻擊、TLS 設定。
行為驗證： API 有沒有拒絕它該拒絕的請求。成本最低，也最常被漏掉。
這個缺口為什麼一直存在
行為層面的授權檢查成本低、效益高，卻普遍沒有人做——這是個奇怪的組合，值得解釋一下。
它卡在兩個負責人之間。它看起來像資安的工作，所以工程團隊假設資安流程已經涵蓋。而資安流程其實就是掃描工具加上一年一次的評估，兩者都不懂你的商業規則，於是資安那邊假設測試已經涵蓋。兩邊的假設在各自的位置上都很合理，於是這個缺口一存在就是好幾年。
指定負責人，問題就解決了大半。誰寫這個端點，誰就在同一個 pull request 裡寫授權檢查，把它當成工作中再正常不過的一部分。這樣一來，責任落在唯一知道「誰才該看到這筆資料」的人身上，而且規模是跟著端點數量成長，而不是跟著資安團隊的人力成長。
這星期就值得跑一次的檢查
建立兩個帳號。用其中一個建立一筆資料，再用另一個的權杖去讀它。如果資料真的回來了，你就有了 API 上最常見的嚴重缺陷，而且擋在服務前面的閘道一個都攔不住它。
然後把它自動化，因為每一個新端點都得重跑這個檢查，而沒有人會記得。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想安裝任何東西，儀表板也能做同樣的事。命令列能做的其他所有事情，都收錄在 CLI 儲存庫。
產生的 API 測試計畫包含授權與邊界類別，因此這些檢查會和功能覆蓋並列，而不是等著每季一次的演練。運作細節請見 API 測試文件。
從儀表板連接儲存庫，測試就會從你原本就會產出的部署版本開始執行；或者，你也可以在自己的工作流程裡加上一個步驟。
TestSprite 在驗證這一類工具中涵蓋了什麼
那些防護層做不到的行為檢查：未經驗證的存取、物件層級授權、角色權限邊界、過期憑證，以及超出範圍的輸入。產生的測試計畫包含授權與邊界類別，所以每一個端點都會被檢查到，包括上星期才加進來的那一個。
它透過介面對運行中的服務執行測試，依據的是探索結果加上你的 API 規格。Auto-Authentication 讓工作階段在整輪執行中保持有效，Dynamic Variables 在呼叫之間傳遞數值，Dependency Chains 推導出執行順序，Auto-Cleanup 則精確清掉這輪執行所建立的東西。
真正的收穫是節奏。這些檢查並不難，難的是寫到第四十個端點時很容易忘記；而每次變更都跑一次，正是補上真實 API 中最常被利用的那個缺口的方法。你的閘道和掃描工具，則繼續做它們擅長的事。
TestSprite 算是 API 安全工具嗎？
它屬於驗證這一類，涵蓋授權、角色邊界與邊界值。它不是閘道，也不是弱點掃描工具。
兩類工具都需要嗎？
需要。防護減少抵達你這裡的東西；驗證告訴你，對於穿透進來的東西你會怎麼處理。兩者無法互相取代。
WAF 能攔下有問題的授權邏輯嗎？
不能。在 WAF 能檢查的每一個面向上，這個請求都是合法的。只有服務本身知道誰才該看到那筆資料。
團隊規模不大，該從哪裡開始？
對每一個接收識別碼的端點做行為層面的授權檢查。命中率最高、成本最低，而且能在你現有的流程中執行。
兩者各自該多久執行一次？
防護是一直開著的。驗證則屬於每一次變更，因為新端點不斷出現，而每一個都需要同樣的檢查。