> 原文地址：[API Security Best Practices](https://dev.to/bearer/api-security-best-practices-3gjl) > > 原文作者：Mark Michon > > 譯者 & 校正：HelloGitHub-小魚乾 & HelloGitHub-鴨鴨 雖然本質上 API 就是拿來用的，但即便某個 API 的使用者全是內部人員，它還是可能會出現安全問題。為了解決 API 安全問題，在本文我們收集了一系列 API 的最佳實踐，希望你記住這些 Tips 日後在保護 API/Web 服務安全和免受入侵時，會幫助到你。 ## 1、使用 HTTPS 現在的 Web 已經不是之前那個年代，標準的 HTTP 滿足不了 Web 安全需求。而各大瀏覽器供應商開始標記不使用安全層的 URL，你的 API 也可以考慮開始動手做這件事——用 HTTPS。HTTPS 採用傳輸層安全性協議（TLS）對傳輸進行加密。這意味著 HTTPS 對客戶端和伺服器之間的通訊進行加密。對 API 而言，HTTPS 意味著從 API 傳送的內容是受第三方保護的，但更重要的是這意味著訪問憑證是安全的。 ## 2、認證 說到訪問憑證，避免意外使用 API 的最直接的方法便是確保正確的身份驗證。身份驗證決定了你是否可訪問 API 及如何訪問某個 API，即便是對外開放的免費 API 理論上也應當考慮採用身份驗證策略以保證安全性。有了身份認證，你可以限制或刪除濫用 API 的使用者，讓使用者在需要時重新設定憑證，從而保護他們的安全。瞭解更多有關 API 身份驗證的知識可以閱讀[《三種最常見的認證方法》](https://blog.bearer.sh/the-three-most-common-api-authentication-methods/)。 ## 3、授權 起到和身份驗證類似作用的是授權。身份驗證和授權的區別在於，身份驗證關注的是 API 的使用者是誰，而授權關注的是他們能夠訪問的內容。舉個例子，免費計劃使用者可能被授權只能訪問你所有 API 的某個子集。當你想整合諸如社交登入此類 API 時，使用者授權可讓應用從社交平臺讀取他們的配置檔案資料。 ## 4、安全 endpoints 和資源（物件級授權） 一般來說，我們會通過授權來保護 endpoint/endpoints，但更長遠來說，我們需要確保單個資源的安全。單個資源的安全可以防止錯誤配置的 endpoint 級授權訪問資料。此外，它還意味著 endpoint 本身不受使用者型別的限制，而是由資源控制誰能檢視它，誰不能檢視它。（精確到 URL 的許可權） ## 5、限速 一說到安全，我們常會想到不適當的訪問。當然，如何處理不適當的訪問對管理資源也很有用。限速是一種限制 API 使用的技術。它不僅在經濟上保護資源，但也保證了伺服器不會因某次大量的請求而超載。大多數限速的方法都基於時間的——一般會設定一個賬單週期來處理 API 總體使用情況，也會用“突發”方法來限制大量湧入的請求。如果你看到 [429 HTTP 狀態程式碼](https://blog.bearer.sh/error-429-too-many-requests-what-to-do-when-youve-been-rate-limited/)，說明你正在被限速。 ## 6、驗證和淨化輸入 要攻擊 Web 程式最古老的方式之一是輸入，即：我們訪問資料的方式可能已經改變，但是驗證任意使用者輸入的需要還沒有改變。客戶端驗證有助於防止錯誤和改善使用者體驗，但是 API 還需要在對輸入執行操作前驗證和淨化（sanitize）輸入——淨化策略為刪除請求中的惡意或無效程式碼。驗證確保資料滿足資源期望的必要條件，例如：型別、形式，甚至是密碼結構等因素。 ## 7、按需公開 採用快捷方式將資料模型直接對映到介面是很誘人，但這不僅會產生冗長的響應、增加頻寬使用，而且還會暴露使用者不需要訪問的資料。舉個例子：一個 `/user` 介面要返回使用者資訊。它可能只要使用者的一些基本資訊，而不需要使用者的密碼/許可權。 ## 8、錯誤訊息的配置 除了對 API 的輸入資料進行淨化（sanitize）外，還需要對從中產生的資訊進行淨化。錯誤訊息對使用者瞭解問題的發生至關重要，但要確保不洩漏任何敏感資料。向終端使用者提供 API 內部程式碼結構的詳細資訊會為攻擊者提供便利，所以一定要確保錯誤資訊的配置不僅能提供足夠的資訊來幫助使用者除錯，並提供足夠的資訊讓他們報告問題，但又不足以暴露應用程式的內部工作和敏感資料。 ## 9、不要暴露敏感資訊 API 開放要建立在保護敏感資料之上，要確保不要在 [JSON Web Token](https://jwt.io/) 和快取中公開細節。JWT（JSON Web Token） body 給人一種很安全的錯覺，其實它很容易破譯。因此，應該避免 JTW 和快取中，包含可用於訪問應用程式的使用者資訊。同樣的建議也適用於 URL，要確保查詢字串不會暴露敏感資料的細節。 ## 10、評估依賴 開發過程中我們並不是完全自己編寫程式碼，大多數情況下，程式碼很大一部分會包含庫、中介軟體和各種來自外部源的依賴關係。雖然一般情況下我們可以認為流行的軟體包是經過實戰測試的，但即便如此，並不意味著這些依賴完全避免漏洞。因此，要確保你評估過 API 的依賴關係——它們維護得好嗎？你使用的是最新版本嗎？有什麼歷史問題？也許最重要的事情是想一下：真的需要一個庫來實現你正在做的功能嗎? ## 11、允許使用者跟蹤和重置身份驗證金鑰 提高 API 安全性的另一種方法是允許使用者重置他們的憑證並監視使用情況。一個常見的錯誤是不允許使用者重置他們的 API 金鑰。如果 API 使用者意外地公開了他們的金鑰，或者惡意獲取金鑰，那麼這個問題現在會直接影響你的 API。相反，為了保證安全，你可以為他們建立一種管理訪問的方法。 ## 12、標準化服務中的認證 我們看到像谷歌、微軟和亞馬遜這樣的 API 巨頭都對它們的 API 授權和認證過程進行了標準化。我們不妨考慮一種集中的方法，比如使用 API 閘道器或專用的入口點來處理身份驗證請求。 ## 遵循 OWASP 標準指南 除了這些最佳實踐之外，可以考慮採用[開放式 Web 應用程式安全專案](https://owasp.org/)（Open Web Application Security Project，縮寫 OWASP）的建議。他們提供了特定平臺的指導，以及即將推出的特定 API 的指導——[API 安全 Top 10](https://owasp.org/www-project-api-security/)。除了在程式碼層面保護 API 之外，還需要確保正確配置伺服器和基礎設施，以避免未經授權的訪問。 > 譯者有話說：本文的最後一段作者安利了自家產品，因此譯者不做翻譯，本文若有任何更佳的翻譯，歡迎留言交流^^ --- **加入 HelloGitHub 的「譯文亦舞」系列** 要求： - 平時閱讀 GitHub、開源、程式設計、程式設計師 的英文資訊和文章 - 每月至少翻譯或校正 1 篇文章 - 翻譯不失原味且通順 - 瞭解 Markdown、排版規則 歡迎優秀的你加入，讓你的才華舞動起來！把優秀的文章分享給更多的人。我的微信：xueweihan （備註：