使用DeepSeek和Claude繪制出高質量的SVG 圖片
但是，如果該實體有任何 PII 或其他信息，那么黑客就可以抓取該端點以獲取數據庫中所有實體的轉儲。如果這些實體意外泄露了 PII 或其他敏感信息，這可能是最危險的，但也可能為競爭對手或其他人提供您企業的采用和使用統計數據，或為詐騙者提供獲取大量電子郵件列表的方法。看看 Venmo 數據是如何被提取的
一種簡單的保護機制是檢查執行次數，如果大于 100 或 1000，則拋出錯誤。這種機制的問題有兩個方面：
skip = 0
while True:
response = requests.post('https://api.acmeinc.com/widgets?take=10&skip=' + skip),
headers={'Authorization': 'Bearer' + ' ' + sys.argv[1]})
print("Fetched 10 items")
sleep(randint(100,1000))
skip += 10為了防止分頁攻擊，您應該跟蹤每個用戶或 API 密鑰在特定時間段內訪問了單個資源的項目數，而不僅僅是在請求級別。通過跟蹤用戶級別的 API 資源訪問
大多數 API 都受到某種 API 密鑰或 JWT（JSON Web 令牌）的保護。這提供了一種跟蹤和保護 API 的自然方式，因為 API 安全工具可以檢測異常的 API 行為并自動阻止對 API 密鑰的訪問。然而，黑客會通過從大量用戶生成和使用大量 API 密鑰來超越這些機制，就像網絡黑客會使用大量 IP 地址來規避 DDoS 保護一樣。
防范此類攻擊的最簡單方法是要求人工注冊您的服務并生成 API 密鑰。可以使用 Captcha 和雙因素身份驗證等技術來阻止機器人流量。除非有合法的商業案例，否則注冊您服務的新用戶不應能夠以編程方式生成 API 密鑰。相反，只有受信任的客戶才應該能夠以編程方式生成 API 密鑰。更進一步，確保在用戶和帳戶級別（而不僅僅是每個 API 密鑰）對任何異常行為進行異常檢測。
API 的使用方式會增加憑證泄露的可能性：
如果由于用戶錯誤而泄露密鑰，人們可能會認為您作為 API 提供商應該承擔責任。但是，安全性的關鍵在于減少接觸面積和風險。請像對待自己的數據一樣對待客戶數據，并通過添加防止意外泄露密鑰的保護措施來幫助他們。
防止密鑰泄露的最簡單方法是利用兩個令牌而不是一個。刷新令牌存儲為環境變量，只能用于生成短期訪問令牌。與刷新令牌不同，這些短期令牌可以訪問資源，但有時間限制，例如幾小時或幾天。
客戶將與其他 API 密鑰一起存儲刷新令牌。然后，您的 SDK 將在 SDK 初始化時或最后一個訪問令牌過期時生成訪問令牌。如果 CURL 命令被粘貼到 GitHub 問題中，那么黑客需要在數小時內使用它，從而減少攻擊媒介（除非它是實際的刷新令牌，但可能性很低）
API 開辟了全新的商業模式，客戶可以通過編程方式訪問您的 API 平臺。然而，這可能會使 DDoS 保護變得棘手。大多數 DDoS 保護旨在吸收和拒絕來自惡意行為者的大量請求DDoS 攻擊
API 的神奇之處在于幾乎每次訪問都需要 API 密鑰。如果請求沒有 API 密鑰，您可以自動拒絕它，這對您的服務器來說很輕量（確保在后續中間件（如請求 JSON 解析）之前盡早完成身份驗證）。那么，您如何處理經過身份驗證的請求？最簡單的方法是利用每個 API 密鑰的速率限制計數器，例如每分鐘處理 X 個請求，并拒絕那些超過閾值的請求。429 HTTP response.有多種算法可以做到這一點，例如漏桶和固定窗口計數器。
在良好的服務器衛生方面，API 與 Web 服務器并無不同。由于 SSL 證書配置錯誤或允許非 HTTPS 流量，數據可能會泄露。對于現代應用程序，幾乎沒有理由接受非 HTTPS 請求，但客戶可能會錯誤地從其應用程序或 CURL 發出非 HTTP 請求，從而暴露 API 密鑰。API 沒有瀏覽器的保護，因此 HSTS 或重定向到 HTTPS 之類的東西無法提供保護。
通過以下網址測試您的 SSL 實現Qualys SSL 測試REST API 跨源資源共享權威指南
API 提供對每個 API 密鑰范圍內的動態數據的訪問。任何緩存實現都應該能夠將范圍限定到 API 密鑰，以防止交叉污染。即使您不在基礎架構中緩存任何內容，也可能使客戶面臨安全漏洞。如果使用代理服務器的客戶使用多個 API 密鑰（例如一個用于開發，一個用于生產），那么他們可能會看到交叉污染的數據。為了避免這種潛在的漏洞，建議購買移動代理可以為每個用戶或應用程序提供增強的安全性和專用隔離的服務。
這有多嚴重？參見 Twitter 在數據安全事件后披露賬單信息泄露
你應該確保緩存控制標頭已正確配置。
API 的一個大問題是，許多 API 不使用標準Authorization標頭，而是使用自定義標頭，如X-Api-Key。緩存服務器不知道此請求是否經過身份驗證，因此選擇緩存該請求。
app.use((req, res, next) => {
res.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate');
res.setHeader('Pragma', 'no-cache');
// ...
});這是 OWASP 十大 API 安全項目。大多數漏洞研究表明，檢測數據泄露的時間超過 200 天。如果您沒有適當的 API 日志記錄和監控，攻擊者可以繼續使用相同的漏洞，甚至探測更多漏洞。
您應該確保您的 API 日志記錄不僅跟蹤 API 請求本身，還應與用戶相關聯以進行用戶行為分析并存儲至少一年。這些系統應受到保護，以確保數據不會被意外刪除或提前退出。出于安全目的，GDPR 和 CCPA 為 API 審計日志提供了例外情況。解決方案包括Moesif API 安全性為 API 產品提供全套 API 監控和分析，只需幾分鐘即可開始使用。
同一 API 服務可能具有供外部和外部使用的端點。端點未記錄并不意味著黑客無法調用它。除了使用身份驗證和授權方案進行保護外，您還應確保這些端點完全不暴露在公共互聯網上，這可以在負載均衡器或 API 網關內完成。這有助于提供多層次的安全性，這是一種常見的預防策略。
雖然大多數 API 開發人員都會添加全局身份驗證方案（例如 API 密鑰或 OAuth）來驗證人員身份，但授權也是必需的，并且與身份驗證分開，因此實施起來比較困難。授權涉及檢查此人（已識別）是否可以訪問特定資源。這可以通過 API 范圍、檢查租戶 ID 或用戶 ID 等來完成。
由于授權特定于您的應用程序邏輯，并且并非總是橫切的，因此它可能是開發人員容易忘記的一個領域。除非您的對象標識符具有足夠的熵，否則黑客可以通過迭代輕松測試不同的 ID。對于在插入時增加 ID 的 SQL 數據庫來說尤其如此。
確保經過身份驗證的用戶有權訪問生成 API 響應所需的所有資源。這可能涉及檢查與相關對象關聯的用戶 ID 或訪問控制列表 (ACL)。有關如何處理授權的更多信息，請查看我們的帖子《為RESTful API構建身份驗證和授權的步驟》
原文地址：https://www.moesif.com/blog/technical/api-security/API-Security-Threats-Every-API-Team-Should-Know/
