API 弱點掃描怎麼做？REST、GraphQL 與 OWASP API Security Top 10 完整指南

先講結論：API 弱點掃描是在驗證信任邊界，不是掃一份 URL

傳統頁面掃描常從 Link、Form 與 JavaScript 找到入口；API 則直接接收結構化資料、物件識別碼、Token、批次操作與狀態轉換。相同 Endpoint 對不同使用者、租戶、角色、Scope、HTTP Method 或物件狀態，可能產生完全不同的安全結果。只用一組帳號跑一次 Crawl，通常只能看到介面的一小部分。

有效的 API 弱點掃描要同時回答五個問題：資產是否完整、Request 是誰送的、他想對哪個物件做什麼、Server 是否只回傳與接受必要欄位，以及這個動作能否被大量或不按順序地濫用。任何一項缺少 Context，掃描器都可能把真正越權判成正常，也可能把預期的 403 或 Business Rule 誤判為弱點。

因此 API Security 是持續流程：以 Inventory 與 Contract 建立可測範圍，用多組最小權限測試身分重播 Request，對物件與欄位做差異驗證，再把結果回到程式碼、Policy、Gateway、監控與修復複驗。一次性工具報告只能提供訊號，不能代表 API 已安全。

• 先盤點 Host、Base Path、Version、Protocol、Environment、Owner 與資料敏感度
• 用至少兩個同權限主體、不同租戶與不同角色建立可比較的授權測試矩陣
• 以 OpenAPI／GraphQL Schema、Client Traffic、Gateway Log 與服務路由交叉補齊 Endpoint
• 把物件層、欄位層、功能層與業務流程授權分開驗證
• 所有測試都要有合法授權、速率與副作用控制，以及可重播的修復複驗證據

API 弱點掃描與網站頁面掃描有什麼不同？

網站頁面通常帶有可見導覽與 HTML 表單，API 的攻擊面卻可能只存在於 Mobile App、SPA、Partner Integration、Service-to-Service Traffic、Webhook、背景 Job 或已停止公開文件的舊版本。若掃描從首頁開始，沒有 Contract 或真實 Traffic，許多 Endpoint 根本不會被發現。

API Request 也更常帶有 Authorization Header、Tenant Header、JSON Body、GraphQL Operation、Idempotency Key、Signature、Nonce 或 Client Certificate。掃描器若不理解這些前置條件，只會收到 401、403 或格式錯誤；若為了提高覆蓋而使用過度權限 Token，又可能錯過一般使用者的授權差異。

第一步不是送 Payload，而是建立 API Inventory

OWASP API9:2023 Improper Inventory Management 特別指出，舊版本、Beta Host、測試環境與文件落差會讓較弱的驗證、Rate Limit 或修補狀態繼續暴露。Inventory 不能只有一張 Endpoint 表；至少要記錄 Environment、Version、網路可達性、Owner、Consumer、認證方式、資料分類、部署版本與淘汰日期。

盤點來源要交叉比對。OpenAPI 文件可能比實際部署舊，Gateway 只看得到經過 Gateway 的流量，程式路由不一定包含 Serverless 或第三方 Webhook，DNS 與 Certificate Transparency 只顯示部分外部面。Contract、Gateway、Service Mesh、Source Route、Cloud Inventory、Mobile／Web Client 與外部 Attack Surface 的聯集，才接近真實範圍。

掃描範圍與授權要怎麼定義？

API 測試可能建立帳號、下單、寄送 OTP、呼叫付費服務、上傳檔案、修改資料或觸發非同步 Job。開始前要用書面授權定義 Host、Environment、允許 Method、測試時間、來源 IP、Rate、測試帳號、資料處理、禁止動作、緊急聯絡人與停止條件。第三方 API、Cloud Metadata、Partner Environment 與 Production Data 不會因為從自己的 API 間接呼叫就自動進入授權範圍。

優先在與 Production 控制一致、資料隔離的環境做深度測試；若必須測 Production，使用專用 Tenant、可回收資料、低速率、可辨識 Header、成本上限與即時監控。任何可能造成大量通知、金融交易、庫存變動或不可逆資料刪除的操作，都要先建立替代驗證或明確人工 Gate。

OpenAPI、GraphQL Schema 與真實 Traffic 各自提供什麼？

Contract 能描述 Path、Method、Parameter、Request Body、Response Schema 與 Security Scheme，適合建立正向與負向測試；但它不一定包含未文件化路由、Feature Flag、舊版與真實使用順序。真實 Traffic 能補上 Client 實際 Header、Token、狀態與資料組合，卻可能缺少低頻管理功能，且必須去識別化與妥善保護秘密。

GraphQL Schema 能列出 Type、Field、Argument、Query 與 Mutation，但不直接說明每個 Resolver 的授權規則、資料成本或跨欄位關係。安全測試應把 Schema 當作攻擊面地圖，再用不同主體、物件與 Operation 驗證真正的 Resolver 行為。

先建立身分、角色、租戶與物件的測試矩陣

API 授權弱點需要比較。至少建立兩個同角色使用者 A／B，若有 Multi-Tenant 再建立 Tenant A／B，並準備一般使用者、管理者、唯讀、停用、未驗證與過期 Token 等狀態。每個測試先取得合法 Baseline，再只改一個維度，例如 Object ID、Tenant Header、Field、Method 或 Scope，才能把差異歸因於授權。

不要用單一 Super Admin Token 代表所有覆蓋。它能發現輸入與設定問題，卻不能證明一般角色受到限制。也不要把 JWT Claim 當成授權真相；測試必須觀察 Resource Server 是否以可信 Server-Side Policy 驗證 Actor、Action、Resource、Tenant 與 Context。

OWASP API Security Top 10 2023 應該怎麼使用？

OWASP API Security Top 10 2023 是教育與風險認知文件，聚焦 API 特有或特別重要的風險。官方也說明，它不取代其他 Top 10，更不會替每個組織完成風險分析；Injection、弱元件等一般應用風險即使不在 API Top 10，仍然存在。

實務上應把十類風險映射到 Inventory、Threat Model、Secure Design、Code Review、Automated Test、Manual Test、Gateway Policy 與 Monitoring，而不是把『掃過 Top 10』當成單一 Checkbox。每一類都要定義適合自己的資產、證據、Owner 與修復 Gate。

API1 BOLA：為什麼換一個 Object ID 就可能越權？

Broken Object Level Authorization 發生在 Endpoint 接收訂單、檔案、帳戶、專案或其他物件識別碼後，沒有驗證目前 Actor 是否能對該物件執行該 Action。ID 是整數、UUID 或無法猜測的字串都不影響授權責任；不可猜測只降低發現機率，不能取代 Server-Side Check。

測試先由 User B 建立物件，再用 User A 的合法 Token 重播相同 Request，只替換 Path、Query、Header、Body 或 Nested Object 中的 ID。讀取、更新、刪除、分享、匯出、下載與子資源都要分開驗證；200 與資料外洩固然是證據，Blind Update、狀態改變或不同 Response Length 也可能證明越權。

API2 Broken Authentication：Token 驗證不是只看簽章

API 身分驗證涵蓋 Login、Token Issuance、Refresh、Revocation、Password Reset、MFA、API Key、Client Credential 與 Service Identity。JWT 驗證除了 Signature，還要固定 Algorithm、驗證 issuer、audience、expiration、not-before、必要 scope 與 token type；Opaque Token 則要確認狀態、Audience、撤銷與 Cache 行為。

掃描應測試缺少 Token、錯誤 Scheme、格式變異、過期／未生效／撤銷 Token、錯誤 Audience、錯誤 Issuer、Scope 缺少、不同 Client Token、Refresh Token 重播與同一憑證跨服務使用。登入與 Recovery 還要驗證 Rate Limit、帳號枚舉、MFA Bypass、一次性憑證與 Session 輪替。

API3 BOPLA：過度回傳與 Mass Assignment 是同一個欄位邊界問題

Broken Object Property Level Authorization 同時包含未授權讀取欄位與未授權修改欄位。API 可能把完整資料模型序列化後交給 Client 自行隱藏，造成 PII、內部狀態、成本、權限或審核欄位過度回傳；也可能直接把 JSON 綁定到 Domain Model，讓 Client 加入 role、ownerId、approved、creditLimit 等不應可寫的欄位。

測試要建立 Read Allowlist 與 Write Allowlist。比較不同角色 Response Schema，檢查 Nested Object、Error、Export、Search、GraphQL Fragment 與批次結果；在 Create／Update／Patch Request 加入敏感、唯讀、未知、Null 與 Nested Field，再從後續 Read、Audit Log 或資料庫狀態確認是否被接受。

API4 Unrestricted Resource Consumption：Rate Limit 只是其中一層

API 會消耗 CPU、Memory、Bandwidth、Database Connection、Thread、File Descriptor、Storage，以及 Email、SMS、OCR、AI、Payment 或第三方查詢等按次計費資源。OWASP API4 強調的不只是 Request 速率，也包含單次 Payload Size、Array Length、Page Size、Upload、Batch、GraphQL Depth／Cost、Execution Timeout 與 Concurrent Job。

安全測試採漸進方式，先確認明確限制與 4xx／429，再在核准窗口小幅增加 Size、Count、Depth 或 Concurrency，觀察 Response Time、CPU、Memory、Queue、第三方費用與其他 Tenant 的服務品質。不能用未設上限的壓力測試在 Production『證明』DoS。

API5 BFLA：能到達 Endpoint 不代表能執行該功能

Broken Function Level Authorization 發生在低權限主體能呼叫管理、審核、匯出、停用、退款或其他高權限功能。常見原因是只在 UI 隱藏按鈕、只以 URL Prefix 保護管理路由、Gateway 與 Service Policy 不一致，或同一路徑的 GET 有檢查但 POST／DELETE 沒有。

測試以 Route × Method × Role 建立矩陣。先由合法管理者取得 Request，再替換成一般使用者、唯讀、其他 Tenant、不同 OAuth Client 或缺少 Scope 的憑證；同時測試 Method Override、Alternate Content-Type、Legacy Version、Batch 與 GraphQL Mutation。

API6 Sensitive Business Flows：技術上合法的 Request 也能傷害業務

搶票、搶購、建立假帳號、刷 Coupon、囤庫存、批量查價、邀請獎勵、內容灌水與 OTP 發送，往往使用合法帳號、合法 Schema 與預期 Endpoint。問題不在單一 Request 是否通過驗證，而在流程是否能被自動化、平行化、重播或繞過順序，造成經濟、資源或公平性影響。

測試要先由產品與風險團隊標出敏感流程、可接受頻率、稀缺資源、前置條件與異常模式，再驗證 Rate、Quota、Device／Account Reputation、Step Binding、Idempotency、Reservation Expiry、Challenge 與人工審查。單純加 IP Rate Limit 容易被分散式來源、帳號農場或不同 Client 繞過。

API7 SSRF：Webhook、匯入 URL 與預覽服務都是高風險入口

當 API 接收 URL、Hostname、Webhook、Image Fetch、Document Import、Callback 或其他遠端資源位置，再由伺服器發出 Request，就形成 SSRF 攻擊面。攻擊者可能導向 Loopback、Private Network、Cloud Metadata、管理介面，或利用 Redirect、DNS Rebinding、IPv6 與不同表示法繞過字串檢查。

掃描要從輸入到實際 Egress 建立證據，不能只看 Response 是否帶回內容。使用核准的受控測試端點觀察 DNS 與 HTTP Call，測試 Redirect 每一跳、Resolved IP、Scheme、Port、Credential、Timeout、Response Size 與 Network Egress Policy；禁止在未授權情況探測真實內網與 Metadata。

API8 Security Misconfiguration：設定可能散落在整條 API Stack

API 設定問題不只在程式。TLS、Gateway、Load Balancer、WAF、CORS、Reverse Proxy、Container、Framework、Error Handler、Cloud Storage 與 Service Mesh 都可能形成暴露。常見訊號包含 Debug／Stack Trace、寬鬆 CORS、未限制 Method、預設帳密、目錄或管理端點、舊 TLS、缺少 Cache Control、過度詳細錯誤與不必要服務。

檢測要比較外部 Response 與實際部署設定，並涵蓋所有 Host、Version 與 Environment。只看 Current Production Gateway 可能漏掉可直接到達的 Origin、Beta Host 或未經同一 Policy 的 Legacy Route。

API9 Improper Inventory Management：舊版本常是安全控制的旁路

新版本補上 MFA、Rate Limit 或欄位授權，不代表 v1、Beta、Regional Host、Mobile Legacy 或 Partner Endpoint 也同步受保護。攻擊者只要找到仍可到達的舊介面，就可能繞過 Current Version 的防線。版本淘汰要包含流量觀察、Consumer Migration、明確 Sunset、Route Removal、DNS／Certificate 清理與持續外部驗證。

掃描排程要以 Inventory 為來源，每個可到達版本使用相同基準 Control Set。若舊版因相容性無法立即修補，需用 Gateway Policy、Network Restriction、短期監控與明確到期的風險例外，而不是從掃描範圍移除。

API10 Unsafe Consumption of APIs：第三方 Response 仍是不可信輸入

內部 API 從支付、物流、地址、身分、AI 或其他 SaaS 收到的資料，不能因供應商品牌或 TLS 就直接信任。第三方可能被入侵、回傳異常格式、惡意內容、巨大 Response、Redirect、延遲或重複事件；若資料再進入 SQL、Template、Command、File、Log 或下游 API，就可能形成二階注入與供應鏈式影響。

測試可用 Mock／Sandbox 模擬錯誤 Schema、額外欄位、惡意字串、超大 Body、慢速 Response、重複／亂序 Webhook、錯誤簽章與 Redirect。系統應驗證 TLS 與目的地、Schema、Signature、Timestamp／Replay、Size、Timeout、Redirect、Idempotency，並以 Circuit Breaker 與隔離 Queue 限制故障。

REST API 要怎麼測 Method、狀態碼與 Idempotency？

REST 測試不能只跑文件中的 Happy Path。每個 Resource 要驗證允許的 Method、Content-Type、Accept、Unknown Field、Missing Field、Duplicate Key、Null、Boundary、Pagination、Filter、Sort 與 Conditional Request。未允許 Method 應一致拒絕，不能因 HEAD、OPTIONS、PATCH、Method Override 或不同 Content-Type 進入另一條較弱路徑。

Status Code 要與安全語意一致，但不能把 200／403／404 當作唯一判定。重點是資料與副作用：失敗 Request 是否仍建立 Job、扣款、寄信或更新部分欄位；重試是否因缺少 Idempotency 造成重複交易；Idempotency Key 是否綁定 Actor、Route 與 Request Fingerprint，避免跨使用者重播。

GraphQL API 要測 Depth、Cost、Batching 與 Resolver 授權

GraphQL 只有一個 HTTP Endpoint，不代表攻擊面更小。攻擊面存在於 Query、Mutation、Subscription、Type、Field、Argument、Resolver、Interface、Union、Alias、Fragment、Batch 與 Data Loader。OWASP 建議驗證輸入、限制昂貴 Query、對資料與 Mutation 強制存取控制，並關閉不必要的 GraphiQL、過度 Error 與公開 Introspection。

資源測試要同時看 Depth、Breadth、Alias、Fragment Expansion、List Cardinality、Nested Pagination、Batch Operation 與實際 Resolver Cost。只限制 Depth 可能被同層大量 Alias 繞過；只做 Rate Limit 可能允許一個 Request 包含數百次昂貴 Resolver。授權則要在 Node 與 Edge、Query 與 Mutation、Parent 與 Child Field 都執行。

OAuth 與 Bearer Token 應該怎麼檢測？

OAuth 把 Authorization Server、Client 與 Resource Server 分開。Resource Server 必須驗證 Token 是由可信 Issuer 發出、Audience 指向自己、Scope 足以執行當下 Action，並區分 Access Token、ID Token 與其他 Token Type。不能只因 JWT 簽章有效就接受，也不能讓同一 Token 在所有 API 通用。

RFC 9700 整理 OAuth 2.0 現行安全最佳實務，包括避免不安全流程、嚴格 Redirect URI、PKCE、最小權限 Token，以及對 Public Client 的 Refresh Token 使用 Sender-Constrained 或 Rotation 來偵測重播。測試要驗證 Authorization Code 綁定 Client／Redirect／PKCE，Access Token 的 iss／aud／scope／exp，以及 Refresh Token Rotation、Family Revocation 與 Concurrent Refresh。

Rate Limit 要綁誰、限制什麼，才不會一繞就過？

單一 IP Limit 無法涵蓋 NAT、Proxy、IPv6、Botnet 與已登入帳號；單一 User Limit 也可能讓攻擊者用帳號農場濫用。應依風險組合 Actor、Client、Tenant、Target、Device、IP、Route、Operation 與成本單位，並區分平常速率、短期 Burst、Concurrent Request、每日 Quota 與昂貴操作 Budget。

429 與 Retry-After 要一致，Gateway 與 Service 不能各自使用互相矛盾的 Key。安全測試要確認 Header／Forwarded IP 不能由外部偽造繞過、分散節點共享狀態、不同 API Version 套用相同策略，以及拒絕後沒有先執行昂貴工作。

錯誤訊息、Response 與 Log 不能洩漏什麼？

API Error 應提供 Client 可處理的穩定 Code 與 Correlation ID，但不應回傳 Stack Trace、SQL、Internal Host、File Path、Secret、Token、完整物件、存在性差異或未授權欄位。Authentication 與 Authorization 的錯誤差異要兼顧可觀測性與資訊洩漏，詳細原因留在受保護的 Server Log。

Log 也不能直接記錄 Authorization Header、Session ID、API Key、Password、OTP、Private Key、完整 Cookie 或敏感 Payload。可用 HMAC／不可逆 Fingerprint 關聯 Token 生命週期，記錄 Actor、Tenant、Route、Decision、Reason、Object 類型、風險訊號與 Trace ID，並限制存取與保存期限。

API 業務邏輯與狀態機要怎麼測？

許多高衝擊問題不屬於單一 Payload，而是順序錯誤：未付款先出貨、已退款再次退款、取消後仍下載、未完成驗證就升級、同一邀請重複領取、並發 Request 造成重複扣款。掃描要把每個流程建成 State Machine，列出允許的 Transition、Actor、前置條件、次數、金額與不可變條件。

對每條合法 Transition 建立 Baseline，再測試跳步、倒序、重播、平行、過期、跨 Actor、跨 Tenant、負數／邊界值與 Client-Supplied State。完成證據來自最終狀態、Ledger、Inventory、Message、Audit Event 與對外副作用，不是單看某一次 Response。

自動化 DAST 能覆蓋哪些 API 問題？

有 Contract、可用憑證與安全測試資料時，自動化工具很適合做 Endpoint 發現、Schema 邊界、Injection Payload、Header／CORS／TLS 設定、已知 Pattern、Method、Content-Type、部分 BOLA 差異、Rate Limit 訊號與修復回歸。它能以固定頻率對相同資產產生一致證據。

但工具通常不知道『A 是否應看 B 的訂單』、『一張票最多能買幾張』、『這次退款是否符合業務條件』，也無法獨立確認所有 GraphQL Resolver、非同步副作用、第三方成本與組織允許的風險。這些需要 Threat Model、Contract Test、程式碼審查、人工測試與業務 Owner 判斷。

Authenticated API Scan 怎麼避免只拿到一堆 401？

掃描器需要可自動更新的測試憑證與明確最小權限。短效 Access Token 可透過受控 Test Client 或預掃描 Login Flow 取得；Service API 可使用專用 Client Credential；需要 MFA 的流程則以測試 IdP、受控 Automation 或人工 Gate 處理，不能把長效 Production Token 硬編碼在設定檔。

同一 Scan Job 依角色與 Tenant 分開執行，並使用獨立資料 Seed。Token 過期時應安全刷新，不把 Refresh Token 寫進 Report 或 Log；掃描結束後撤銷 Credential。Coverage 不是看到 2xx 的比例，而是每個 Endpoint／Method／Role／Object 狀態都有可重播 Baseline 與負向測試。

一套可稽核的 API 弱點掃描流程

流程從 Inventory 與合法授權開始，將 Contract、Schema、Client Traffic、Gateway 與 Source Route 合併成 Endpoint Catalog；接著建立身份與資料 Seed，取得每個 Role 的合法 Baseline，再逐一變更 Object、Field、Function、Token、State 與 Resource Dimension。每次測試都保留 Sanitized Request、Response、Actor、Target、Time 與後端副作用證據。

結果進入技術驗證時，要重播最小 Case、排除 Cache／Race／測試資料污染，映射 OWASP API Category、CWE、Asset Criticality 與 Business Impact。修復後以原 Request 複驗，並跑正常 Client Contract／Regression Test，確認不是把 200 一律改成 403 或破壞既有整合。

Production API 掃描如何控制風險？

Production 測試不應直接複製 Staging 的強度。使用明確識別的 Source、Header、User Agent、Test Tenant 與 Test Data，限制 Request Rate、Concurrency、Payload、Upload、Batch、GraphQL Cost 與外部費用。建立 Dashboard 觀察 Error Rate、Latency、CPU、DB、Queue、Third-Party Call 與告警，達到門檻立即停止。

對 Delete、Payment、Refund、Notification、Account Lock、Export、Webhook 與付費 API 使用 Dry Run、Sandbox、Mock、Feature Flag 或人工核准。掃描窗口結束要清理資料、撤銷 Token、確認 Queue 與 Job 沒有殘留，並保存 Scan ID 與 Change／Incident 關聯。

API Security 要怎麼進 CI/CD，而不是只在上線後掃？

在 Pull Request 階段檢查 Contract Diff、Security Scheme、敏感欄位、無上限 Array／Page Size、未授權 Route 與 Schema Breaking Change；在 Integration Environment 用多角色 Contract Test 驗證 401／403、BOLA、BOPLA、BFLA、Idempotency 與 GraphQL Cost；部署後再由外部 DAST 驗證真實 Gateway、DNS、TLS、CORS 與可到達版本。

Gate 必須以可行動的風險條件決定，而非任何 Scanner Finding 都阻擋。Confirmed Critical／High、核心授權回歸、敏感資料暴露與未核准 Public API 可直接停止；其餘依 SLA、Owner、資產與證據管理。Contract、Test、Inventory、Finding 與 Release 應共享 Service／Version Identifier。

API 弱點報告要包含哪些證據才可修？

報告應讓 Owner 在不接觸真實客戶秘密的前提下重現問題。最小欄位包含 Asset／Version、Endpoint／Operation、Actor／Role／Tenant、前置資料、Sanitized Request、Baseline 與 Negative Response、實際資料或狀態差異、OWASP API Category、CWE、Business Impact、修復方向與 Retest Condition。

BOLA 不能只寫『更換 ID 可存取』，要說明 A／B 身分、物件 Ownership、被讀或被改的欄位與後續狀態；Resource Consumption 不能只貼 Timeout，要提供合法限制、測試增量、Server Metric 與停止點；Business Flow Abuse 則要由產品 Owner 確認經濟與流程影響。

修復 API 弱點時，為什麼不能只封鎖一個 Payload？

封鎖某個 ID、字串、User Agent 或單一路徑，只會修掉掃描樣本。BOLA 的根因通常是 Domain Query 或 Policy 沒有綁 Actor；BOPLA 是 Serializer／Binder 沒有欄位 Allowlist；BFLA 是功能 Policy 漏套 Method；Resource Risk 是 Cost Model 與 Bound 缺失；Business Abuse 則需要流程與經濟控制。修復應放在可被所有版本與入口一致重用的 Enforcement Point。

複驗先重播原 Case，再擴展到同 Controller、同 Object Type、同 Resolver、其他 Method、Batch、Legacy Version 與不同角色，確認不是局部 Patch。最後跑合法 Client、Partner Contract、Mobile Legacy、Performance 與 Error Handling Regression，避免安全修復造成無聲整合故障。

修復後複驗要證明哪些事？

第一，原攻擊 Request 在相同 Actor、Object、Token 與狀態下必須失敗；第二，失敗不能留下資料、Job、Message、費用或部分更新；第三，同類入口與版本也受到相同控制；第四，合法 Owner、Admin、Partner 與 Mobile Client 仍能依 Contract 正常運作；第五，Log 與 Alert 能記錄被拒絕事件而不洩漏秘密。

對 Race、Idempotency、Refresh Rotation 與非同步流程，單次重播不足以結案，需重現並發與時間條件。對 Rate／Cost 類問題，要用核准增量測試證明 Limit 在昂貴工作前生效，且不會讓一個 Tenant 影響其他租戶。Closure Evidence 應綁定修復 Version 與部署 Artifact。

API Security 的最小可行導入路線圖

先不要從購買最多工具開始。第一階段建立所有 Public／Partner API 的 Inventory、Owner、Contract、資料分類與認證方式，先關閉未知 Host 與舊版本；第二階段為高價值 API 建立多角色授權矩陣、資源限制與業務流程 Threat Model；第三階段把 Contract、Policy Test、Authenticated DAST、Runtime Detection 與修復複驗接進 Release。

成熟後擴展到 Internal／Service API、GraphQL、Webhook、第三方 Consumption 與跨服務 Identity，建立統一的 Policy Library、Token Profile、Rate／Cost Model、Secure Logging 與 Exception Workflow。衡量 Coverage 時，使用 Asset、Operation、Role、Risk Axis、Verified Finding、Remediation Time 與 Retest Closure，不用單一『掃描完成率』。

API 弱點掃描最終檢查清單

掃描前，確認所有 Host、Version、Environment、Owner、Contract、資料分類、第三方依賴與合法授權；確認每個角色、Tenant、Object 與狀態都有專用測試資料與最小權限憑證。掃描中，除了 Injection 與設定，也要覆蓋 Object、Field、Function、Business Flow、Resource、Token、GraphQL 與第三方 Trust Boundary。

掃描後，所有 Finding 都有 Sanitized Evidence、Business Context、根因 Owner、SLA 與 Retest Condition；所有 Token 與測試資料已撤銷或清理；修復複驗同時證明攻擊失敗與合法 Client 正常。若這些條件沒有完成，就只能說某個工具執行過，不能說 API Security 已被驗證。

• Inventory 與實際部署、Gateway、Client Traffic、Contract 相符，舊版與 Beta 也在範圍內
• 至少有同角色雙主體、跨租戶、跨角色、過期／撤銷 Token 與關鍵狀態資料
• BOLA、BOPLA、BFLA、Business Flow、Resource、SSRF、Misconfiguration 與 Third-Party Trust 均有證據
• REST Method／Idempotency 與 GraphQL Depth／Cost／Batch／Resolver Authorization 已驗證
• Production 測試有速率、副作用、成本、監控、停止與清理控制
• 修復以根因與共用 Enforcement Point 完成，原 Case、同類入口與合法 Client 均通過複驗