API（應用程式程式設計介面）使軟體系統和應用程式能夠進行通訊和共享資料。API 測試非常重要，因為 API 中的漏洞可能會破壞網站的機密性、完整性和可用性的核心方面。所有動態網站都由 API 組成，因此SQL 注入等經典 Web 漏洞可以歸類為 API 測試。在本主題中，我們將教您如何測試網站前端未充分使用的 API，重點是 RESTful 和 JSON API。
一.api偵察
要開始 API 測試，首先需要儘可能多地找出有關 API 的資訊，以發現其攻擊面。
首先，您應該確定 API 端點。這些是 API 接收有關其伺服器上特定資源的請求的位置。例如，考慮以下GET請求：
GET /api/books HTTP/1.1
Host: example.com
此請求的 API 端點是/api/books。這將導致與 API 的互動以從圖書館檢索書籍列表。另一個 API 端點可能是，例如， /api/books/mystery它將檢索神秘書籍列表。
確定端點後，您需要確定如何與它們互動。這使您能夠構建有效的 HTTP 請求來測試 API。例如，您應該找出有關以下內容的資訊：
1.API 處理的輸入資料，包括強制引數和可選引數。
2.API 接受的請求型別，包括支援的 HTTP 方法和媒體格式。
3.速率限制和身份驗證機制。
二.api文件
API 通常會有文件記錄，以便開發人員知道如何使用和整合它們。
文件既可以採用人可讀的形式，也可以採用機器可讀的形式。人可讀文件旨在幫助開發人員瞭解如何使用 API。它可能包括詳細的說明、示例和使用場景。機器可讀文件旨在由軟體處理，以自動執行 API 整合和驗證等任務。它以 JSON 或 XML 等結構化格式編寫。
API 文件通常是公開的，特別是當 API 旨在供外部開發人員使用時。如果是這種情況，請始終透過檢視文件來開始偵察。
1.發現 API 文件
即使 API 文件未公開，您仍然可以透過瀏覽使用該 API 的應用程式來訪問它。
為此，您可以使用Burp Scanner來抓取 API。您也可以使用 Burp 的瀏覽器手動瀏覽應用程式。查詢可能引用 API 文件的端點，例如：
/api
/swagger/index.html
/openapi.json
如果您確定了資源的端點，請務必調查基本路徑。例如，如果您確定了資源端點 /api/swagger/v1/users/123，則應調查以下路徑：
/api/swagger/v1
/api/swagger
/api
第一個靶場：
在實驗開始前請掛上burpsuite，如果不會配置瀏覽器的burpsuite代理，使用burpsuite的內建瀏覽器開啟實驗也可以，我就是使用burp內建瀏覽器開啟的實驗。
要解決該實驗，請找到公開的 API 文件並刪除carlos。您可以使用以下憑據登入到您自己的帳戶：wiener:peter。根據實驗室的提示可以看看my acount這個按鈕。
根據提示，輸入賬戶資訊
發現可以更新自己的郵箱
在burp的請求history功能中看到了一個疑似與api有關的請求
可以看到該請求包是用於更新郵箱的
還記得在api測試的理論學習中的這句話嗎？
如果您確定了資源的端點，請務必調查基本路徑。例如，如果您確定了資源端點 /api/swagger/v1/users/123，則應調查以下路徑：
/api/swagger/v1
/api/swagger
/api
沒錯，它給了我們啟發。
我們把/api後面的引數刪掉，繼續進行請求試試
複製連結用瀏覽器開啟。
發現了一個rest api的功能。
可以看到這個rest api已經把如何使用它進行請求很明確地告訴我們了。
點選get會發現這裡面內嵌了請求工具，發現使用get請求就是獲取到使用者的個人資訊
使用delete方法就是刪除使用者。那麼我們如果使用delete請求，就可以刪掉carlos使用者了。
而最後一個options請求方法是用來更新郵箱的介面。
至此，我們完成了第一個實驗室。