什么是SQL注入？理解、風險與防范技巧
平均而言，API 數據泄露會給公司造成381 萬美元的損失，這還不包括 IBM 所認為的“超級泄露”，這類泄露平均會給公司造成 5000 萬美元以上的損失。
再加上幾乎25%的美國人不會與數據泄露的組織做任何生意，您需要了解基本的 API 安全措施，以避免成為統計數據。
以下是每個現代開發人員都應該知道的十個基本 API 安全最佳實踐，以確保他們的數據安全。
API 安全始于身份驗證和授權協議。
他們幫助防止 API 用戶訪問不屬于他們的數據或他們無權查看的信息– 屬于 OWASP API 安全性 Top 10 列表頂部的漏洞組。
受到推崇的：?OWASP API 安全性十大列表是什么？
在處理敏感的財務、醫療保健和政府記錄時，這一點尤為重要，因為如果沒有適當的 API 身份驗證和授權協議，黑客可以利用這些數據謀取私利。
身份驗證和授權協議的一些示例包括：
盡管身份驗證和授權可以說是 API 安全的最重要元素，但數據加密也同樣重要。
一旦數據進入 API，使用加密可防止其他用戶未經授權訪問。
這意味著無論數據狀態如何，都要創建數據加密 – 無論是存儲、通過網絡或互聯網傳輸，還是靜止。
靜態數據是保存在計算機上的任何 API 數據。您可以使用行業標準的高級加密標準 (AES) 算法（稱為 Rijndael 密碼）通過 AES 256 位加密來保護它。
您可以同樣保護存儲的數據，同時使用 2048 位加密通過 SSL/TLS 加密傳輸數據。
正確加密的數據將防止與敏感數據相關的安全漏洞等。
定期的數據完整性檢查可確保敏感數據在傳輸之前、之后或傳輸過程中不會發生變化。
散列是執行此類檢查的最常用方法之一。對數據進行散列后，您可以將散列值與原始值進行比較。
正確執行的數據完整性檢查將確保收到的信息與服務器發送的或存儲在硬盤上的信息相匹配。
完整性檢查可確保 API 請求得到安全處理并根據一組標準化策略進行驗證，從而幫助開發人員保護他們的資源。
最好的 API 安全實踐之一包括記錄可審計事件（例如登錄失敗或大型交易）以用于分析目的。
日志記錄不足在 OWASP 列表中排名第 10，這意味著存在重大安全風險，可能導致您的系統在發生主動攻擊時無法觸發任何警報。
此外，如果沒有任何日志，就很難證明黑客犯了罪，或者在發布后排除任何錯誤或漏洞。
充分實施的安全日志使您能夠密切監視用戶和任何可疑活動。
一旦縮小了可疑來源的范圍，您就可以構建一些閾值、規則或參數來進一步保護數據。
代碼審查是提高軟件質量的一種行之有效的方法。因此，定期進行代碼審查可以幫助您在攻擊者利用漏洞之前識別出任何 API 漏洞。
您可以通過多種方式定期進行代碼審查。例如，您可能希望每月至少安排一次團隊會議來討論所有更改，并確保您的 API 團隊審查所有相關的代碼更改，尤其是涉及開源工具時。
手動和自動代碼審查相結合將使您比網絡犯罪分子更具優勢。
為了覆蓋所有基礎，安全專業人員或滲透測試工具應定期分析公共 API，以便在黑客利用漏洞之前識別漏洞。
由于基本身份驗證實施不力，網站、API 服務和云應用程序經常成為成功的網絡攻擊的目標。
雙因素身份驗證，有時也稱為多因素身份驗證，通過要求兩步來訪問用戶數據，消除了單源登錄的弱點。
輸入正確的用戶名和密碼組合將要求用戶提交第二個身份驗證因素（發送到他們的電子郵件地址或電話的代碼），提供第二層保護。
您可以為您的 API 使用的三種基本身份驗證類型如下：
實施雙重身份驗證可阻止黑客的攻擊。因此，2FA 被視為基本 API 安全的必備措施也就不足為奇了。
網關可確保所有請求都得到安全處理并根據一組標準化策略進行驗證，從而幫助 API 提供商保護其資源。
有了 API 網關安全保護，您就不必擔心直接保護 API 端點。相反，它們提供與防火墻為服務器和網絡提供的相同保護層：它們位于客戶端和受保護的后端服務之間。
您的 API 網關將審查來自授權用戶的任何傳入請求，并將其引導通過管理系統進行進一步審核。
網關的主要功能取決于實施目標。大多數網關側重于以下安全機制：
測試軟件會檢查 API 質量和安全問題方面的所有問題：它可以在錯誤或故障到達用戶群之前識別它們，同時還能加強源代碼。
有多種方法可以全面測試您的 API，包括（但不限于）：
受到推崇的：?您應該知道的 API 術語完整列表
這些手動或自動測試中的每一個都可以發現新的安全問題和漏洞，從而使您的 API 暴露給黑客。
當開發人員可以訪問完善的 API 文檔時，他們可以運行自己的測試以確保他們的 API 按預期工作。
如果您構建了具有公共訪問權限的 API 或在開發人員中實現廣泛采用，則手動測試是一個不錯的選擇。
但是，如果只有內部業務部門才能訪問您的 API，那么自動化測試是將成本控制在預算限制之內的最佳方法。
如果您想防止 API 基礎設施因過多請求而超載（包括 DDoS 和暴力攻擊），最好使用某種類型的速率限制來限制 API 請求。
速率限制是 API 安全的重要組成部分，可以保護重要的軟件資源。
它們通過限制 API 請求的數量或 API 在給定時間段內可以處理的流量量來工作。
如果應用程序超出速率限制，系統將阻止來自特定用戶或 IP 地址的傳入流量并生成錯誤代碼。
限制 API 限制是防止 API 濫用的最佳方法之一。這樣，您就不會讓外部用戶以過多的每秒請求數 (RPS) 壓垮您的 API，從而給后端資源帶來壓力，并可能在推送合法流量的同時降低系統性能。
最后要牢記的 API 安全實踐是限制不必要的信息傳播。無論您的 API 的用途是什么，每次執行 API 請求時，限制向最終用戶透露的數據量都至關重要。
在 API 數據管理方面，黃金法則如下：不要讓用戶發送超出他們需要的信息 – 因為這會產生安全漏洞，使您的 API 面臨風險。
如果 API 客戶端在其請求中發送了太多不必要的信息，請設置一個 API 端點，返回必要信息并忽略其余信息。
組織需要將發布 API 文檔的方式納入中央門戶，作為其 CI/CD 流程的一部分。這樣，就可以從單一來源了解哪些 API 可用、它們位于何處以及誰負責它們。
通常，這包括在 API 層設置治理層，并從后端和前端系統中抽象出 API 基礎設施，以便它充當客戶端和目標后端系統之間的粘合劑。
這樣，您就可以在 API 基礎設施或 API 平臺層進行集中治理。
這使您能夠讓開發人員以及內部和外部合作伙伴加入，并為他們提供標準化的入職和 API 文檔方法 – 同時版本管理和修訂控制使您能夠處理 API 定期更改的情況。
對于許多組織而言，只有在發布 API 后，治理才成為關注的問題。這種方法行不通，因為如果文檔不充分，潛在客戶就會轉向其他地方。
治理需要從一開始就建立起來，并強制執行到開發流程中。采用自下而上的治理方法可以產生主觀性，并避免由于只有少數人組成的小組委員會不了解 API 的各個方面而造成的限制。
許多缺乏這種治理的組織都已發布和未發布 API，從而造成了漏洞。這些 API 需要進行審核，以記錄每種 API 的風險類型以及如何減輕這些風險。
使用 IP 白名單作為安全措施為 API 安全提供了良好的基礎，但應輔以其他安全措施。
具有最少 API 的小型組織可能會考慮這種選擇，但它仍應包含零信任模型。
他們應該將 IP 白名單與分層安全和地理圍欄等其他技術結合起來，以避免過度依賴一種保護形式。
API 從根本上改變了代碼投入生產的頻率。傳統的安全測試并不一定能以 DevOps 的速度運行。
因此，自動化流程并融入開發周期的工具和技術可幫助組織不再依賴被動方法來規避攻擊。
軟件配置分析測試需要納入流程，以避免安全配置錯誤。借助 API 管理解決方案，組織可以實現精細控制，以持續監控和降低風險。
隨著越來越多的應用程序進入市場，API 安全性比以往任何時候都更加重要。
無論你感覺多么無懈可擊，事實是，2021 年全年已有數百萬次網絡攻擊獲取敏感數據 – 而且這種令人擔憂的趨勢短期內沒有放緩的跡象。
API 使用者依賴提供商來保證其個人數據的安全。當發生數據泄露時，風險可能很高：
但事情并不一定非得如此。
文章來源：10 Essential API Security Best Practices To Protect Your Data
