域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過

雖然本質(zhì)上 API 就是拿來用的，但即便某個(gè) API 的使用者全是內(nèi)部人員，它還是可能會(huì)出現(xiàn)安全問題。為了解決 API 安全問題，在本文我們收集了一系列 API 的最佳實(shí)踐，希望你記住這些 Tips 日后在保護(hù) API/Web 服務(wù)安全和免受入侵時(shí)，會(huì)幫助到你。

1、使用 HTTPS

現(xiàn)在的 Web 已經(jīng)不是之前那個(gè)年代，標(biāo)準(zhǔn)的 HTTP 滿足不了 Web 安全需求。而各大瀏覽器供應(yīng)商開始標(biāo)記不使用安全層的 URL，你的 API 也可以考慮開始動(dòng)手做這件事——用 HTTPS。HTTPS 采用傳輸層安全性協(xié)議（TLS）對(duì)傳輸進(jìn)行加密。這意味著 HTTPS 對(duì)客戶端和服務(wù)器之間的通信進(jìn)行加密。對(duì) API 而言，HTTPS 意味著從 API 發(fā)送的內(nèi)容是受第三方保護(hù)的，但更重要的是這意味著訪問憑證是安全的。

2、認(rèn)證

說到訪問憑證，避免意外使用 API 的最直接的方法便是確保正確的身份驗(yàn)證。身份驗(yàn)證決定了你是否可訪問 API 及如何訪問某個(gè) API，即便是對(duì)外開放的免費(fèi) API 理論上也應(yīng)當(dāng)考慮采用身份驗(yàn)證策略以保證安全性。有了身份認(rèn)證，你可以限制或刪除濫用 API 的使用者，讓使用者在需要時(shí)重新設(shè)置憑證，從而保護(hù)他們的安全。了解更多有關(guān) API 身份驗(yàn)證的知識(shí)可以閱讀《三種最常見的認(rèn)證方法》。

3、授權(quán)

起到和身份驗(yàn)證類似作用的是授權(quán)。身份驗(yàn)證和授權(quán)的區(qū)別在于，身份驗(yàn)證關(guān)注的是 API 的使用者是誰，而授權(quán)關(guān)注的是他們能夠訪問的內(nèi)容。舉個(gè)例子，免費(fèi)計(jì)劃用戶可能被授權(quán)只能訪問你所有 API 的某個(gè)子集。當(dāng)你想集成諸如社交登錄此類 API 時(shí)，用戶授權(quán)可讓應(yīng)用從社交平臺(tái)讀取他們的配置文件數(shù)據(jù)。

4、安全 endpoints 和資源（對(duì)象級(jí)授權(quán)）

一般來說，我們會(huì)通過授權(quán)來保護(hù) endpoint/endpoints，但更長(zhǎng)遠(yuǎn)來說，我們需要確保單個(gè)資源的安全。單個(gè)資源的安全可以防止錯(cuò)誤配置的 endpoint 級(jí)授權(quán)訪問數(shù)據(jù)。此外，它還意味著 endpoint 本身不受用戶類型的限制，而是由資源控制誰能查看它，誰不能查看它。（精確到 URL 的權(quán)限）

5、限速

一說到安全，我們常會(huì)想到不適當(dāng)?shù)脑L問。當(dāng)然，如何處理不適當(dāng)?shù)脑L問對(duì)管理資源也很有用。限速是一種限制 API 使用的技術(shù)。它不僅在經(jīng)濟(jì)上保護(hù)資源，但也保證了服務(wù)器不會(huì)因某次大量的請(qǐng)求而超載。大多數(shù)限速的方法都基于時(shí)間的——一般會(huì)設(shè)置一個(gè)賬單周期來處理 API 總體使用情況，也會(huì)用“突發(fā)”方法來限制大量涌入的請(qǐng)求。如果你看到 429 HTTP 狀態(tài)代碼，說明你正在被限速。

6、驗(yàn)證和凈化輸入

要攻擊 Web 程序最古老的方式之一是輸入，即：我們?cè)L問數(shù)據(jù)的方式可能已經(jīng)改變，但是驗(yàn)證任意用戶輸入的需要還沒有改變?？蛻舳蓑?yàn)證有助于防止錯(cuò)誤和改善用戶體驗(yàn)，但是 API 還需要在對(duì)輸入執(zhí)行操作前驗(yàn)證和凈化（sanitize）輸入——凈化策略為刪除請(qǐng)求中的惡意或無效代碼。驗(yàn)證確保數(shù)據(jù)滿足資源期望的必要條件，例如：類型、形式，甚至是密碼結(jié)構(gòu)等因素。

7、按需公開

采用快捷方式將數(shù)據(jù)模型直接映射到接口是很誘人，但這不僅會(huì)產(chǎn)生冗長(zhǎng)的響應(yīng)、增加帶寬使用，而且還會(huì)暴露用戶不需要訪問的數(shù)據(jù)。舉個(gè)例子：一個(gè) /user 接口要返回用戶信息。它可能只要用戶的一些基本信息，而不需要用戶的密碼/權(quán)限。

8、錯(cuò)誤消息的配置

除了對(duì) API 的輸入數(shù)據(jù)進(jìn)行凈化（sanitize）外，還需要對(duì)從中產(chǎn)生的信息進(jìn)行凈化。錯(cuò)誤消息對(duì)用戶了解問題的發(fā)生至關(guān)重要，但要確保不泄漏任何敏感數(shù)據(jù)。向終端用戶提供 API 內(nèi)部代碼結(jié)構(gòu)的詳細(xì)信息會(huì)為攻擊者提供便利，所以一定要確保錯(cuò)誤信息的配置不僅能提供足夠的信息來幫助用戶調(diào)試，并提供足夠的信息讓他們報(bào)告問題，但又不足以暴露應(yīng)用程序的內(nèi)部工作和敏感數(shù)據(jù)。

9、不要暴露敏感信息

API 開放要建立在保護(hù)敏感數(shù)據(jù)之上，要確保不要在 JSON Web Token 和緩存中公開細(xì)節(jié)。JWT（JSON Web Token） body 給人一種很安全的錯(cuò)覺，其實(shí)它很容易破譯。因此，應(yīng)該避免 JTW 和緩存中，包含可用于訪問應(yīng)用程序的用戶信息。同樣的建議也適用于 URL，要確保查詢字符串不會(huì)暴露敏感數(shù)據(jù)的細(xì)節(jié)。

10、評(píng)估依賴

開發(fā)過程中我們并不是完全自己編寫代碼，大多數(shù)情況下，代碼很大一部分會(huì)包含庫、中間件和各種來自外部源的依賴關(guān)系。雖然一般情況下我們可以認(rèn)為流行的軟件包是經(jīng)過實(shí)戰(zhàn)測(cè)試的，但即便如此，并不意味著這些依賴完全避免漏洞。因此，要確保你評(píng)估過 API 的依賴關(guān)系——它們維護(hù)得好嗎？你使用的是最新版本嗎？有什么歷史問題？也許最重要的事情是想一下：真的需要一個(gè)庫來實(shí)現(xiàn)你正在做的功能嗎?

11、允許用戶跟蹤和重置身份驗(yàn)證密鑰

提高 API 安全性的另一種方法是允許用戶重置他們的憑證并監(jiān)視使用情況。一個(gè)常見的錯(cuò)誤是不允許使用者重置他們的 API 密鑰。如果 API 使用者意外地公開了他們的密鑰，或者惡意獲取密鑰，那么這個(gè)問題現(xiàn)在會(huì)直接影響你的 API。相反，為了保證安全，你可以為他們創(chuàng)建一種管理訪問的方法。

12、標(biāo)準(zhǔn)化服務(wù)中的認(rèn)證

我們看到像谷歌、微軟和亞馬遜這樣的 API 巨頭都對(duì)它們的 API 授權(quán)和認(rèn)證過程進(jìn)行了標(biāo)準(zhǔn)化。我們不妨考慮一種集中的方法，比如使用 API 網(wǎng)關(guān)或?qū)Ｓ玫娜肟邳c(diǎn)來處理身份驗(yàn)證請(qǐng)求。

遵循 OWASP 標(biāo)準(zhǔn)指南

除了這些最佳實(shí)踐之外，可以考慮采用開放式 Web 應(yīng)用程序安全項(xiàng)目（Open Web Application Security Project，縮寫 OWASP）的建議。他們提供了特定平臺(tái)的指導(dǎo)，以及即將推出的特定 API 的指導(dǎo)——API 安全 Top 10。除了在代碼層面保護(hù) API 之外，還需要確保正確配置服務(wù)器和基礎(chǔ)設(shè)施，以避免未經(jīng)授權(quán)的訪問。

本文來自博客園，原文鏈接https://www.cnblogs.com/xueweihan/p/13873707.html

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！