雖然本質(zhì)上 API 就是拿來用的，但即便某個 API 的使用者全是內(nèi)部人員，它還是可能會出現(xiàn)安全問題。為了解決 API 安全問題，在本文我們收集了一系列 API 的最佳實踐，希望你記住這些 Tips 日后在保護 API/Web 服務(wù)安全和免受入侵時，會幫助到你。
1、使用 HTTPS
現(xiàn)在的 Web 已經(jīng)不是之前那個年代，標(biāo)準(zhǔn)的 HTTP 滿足不了 Web 安全需求。而各大瀏覽器供應(yīng)商開始標(biāo)記不使用安全層的 URL，你的 API 也可以考慮開始動手做這件事——用 HTTPS。HTTPS 采用傳輸層安全性協(xié)議（TLS）對傳輸進行加密。這意味著 HTTPS 對客戶端和服務(wù)器之間的通信進行加密。對 API 而言，HTTPS 意味著從 API 發(fā)送的內(nèi)容是受第三方保護的，但更重要的是這意味著訪問憑證是安全的。
2、認(rèn)證
說到訪問憑證，避免意外使用 API 的最直接的方法便是確保正確的身份驗證。身份驗證決定了你是否可訪問 API 及如何訪問某個 API，即便是對外開放的免費 API 理論上也應(yīng)當(dāng)考慮采用身份驗證策略以保證安全性。有了身份認(rèn)證，你可以限制或刪除濫用 API 的使用者，讓使用者在需要時重新設(shè)置憑證，從而保護他們的安全。了解更多有關(guān) API 身份驗證的知識可以閱讀《三種最常見的認(rèn)證方法》。
3、授權(quán)
起到和身份驗證類似作用的是授權(quán)。身份驗證和授權(quán)的區(qū)別在于，身份驗證關(guān)注的是 API 的使用者是誰，而授權(quán)關(guān)注的是他們能夠訪問的內(nèi)容。舉個例子，免費計劃用戶可能被授權(quán)只能訪問你所有 API 的某個子集。當(dāng)你想集成諸如社交登錄此類 API 時，用戶授權(quán)可讓應(yīng)用從社交平臺讀取他們的配置文件數(shù)據(jù)。
4、安全 endpoints 和資源（對象級授權(quán)）
一般來說，我們會通過授權(quán)來保護 endpoint/endpoints，但更長遠(yuǎn)來說，我們需要確保單個資源的安全。單個資源的安全可以防止錯誤配置的 endpoint 級授權(quán)訪問數(shù)據(jù)。此外，它還意味著 endpoint 本身不受用戶類型的限制，而是由資源控制誰能查看它，誰不能查看它。（精確到 URL 的權(quán)限）
5、限速
一說到安全，我們常會想到不適當(dāng)?shù)脑L問。當(dāng)然，如何處理不適當(dāng)?shù)脑L問對管理資源也很有用。限速是一種限制 API 使用的技術(shù)。它不僅在經(jīng)濟上保護資源，但也保證了服務(wù)器不會因某次大量的請求而超載。大多數(shù)限速的方法都基于時間的——一般會設(shè)置一個賬單周期來處理 API 總體使用情況，也會用“突發(fā)”方法來限制大量涌入的請求。如果你看到 429 HTTP 狀態(tài)代碼，說明你正在被限速。
6、驗證和凈化輸入
要攻擊 Web 程序最古老的方式之一是輸入，即：我們訪問數(shù)據(jù)的方式可能已經(jīng)改變，但是驗證任意用戶輸入的需要還沒有改變?？蛻舳蓑炞C有助于防止錯誤和改善用戶體驗，但是 API 還需要在對輸入執(zhí)行操作前驗證和凈化（sanitize）輸入——凈化策略為刪除請求中的惡意或無效代碼。驗證確保數(shù)據(jù)滿足資源期望的必要條件，例如：類型、形式，甚至是密碼結(jié)構(gòu)等因素。
7、按需公開
采用快捷方式將數(shù)據(jù)模型直接映射到接口是很誘人，但這不僅會產(chǎn)生冗長的響應(yīng)、增加帶寬使用，而且還會暴露用戶不需要訪問的數(shù)據(jù)。舉個例子：一個 /user 接口要返回用戶信息。它可能只要用戶的一些基本信息，而不需要用戶的密碼/權(quán)限。
8、錯誤消息的配置
除了對 API 的輸入數(shù)據(jù)進行凈化（sanitize）外，還需要對從中產(chǎn)生的信息進行凈化。錯誤消息對用戶了解問題的發(fā)生至關(guān)重要，但要確保不泄漏任何敏感數(shù)據(jù)。向終端用戶提供 API 內(nèi)部代碼結(jié)構(gòu)的詳細(xì)信息會為攻擊者提供便利，所以一定要確保錯誤信息的配置不僅能提供足夠的信息來幫助用戶調(diào)試，并提供足夠的信息讓他們報告問題，但又不足以暴露應(yīng)用程序的內(nèi)部工作和敏感數(shù)據(jù)。
9、不要暴露敏感信息
API 開放要建立在保護敏感數(shù)據(jù)之上，要確保不要在 JSON Web Token 和緩存中公開細(xì)節(jié)。JWT（JSON Web Token） body 給人一種很安全的錯覺，其實它很容易破譯。因此，應(yīng)該避免 JTW 和緩存中，包含可用于訪問應(yīng)用程序的用戶信息。同樣的建議也適用于 URL，要確保查詢字符串不會暴露敏感數(shù)據(jù)的細(xì)節(jié)。
10、評估依賴
開發(fā)過程中我們并不是完全自己編寫代碼，大多數(shù)情況下，代碼很大一部分會包含庫、中間件和各種來自外部源的依賴關(guān)系。雖然一般情況下我們可以認(rèn)為流行的軟件包是經(jīng)過實戰(zhàn)測試的，但即便如此，并不意味著這些依賴完全避免漏洞。因此，要確保你評估過 API 的依賴關(guān)系——它們維護得好嗎？你使用的是最新版本嗎？有什么歷史問題？也許最重要的事情是想一下：真的需要一個庫來實現(xiàn)你正在做的功能嗎?
11、允許用戶跟蹤和重置身份驗證密鑰
提高 API 安全性的另一種方法是允許用戶重置他們的憑證并監(jiān)視使用情況。一個常見的錯誤是不允許使用者重置他們的 API 密鑰。如果 API 使用者意外地公開了他們的密鑰，或者惡意獲取密鑰，那么這個問題現(xiàn)在會直接影響你的 API。相反，為了保證安全，你可以為他們創(chuàng)建一種管理訪問的方法。
12、標(biāo)準(zhǔn)化服務(wù)中的認(rèn)證
我們看到像谷歌、微軟和亞馬遜這樣的 API 巨頭都對它們的 API 授權(quán)和認(rèn)證過程進行了標(biāo)準(zhǔn)化。我們不妨考慮一種集中的方法，比如使用 API 網(wǎng)關(guān)或?qū)Ｓ玫娜肟邳c來處理身份驗證請求。
遵循 OWASP 標(biāo)準(zhǔn)指南
除了這些最佳實踐之外，可以考慮采用開放式 Web 應(yīng)用程序安全項目（Open Web Application Security Project，縮寫 OWASP）的建議。他們提供了特定平臺的指導(dǎo)，以及即將推出的特定 API 的指導(dǎo)——API 安全 Top 10。除了在代碼層面保護 API 之外，還需要確保正確配置服務(wù)器和基礎(chǔ)設(shè)施，以避免未經(jīng)授權(quán)的訪問。
本文來自博客園，原文鏈接https://www.cnblogs.com/xueweihan/p/13873707.html
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
