深度解析：臨床試驗數據庫CT.gov與API接口指南
API安全防護示意-圖1
Web API 簡單來講就是通過網絡（特別是互聯網）來提供的應用程序編程接口。
比如說，您打開一個購物網站，網站上展示商品信息、價格、銷量等數據，這些數據不是網站自己憑空生成的，而是通過調用后端的 Web API 從數據庫中獲取的。又比如您用手機上的地圖應用查找附近的餐廳，這個應用也是向服務器發送請求，通過服務器提供的 Web API 獲取相關餐廳的位置、評價等信息。
Web API 讓不同的網頁應用或者移動應用能夠與服務器進行交互，獲取或提交數據，實現各種各樣的功能，就像給這些應用提供了一個獲取所需信息和完成特定任務的“快捷通道”。
WebAPI工作示意-圖2
比如說，一個為移動應用提供位置信息的 Web API ，任何支持網絡請求的移動開發語言都能輕松調用獲取數據；而傳統的某個操作系統內部用于系統組件通信的 API ，則只能在該操作系統特定的開發環境中使用。
總的來說，Web API 更適應現代互聯網環境下的分布式應用和跨平臺需求，而傳統 API 則在特定的軟件系統內部發揮重要作用。
Web API與傳統的API區別示意-圖3
目前常見的 Web API 四種主要類型（基于 HTTP 的 API）如下：
WebAPI類型-圖4
企業對消費者（B2C）的 API 呢，就是支持網頁應用程序和手機應用程序的一種接口。這些接口常常被現在的前端客戶端用到，能讓最終用戶用上公司開放的業務功能。
企業對企業（B2B）的 API 是公司合作伙伴（其他公司）用的，有時給合作伙伴服務（這些公司就是最終客戶），有時給共同客戶創造價值（就是 B2B2C）。
B2B 的 API 是企業數字化轉型的基礎，因為能讓企業和供應商、經銷商還有其他伙伴合作更簡單，給企業客戶體驗也更好。
比如說開放銀行 API 、供應鏈管理 API 、貿易伙伴之間電子開票和付款，這些都是 B2B API 。
因為用 B2C API 的是面對用戶的應用程序，用 B2B API 的是合作伙伴的業務應用程序，使用者差別大，所以保護它們的安全控制工具也不一樣。
在安全上，行業關注點到最近還主要在 B2C 應用場景，但就算在這場景里，重點也不是保護 B2C 的 API ，而是保護網頁應用程序。保護 B2C 網頁應用程序的安全控制工具，很難用來保護 B2C 的 API （像 WAF/WAAP ），有的甚至根本用不了（像大部分防爬蟲程序的解決辦法）。
保護 B2B 的 API 已經變成個越來越重要的問題。對 B2B API 來說，第一代供應商沒有專門針對共享用戶批量數據訪問的安全監測和保障方案（像開放銀行業務里，金融科技公司和金融機構同意共享客戶數據，就是這種情況）。
很多時候，人們說“API”，其實說的是單個的 API 端點。API 有時候也被叫做服務或者 API 產品，它實際上是一堆端點湊在一起，為業務功能服務。
那什么是端點呢？端點就是資源（或者說是資源的路徑，也有人叫它 URI 或者統一資源標識符），還有對這個資源能做的操作，比如創建、讀取、更新或者刪除。
在 RESTful API 里，這些操作一般跟 HTTP 方法是對應的，像創建對應 POST，讀取對應 GET，更新對應 PUT，刪除對應 DELETE。
這些 API 是企業對外面（主要是合作伙伴）開放的。比如說，搞開放銀行業務的銀行可能通過 API ，讓別的金融科技企業或者金融服務企業能使用它的賬戶。醫療保健企業可能通過 API 把患者記錄給保險公司和其他醫療企業用。酒店企業可能通過 API 把預訂系統開放給旅行社或者旅游信息采集平臺。API 就是企業之間的連接橋梁。
南北向的 API 通常被認為是安全的，因為使用 API 已經得到了允許并且通過了身份驗證。但這些 API 往往增長得特別快，數量又特別多，所以對于大多數企業來講，這是一個很大的容易受到攻擊的地方。
企業內部使用的 API，它們將內部應用程序或者業務單位（部門）連接起來。只要無法從企業外部訪問，就是東西向 API。
API環境示意-圖5
私有 API 也叫內部 API ，是公司內部開發人員和承包商用的。它通常是面向服務架構計劃的一部分，能方便不同部門或業務單位獲取彼此數據，讓內部開發更輕松。
公共 API 又叫外部 API ，對公司外的人開放，極端情況下誰都能用，但需要嚴格管理和完整文檔供外部工程師使用。得注意，能通過互聯網訪問的私有 API 不是真的私有 API 。
API 漏洞是一種軟件錯誤或系統配置錯誤，可能導致攻擊者利用這類錯誤來訪問敏感應用程序功能或數據，或者造成 API 濫用。
就好比 API 是房子的門，漏洞就是門沒關好或者壞了。比如可能沒好好檢查用戶能不能進來，不該進的人能隨便進還能拿數據；或者傳輸數據時沒加密，被人截取就能看到；也可能 API 本身代碼有錯，處理不了特殊請求，導致系統出問題或者結果不對。反正 API 漏洞會讓壞人有辦法非法拿到信息、搞壞系統或者影響正常服務。
OWASP TOP 10 API 安全風險清單十分實用，其中概括了一些被廣泛濫用的 API 漏洞，企業應該盡力識別和修復這些漏洞。這一塊太龐大了，就不說了，細看可前往。
OWASP TOP 10 API 安全風險
https://owasp.org/www-project-api-security/
Q10 API濫用的方式有？
API濫用示意-圖6
API 安全防護解決方案包括：
總的來說，這些解決方案對保證 API 的安全和完整特別重要。因為 API 對企業越來越不能少了，所以企業得花錢弄可靠的方案來保護敏感數據和知識產權。
舉個栗子，有一家大型電商企業用了這些安全防護辦法，用多重身份驗證保證用戶登錄 API 是安全的；靠 API 網關去管理流量和驗證身份；給數據加密傳輸；設置速率限制，不讓人亂發請求；做好審計和日志記錄，方便追查問題；做 API 測試，及時找出漏洞；通過監控和運行時保護隨時看著 API 的狀態；做好漏洞管理，保證 API 沒有已知的安全問題，這樣就保證了企業的 API 安全，也保護了用戶數據和企業的知識產權。
僵尸 API 指的是那些雖然已經部署了，但很少或者幾乎不再被使用的 API 。就好像是一個被遺忘在角落里、無人問津的工具。
影子 API 則是那些在企業的正式記錄和監管之外被開發和使用的 API 。比如說，某個開發團隊為了快速解決問題，自己私下弄了個 API 來用，但公司并不知道，也沒有對其進行管理和監控。簡單來說，僵尸 API 是被冷落的，而影子 API 是偷偷存在的。
至于這塊怎么去發現并處理僵尸、影子API，這一塊有專業的公司，會提供專業的工具發現并處理，僵尸這塊更多得跟開發團隊去溝通，工具很難梳理出來。
API 攻擊就是對應用程序編程接口（API）干的壞事，想破壞 API 正常運行、拿到沒授權的數據或者干非法的事。比如說，攻擊者可能狂發惡意請求，讓 API 服務器累趴下，正常用戶就用不了；或者找 API 的安全漏洞，繞過授權拿到敏感信息。
API 撞庫是這樣的，攻擊者有好多用戶名和密碼的組合，就在某個 API 上一個個試能不能登錄。要是登錄成功，就能拿到用戶信息或者干別的壞事。
總之，API 攻擊是各種搞壞 API 的惡意行為，API 撞庫是拿大量賬號密碼嘗試登錄 API 來謀私利。
基于簽名的 API 安全防護，簡單來說，就是通過對 API 通信中的特定特征或標識進行識別和驗證，來保障 API 安全的一種方式。 就好像每個人都有獨特的簽名來證明自己的身份一樣，API 也有它獨特的“簽名”。這個“簽名”可能包含了一些關鍵的信息，比如請求的來源、請求的內容特征、特定的加密標識等等。 當有請求訪問 API 時，系統會檢查這個請求攜帶的“簽名”是否符合預先設定的規則和標準。如果符合，就認為是安全的請求，允許通過；如果不符合，就可能被判定為不安全的請求，從而被拒絕或者觸發相應的安全警報。舉個栗子，一家電商公司的 API 系統設置了基于簽名的安全防護，規定只有來自特定合作伙伴網站的請求，并且請求中包含特定的加密標識，才被認為是合法的。這樣，就能有效地防止來自其他不明來源或者惡意的請求訪問 API ，保護公司的數據和業務安全。
API 檢測和響應簡單來講，就是對 API 的運行狀況和相關活動進行密切監視，并在發現異常或潛在威脅時迅速采取應對措施的過程。
比如說，檢測就像是時刻盯著 API 這個“大門”，看誰在進出、進出的頻率如何、進出時攜帶的“東西”是否合規。而響應呢，則是當檢測到不對勁的情況時，比如有大量異常的訪問請求、數據傳輸出現異常等，馬上采取行動，可能是阻止這些異常訪問、發出警報通知相關人員，或者啟動應急處理程序來修復問題、保護數據。
打個比方，API 檢測和響應就像一個保安系統，檢測是負責觀察和發現問題的“眼睛”，響應則是負責處理問題的“手腳”。
例如，一家金融公司通過 API 檢測和響應系統，發現某個時間段內 API 收到了大量來自陌生 IP 地址的請求，系統立即響應，阻止這些請求并啟動調查，以防止可能的金融數據泄露。
API使用意圖示意-圖7
API使用模式示意-圖8
HTTP API：這類 API 使用超文本傳輸協議作為 API調用的通信協議。
RESTfuI API：表現層狀態轉換(RESTful) 可追溯到 Roy Fielding 2000 年的博士論文，是最常見的Web API 類型，通常使用 JSON(JavaScript對象表示法)來存儲數據。RESTfuIAPI易于供現代前端框架(例如 React 和 React Native)使用，并可促進 Web 應用程序和移動應用程序的開發。這類 API已成為各種 Web API(包括 B2BAPI)的實質性標準。
GraphQL：GraphQL API是 Facebook開發的新標準，通過單個 POST端點(通常為 /graphql)提供數據庫訪問功能。GraphQL API解決了RESTfuI API的一個常見問題(需要多次調用才能填充單個 U 頁面)，但引入了其他附加問題。
SOAP：SOAP 使用詳細的可擴展標記語言(XML) 進行遠程過程調用(RPC)。在舊版 API 中仍然可以找到它。
XML-RPC：XML-RPC 是通過互聯網進行過程調用的一種方法，使用XML進行編碼并用 HTTP 作為通信協議。
gRPC：gRPC API是 Google 新開發的 HTTP/2.0 高性能二進制協議，主要用于東西向通信。
OpenAPI：OpenAPI是 API的一種描述和文檔規范。在舊版本中，0penAPI被稱為 Swagger，這兩個術語現在仍然經常互換使用(就像 SSL與TLS)。
文章轉自微信公眾號@明格科技沙龍
