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