一、前言

伴隨著移動互聯網時代的飛速發展，人手一部智能機連接這個世界已經成為現狀，隱私和安全問題也逐漸被越來越多的人重視。從 2021 年某滴安全信息泄露的消息公之于眾后，人們對于信息安全的呼聲和訴求也越發高漲。

回到正題，不管是 App，還是各個訪問終端的入口，作為最終承載交互數據的來源 — API 接口，無疑需要對數據的安全訪問提供最終的支撐和保障。接下來，讓我們花點時間來聊聊關于 API 接口安全的那些事吧。

二、API 安全常見問題

經常聽人說，某某系統被黑了，某某 app 的短信 1 分鐘內被狂刷了幾萬條，某某應用的系統癱瘓了...諸如此類不一而足。追根溯源，從問題分析的經驗來看，不管系統攻擊者采用何種手段，多數情況下，最終攻擊的入口，或者說最終的受害者還是匯聚到了API 這一層，可見，API 可以說是系統的守衛員，不容有失。

關于 API 的常見安全問題有哪些呢？小編這里結合多年的實踐經驗，做了如下的一些總結以供參考。

2.1 接口被惡意調用

當系統的某些接口被攻擊者或別有用心的人惡意調用時，可能有如下表現：

• 系統被狂刷短信...
• 某個頁面直接卡死，導致其他用戶無法訪問頁面...
• 系統服務器 CPU 瞬間飆升...
• 平臺內關聯的其他應用也無法正常使用...

為什么 API 接口會被惡意調用呢？經驗來看，無非就那點，樹大招風，你的產品被競爭對手盯上了，人家眼紅了。

2.2 接口數據被篡改

這也是一種比較場景的 API 安全問題，一個常見的場景就是，當你登錄某個系統時，你的會話信息，像存在瀏覽器中的 cookie 信息，被別有用心者劫持了，然后這個人拿著你的信息冒充你的身份去請求 API 的數據，甚至修改你的數據返回給你進行詐騙等目的。使用過 Fiddler 抓包工具的同學可以在自己公司的產品中模擬下這個過程。

2.3 接口敏感數據被竊取

通常在 B 端產品中，會對某些 API 返回的部分字段數據進行脫敏，比如手機號，郵箱等，以保證用戶的信息隱私。

盡管 API 層面對敏感數據做了脫敏處理，但敏感數據如果未進行加密處理，或加密的強度不夠，或者沒有安全的存儲加密數據，以至于攻擊者仍然能夠獲得敏感信息，進而攻擊者可能利用此漏洞對客戶端，或服務器發送特殊構造的數據，發出攻擊，從而了解后臺數據庫表等信息，對系統安全構成威脅。這也就是接口敏感數據被竊取了。

2.4 XSS 攻擊

深究起來，XSS 攻擊更多偏向于前端這一層，但是對于一個能夠提供充分安全保障的系統來說，API 的對于參數的安全校驗也是非常重要的一環，對于系統來說，應該確保核心 API 的業務對于所有的入參都應該是安全，可信且經過校驗之后才能進行數據存儲的。這樣可以從源頭上保障 XSS 攻擊影響的范圍進一步縮小。

三、系統層面的安全防護解決措施

在系統架構設計之初，系統安全一定是一個重要的考量因素被納入到架構設計規劃中，系統安全關乎著既關乎公司的生存，也關乎產品的盈利，更進一步說，更關乎著法律法規對公司的監管合規性依據。下圖所示，為一個通用的微服務業務架構圖。

從實踐經驗來看，安全在一個系統的架構設計中占據著舉足輕重的地位，從上圖來看，可以說，安全考慮在架構設計的每一環都有著落地的目標，拆開來看，具體如下所述。

3.1 前端安全

涉及到前端安全的技術，比如：

• 頁面表單的防重提交（功能上限制防刷的可能性）；
• 接口請求前關鍵參數的校驗，脫敏，XSS 不安全字符的自動識別；
• 使用參數加密，Base64 處理，禁止明文傳輸;

3.2 系統級防火墻

防火墻本身具有較強的抗攻擊能力，它是提供信息安全服務、實現網絡和信息安全的基礎設施之一。

防火墻對于一個互聯網公司的重要意義毋庸置疑，尤其是金融類，銀行類等 B 端產品，防火墻的作用可以說是不可替代的，盡管這個技術已經不是什么新鮮的東西，但基本上所有的軟件公司在產品發布到線上環境之后，所有來自外部的請求，都會經過服務器廠商的防火墻，只有通過了防火墻這一層請求才能繼續往下進行。

關于防火墻的作用，這里簡單列舉如下：

• 防止來自被保護區域外部的攻擊，保護易受攻擊的網絡服務資源和客戶資源；
• 集中安全管理，通過集中的安全策略配置，以便統一管理和執行安全政策；
• 防止信息外泄和屏蔽有害信息，執行安全檢查，嚴格控制進出網絡的數據，過濾和屏蔽有害信息，防止信息外泄；
• 安全審計和告警，通過對網絡存取訪問進行監控審計，有效跟蹤各類網絡活動，及時發現問題和及時報警。

3.3 網關

關于網關，基本上所有的人都多少有一定的了解，網關在一個安全的系統架構設計中的作用，可以說是承上啟下，至關重要，大體來說，從安全的角度來講，主要體現在如下幾個方面：

屏蔽真實的API地址

拿 Nginx 來說，如果后端的接口真實地址是：/API/v2/user/get/1，為了確保接口安全，屏蔽真實的地址，通過nginx 的反向代理之后，接口可能變成這樣：
/platform/biz/API/v2/user/get/1。

負載均衡，均衡流量

從系統安全和系統可用性的角度講，為了確保系統的高可用性，通常應用服務集群部署，這樣可以避免單節點壓力過大而造成業務高峰時系統不可用，有了網關這一層，就可以通過網關的配置動態實現負載均衡，以達到均衡流量的效果，從而對系統過載形成防護。

攔截惡意請求，定向黑白名單

以 nginx 來說，提供了可編程式的配置，通過編寫腳本代碼，對經過 nginx 的請求進行監控，尤其是對于那些惡意刷接口的請求，可以很好的進行識別，甚至可以在 nginx 這一層對那些惡意請求的 IP，IP 段進行黑名單的設置，從而對后臺的服務進行第一層的安全防護。

限流

對一個系統來說，可用性已然成了系統是否穩定的考量因素的重要標準，當業務高峰期時，不管是外部的惡意請求，還是類似搶單這樣的瞬間大流量來說，為了保障系統的整體可用性，必要的限流措施也是確保系統安全的重要手段，而網關作為承載系統流量的入口，在網關這一層做一定的限流管控是很有必要的。

四、API 層面安全設計的常用解決方案

以上從架構設計層面聊了一下常用的安全防護措施，而作為系統對外提供數據來源的 API 接口，也就是系統的核心后臺服務，可以說，關于 API 的安全考慮，可以說很多開發者在設計過程中尚未引起足夠的重視。這里小編說一個有意思的現象，在小編過往的工作經歷中，那些甲方公司最終對項目進行驗收時，通常需要對整個源碼進行安全審計，其中審計最容易出問題的地方，就是很多 API 接口的安全問題，比如 XSS 攻擊，CSRF 攻擊，接口有被刷的風險...

接下來，針對上述談到的問題，以及日常開發中對于 API 安全的一些規范性要求，一起探討下在 API 安全設計的一些處理措施。

4.1 控制 API 的訪問邊界

以當下流行的微服務來說，后臺提供出去的 API 一定要規范訪問邊界，哪些接口可以暴露出去，哪些接口一定要通過鑒權才能訪問，關于這一點，依照經驗來說，做好下面幾點即可：

• 接口設計之初，與前端同學約定好接口的使用場景；
• 對外暴露且不需要鑒權的接口做好流控，避免被刷，比如有些登錄接口中需要用到短信驗證碼的場景；
• 對外暴露且不需要鑒權的接口做好嚴格的參數校驗，避免 XSS 字符的入庫存儲；
• 需要走鑒權的接口，最好走統一的安全校驗邏輯，比如 SDK 或者內部封裝的組件；

4.2 嚴格規范 API 的使用類型

對于某些比較大的平臺來說，比如 pass 平臺，通常都是十幾個甚至幾十上百個內部服務組成的，如此龐大的系統統一對外提供服務時，各應用服務之間必然存在著互相的調用，這些可以是 dubbo 調用，或者 http 的調用，通常不同的應用之間調用時，走 rest 接口非常多，同時，不同應用之間互相調用時，場景也是多樣，有些需要認證，有些不需要，有些需要嚴格的認證，有些需要寬容的認證，這該怎么辦呢？

針對上面的場景，這里可以考慮定義不同的 API 使用類型，針對不同類型的 API，在調用的時候策略也不一樣，具體實踐來說，可以參照如下設計原則；

系統外部可調用的 API

這種 API，即內部應用和外部應用都可以調用的 API，這類 API 的設計，通常需要通過一個統一的憑證頒發入口，調用者拿到這個憑證，在調用 API 時傳過去，認證通過后，API 給與數據響應，由于憑證是系統內部的服務頒發，可以認為是安全的，同時，如果更進一步的話，可以對憑證做有效期的設定，甚至是加密處理等措施。

系統內部可調用的 API

即平臺各個微服務應用之間調用的 API，由于內部的應用在使用之前，都需要一定的注冊或者其他的認證措施，對于內部的 API 調用來說，可以在 API 接口中添加關鍵參數信息識別即可，比如，在請求內部 API 的時候添加一個 appName 這樣的標識，一旦 API 校驗這個 appName 合法有效，就可以給與響應。

無需認證的 API

比如請求系統的首頁，或者上面談到的請求短信驗證碼，再就是某些需要對接平臺的外部第三方應用，這些第三方應用需要拿到一些非敏感的數據作為業務標識等，這種情況下，針對這樣的 API，在設計時，要做好關鍵參數的校驗，接口防刷的處理，以及可信 IP 的識別。

4.3 API 敏感參數加密處理

類似于登錄，獲取用戶信息的 API 接口，一定要做加密處理，防止因會話劫持造成數據傳輸過程中敏感信息的泄露，關于加密，常用的加密方式包括：

• 密碼的 MD5 加密，甚至可以混合鹽值提高加密的安全等級；
• 對稱或非對稱加密（根據業務需要選擇）；
• JWT，也是當下流行的一種輕量化的加解密方案；

4.4 API 請求 header 中混合特殊參數

一種常見的場景就是，前端請求 API 接口時，需要在請求的 header 中添加后臺辦法的 token 或者其他的令牌等參數，而請求到達 API 之前（有的在 API 中做），解析并統一校驗 API 請求中的 header 是否攜帶了這個參數，且有效的情況下才予以返回。如果你的 API 安全等級更高，可以考慮在請求 header 中混合其他的定制化參數，這也是一種有效的保護 API 的手段。

4.5 API 自身的防刷措施

對于一個成熟穩定的系統來說，盡管請求在真正到達 API 時有各種防護措施，比如限流，惡意請求 IP 識別等統一的措施，但是作為打通數據后臺到前臺的最后一關，針對系統中的某些核心業務的 API，還是有必要做針對性的接口防刷機制，具體來說，可參考下面的思路進行實施；

• 根據來源 IP，核心業務字段的組合進行惡意請求的識別，限制這類請求頻次，減少對服務端的壓力；
• API 采用限流組件，或者引入開源限流 SDK，或者自己編寫限流算法工具包，對熱點 API 進行限流；
• 日志追蹤，針對那些惡意刷接口的 IP，記錄在日志，并接入告警平臺，定向的上報監控告警；

4.6 盡量對請求參數進行封裝

一般來說，從 rest 請求安全的角度來說，post 請求的安全性要好于 get 請求，這是因為大多數情況下，get 請求暴露在請求 url 中，而 post 請求的參數相對來說會隱蔽一些。這里給出的建議是，當查詢請求參數超過 5 個時，可以對請求參數進行封裝，然后將親請求類型調整為 post。

4.7 API 參數校驗

為什么這一點放在最后來說，小編認為這是大多數開發者能夠想到但在實際工作中又不能做得很好的一點。參數校驗可以說是 API 層面最后一道基礎但是重要的安全保障了，但是在參數校驗這個度的把握上，很多開發人員顯得有些不知所措，這里小編提出下面幾點建議以供參考：

區分 API 的重要程度

并不是所有的 API 都需要一大堆的參數校驗，為什么這么說呢？要知道，參數對于一個系統安全的影響隨著鏈路的傳遞是逐漸增加的，假如說一段xss的字符作為參數傳入到 API 接口中，假如不做處理最終會入庫，后面再查詢出來渲染到頁面時候，這個危害性就大了，影響的不僅是用戶的體驗，甚至會失去一個潛在的有價值的用戶。

說到這里，相信大家能夠了解，假如在 save 數據的接口中就能夠識別非法參數，從而進行攔截的話，后續所有的麻煩都可以提前避免掉。從這個角度來說，一個通用的做法就是，針對那些需要保存表單的數據，或者是涉及到修改，刪除之類的 API，一定要做好參數的校驗和控制。

不要過度對參數進行校驗

看到過不少開發者在一個存儲數據的接口中對參數進行了相當篇幅的代碼校驗，并不是說這樣不好，而是需要區分一個度的問題，舉例來說，有人在編寫一個保存用戶的 API 接口時，對用戶名稱做校驗時，大概有幾十行代碼，涉及的規則如下：

• 校驗賬戶中是否有特殊字符，比如 $% 這樣的字符；
• 校驗賬戶名稱長度是否超過限制；
• 校驗系統中是否有重復的賬戶名；
• 校驗賬戶名中是否有違禁的詞；
• 校驗賬戶名中是否有多音字；
• ...

我就想不通了，一個賬戶名的校驗需要搞那么多花樣嗎，開個玩笑，這當然不是我的過激行為，我要表達的意思是，API 設計時，在考慮安全性的同時盡可能兼顧使用者的習慣，簡化因參數校驗帶來的交互流程上的麻煩。

五、寫在文末

安全無小事，這句話應該來說對所有的行業都適用。希望從事開發的伙伴們在日常開發中對系統安全多一份敬畏，從而少一些因安全事故帶來的不必要的麻煩。當然，系統的安全性建設是一項長期的工作，需要自頂而下，做好長遠的規劃，并逐步落實并貫穿到日常的每一個開發、測試、運維以及實施過程中，這樣這才是長久之計，與君共勉。