API 安全測試檢查清單，依「由誰檢查」分組
由自動化功能驗證涵蓋
這些是行為面的檢查：面對一個本來就該被拒絕的請求，API 的回應是否正確。它們屬於你日常的測試套件，而且每次變更都該執行。
未經驗證的存取會被拒絕。 每一個受保護的端點在不帶憑證呼叫時，回傳的是正確的拒絕回應，而不是資料。
授權以物件為單位確實落實。 使用者 A 無法靠著更改路徑中的識別碼，讀取或修改使用者 B 的資料。這是實際 API 中最常被利用的缺陷，而它就只是一個單純的行為檢查。
角色界線守得住。 唯讀角色無法寫入。過期或已撤銷的權杖會被拒絕。
輸入驗證會拒絕超出範圍的值。 每個參數的邊界案例，包括那些沒有人寫進文件的參數。
錯誤訊息不會洩漏內部資訊。 堆疊追蹤、查詢片段與內部主機名稱都不會出現在回應裡。
需要掃描工具或專門工具
相依套件與函式庫的漏洞。
各類注入攻擊：SQL、命令、樣板、反序列化。
TLS 設定與憑證處理。
針對你的技術堆疊進行已知 CVE 探測。
需要真人
商業邏輯濫用。下單數量填成負數、重複套用同一組折扣、在預設有先後順序的流程中跳過某個步驟。
威脅建模，以及判定哪些資料才真的算是敏感資料。
任何需要發揮想像力、去設想別人會如何濫用你產品的事。
最常被略過的那一項
物件層級授權是最常被漏掉、也最容易檢查的一項。建立兩個帳號，用其中一個建立一筆資料，再用另一個的權杖去讀它。如果讀得到資料，你手上就有業界最常見的嚴重 API 缺陷，而找出它只需要一個測試。
把這件事自動化，就足以回收整件事的成本，因為每新增一個端點就得重做一次這項檢查，而沒有人會記得去做。
讓可自動化的那一半真的跑起來
自動產生的 API 測試計畫包含授權與邊界這兩類項目，因此這些檢查會與你的功能測試覆蓋並存，而不是變成一項沒人排進行程的獨立資安工作。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果不想在本機安裝，儀表板也能做到同樣的事；完整的指令清單請見 CLI 儲存庫。
運作細節請見 API 測試文件。
你該長期保留的那兩個帳號
這份清單上幾乎每一項行為檢查都需要兩個使用者，而你能做的最省事的一件事，就是在每個環境都常備一組測試帳號，而不是每個測試都重新建立。
讓這兩個帳號在你的產品真正在意的面向上有所不同：不同的擁有者、如果有角色制度就給不同角色，最好還隸屬不同組織。這樣一來，每個授權檢查都只是兩行程式碼的測試，而不是一場前置準備工程，大家也才真的會動手寫。
行不通的做法，是在每個測試裡面現建帳號。這樣比較慢、會留下殘餘資料，而且讓檢查變成依賴註冊流程能正常運作——於是註冊一壞掉，每個權限測試都會因為錯誤的理由亮紅燈。改用只需初始化一次的常設帳號，這些問題就全部不見了。
各組的執行頻率
行為檢查在每次變更時執行。掃描工具定期執行，並在發版時再跑一次。人工審查則在威脅模型改變時進行，也就是當你新增了一種資料或一種使用者的時候。
從儀表板連接儲存庫，測試就會從你原本就會產出的部署開始執行；或者，你也可以改成在自己的工作流程中加上一個步驟。
TestSprite 如何涵蓋可自動化的那三分之一
自動產生的 API 測試計畫包含授權與邊界這兩類項目，因此這份清單上的行為項目會與你的功能測試覆蓋並存，而不是變成一項得由某人排進行程的獨立工作。
這表示未經驗證的存取、物件層級授權、角色界線、過期權杖與超出範圍的輸入，都會在每次變更時針對執行中的服務逐一檢查，涵蓋每一個端點，包括上週才新增的那些。Auto-Authentication 讓工作階段在整趟執行中保持有效，Dynamic Variables 在呼叫之間傳遞數值，Dependency Chains 依每個案例所需與所產出的內容推導執行順序，Auto-Cleanup 則精準移除這次執行所建立的東西。
價值在於執行的頻率，而不在於手法多聰明。這些檢查並不難寫，難的是寫到第四十個端點時還記得要寫。讓它們自動產生並持續執行，才能在不增加任何人得遵守的流程的前提下，補上實際 API 中最常被利用的那個破口。
這能取代滲透測試嗎？
不能。它持續涵蓋行為面的那一半，藉此減少滲透測試需要找出的問題，也讓這筆昂貴的委託更有價值。
TestSprite 會掃描漏洞嗎？
不會。它驗證的是行為，包括授權與邊界案例。漏洞掃描是另一種工具。
行為檢查應該多久執行一次？
每次變更都要。新端點不斷出現，而每一個都需要和前一個一樣的授權檢查。
我們該從哪裡開始？
從每一個接受識別碼的端點的物件層級授權開始。命中率最高，花的力氣最少。
做這些需要資安團隊嗎？
威脅建模和商業邏輯濫用需要。上面列出的清單項目則是一般的工程工作。