無論是在科技導向的媒體或分析報告中，越來越常看到 API 和「資安」擺在一起，或是 API 與「外洩」負面的詞彙一同出現在標題中。
APIs (Application Programming Interfaces) 不僅能作為應用程式、系統和數據之間的連結，亦是幫助開發人員將數位資產用於新用途的機制。APIs 幾乎包含了所有數位使用案例，在資訊安全的新聞中，APIs 被這樣分類錯誤並非是因為它與生俱來的缺陷，只是因為某些 APIs 遭受入侵，導致 vault 被錯誤分類。但上述提到的媒體標題仍透露了一個重要的訊息：假如 API 的安全性沒有被企業列為優先重要事項，那優先事項清單就不完整。
事實上，現今對 API 安全性的要求已成為共識：
- 2017 年 12 月 Gartner 分析師 Mark O’Neill、 Dionisio Zumerle 和 Jeremy D’Hoinne 提出的預測報告 –「如何建置有效的 API 安全策略」，「[b] 到 2022 年，API 濫用將會是最常見的攻擊媒介，而這將會導致企業Web 應用程式的數據外洩 」。
- OWASP 是一份備受重視的網站安全威脅列表， 而在 OWASP Top 10 中，就包含了數十種 API 的引用。在這些明確警告中包含「在沒有保護的情況下傳輸敏感數據」、「沒有監控 API 流量中可疑的行為」、「使用易受攻擊元件的 API」。
- 醫療組織 HIMMS 在 2018 年發佈了一份報告，詳細說明了不安全的 API 會對敏感的醫療數據造成威脅。
調查指出企業已經特別關注對 APIs 的殭屍網路與 DDoS 攻擊。儘管企業已經特別關注這些情況，但當企業對所使用的 API 缺乏透徹的理解時，這些攻擊漏洞對於惡意攻擊者來說，還是相當可觀。 許多組織仍不知道自己已經部署了多少 API，或多少人正在使用這些 API，亦或是這些 API 的流量是否在持續增加。
越來越多與 API 相關的資料外洩和安全事件顯示了 API 安全性的重要，舉例而言一個政府機構的安全漏洞可以使任何登入的使用者不當地查詢系統、獲取其他用戶的個人訊息，包含電子郵件地址、電話號碼、住址等，嚴重時更暴露了部分用戶敏感的數據。設計不良、管理不善的 API 所帶來的危害和漏洞各不相同，最重要的是，如果持續依賴這樣的 API，企業或政府機構將持續暴露在資安威脅中。企業該如何應付這個日趨嚴重的威脅呢？Google Cloud Apigee 推薦以下四大訣竅：
(一) 以 TLS (Transport Layer Security) 為基礎
- 傳輸層安全性協定 (TLS) 會將流量加密，以確保用戶與正確的伺服器通訊，是 API 的安全性基礎。所有 API 都應該以 TLS 為基礎。
- 隨時更新 TLS：因為它們會頻繁變動。許多 API 團隊會利用像是 Qualisys SSL Labs 的 SSL Server Test 服務測試 TLS 的配置。
- 利用追蹤工具、資料遮罩和標記化 (tokenization) 等技術。
(二) 專注於身份驗證
- 控制 API 存取權限是有效確保 API 安全的基礎，企業應該使用 OAuth 對使用者進行身份驗證。
- 使用者與應用程式都需要被驗證身份。
(三) 在部分服務上使用速率限制來防止暴力攻擊，並且管理流量
- 使用速率限制防止暴力攻擊，舉例來說：一個駭客可能會利用自動化軟體猜測密碼，造成大量連續登入嘗試。此時 API 若不受速率限制，則會無限制地允許此攻擊，直到攻擊成功為止。
(四) 使用行為模式 (Behavioral Patterns) 和機器學習阻檔意圖不良的機器人
- 不僅監控 API 的存取模式，也要監控流量的狀況，才能發現可疑的行為。
- 利用複雜的演算法和機器學習來發現意圖不良的機器人，同時留意：有些適用於阻止網路或 Web 攻擊的方法可能不適用於 API。
只要企業使用資訊技術，就會有惡意攻擊者試圖找到這些 IT 漏洞，這樣的挑戰不計其數，但在前往成功的過程中這是不可避免的，當企業數位化越成功，就更有可能吸引更多的攻擊者。
以上四大訣竅只是保護 API 安全的開端，企業不僅需要保持積極，更應在「設計對開發人員有善的 API 」與「保護 API 免於受到攻擊」之間取得平衡。除了技術方面的考量外，安全性還需涉及其他層面：企業應針對其開發的 API 制定服務條款，將 API 的更新資訊傳達給其他開發者，同時回應資料外洩等資安問題。
儘管在保護 API 安全的路上沒有鬆懈的可能，但可以看到的是，企業並沒有被惡意攻擊者束縛，成熟度也越來越高。專注於 API 安全性的企業將會盡其所能確保：當這些 API 安全議題再次出現在媒體標題時，是因為其它公司資料外洩所造成的。
(原文翻譯自 Google Cloud Apigee。)
