元伸科技
你家大門有幾道鎖？API 也需要同等防護
想像你住在一棟透天厝，你會只裝一把門鎖就安心嗎？多數人至少會有大門鐵捲門、玄關門鎖、室內反鎖，甚至加裝監視器和保全系統。每一道防護都不是多餘的——它們層層堆疊，讓小偷即使突破一關，也很難長驅直入。
網站的 API（Application Programming Interface） 就像你家的大門。它是外部系統存取資料的唯一入口，也是駭客最常鎖定的攻擊目標。根據 OWASP 公布的 API Security Top 10，超過 60% 的資料外洩事件與 API 漏洞直接相關。無論你的網站是串接金流、會員系統還是第三方服務，API 安全都不容忽視。
本文將帶你認識 API 面臨的常見威脅，並逐一拆解 7 道關鍵防線，幫助你的企業建立穩固的 API 安全架構。如果你還不熟悉 API 的基本概念，建議先閱讀 API 串接與系統整合指南。
API 為什麼會成為攻擊目標？
傳統網站的互動主要透過瀏覽器頁面，攻擊面相對有限。但現代網站大量依賴 API 來傳輸資料——會員登入、訂單查詢、庫存同步、金流通知，全部都透過 API 完成。這代表：
- API 直接暴露商業邏輯：攻擊者可以繞過前端介面，直接對 API 發送惡意請求
- API 回傳的是原始資料：不像網頁有畫面遮蔽，API 回傳的 JSON 資料一覽無遺
- API 端點數量龐大：一個中型網站可能有數十個 API 端點，每個都是潛在的攻擊入口
- 自動化攻擊成本極低：撰寫腳本批量呼叫 API 比手動操作網頁容易得多
第一道防線：身份驗證（Authentication）
身份驗證是確認「你是誰」的機制，也是 API 安全最基礎的一環。
API Key 驗證
最簡單的方式是為每個使用者或應用程式核發一組 API Key。每次請求都必須在 Header 中帶上這組金鑰，伺服器驗證通過才會回應。要注意的是，API Key 絕對不能出現在前端程式碼或 URL 參數中，否則等於把鑰匙放在門口地墊下。
OAuth 2.0 與 JWT
對於需要更精細權限控制的場景，建議採用 OAuth 2.0 搭配 JWT（JSON Web Token）。OAuth 2.0 透過授權流程核發有時效的 Access Token，JWT 則將使用者資訊和權限編碼在 Token 中，伺服器無需每次查詢資料庫即可驗證身份。
最佳做法
- Token 設定合理的過期時間（例如 Access Token 15 分鐘、Refresh Token 7 天）
- 實作 Token 撤銷機制，當使用者登出或帳號異常時立即失效
- 絕對不要在 API 回應中回傳完整的 Token 或密碼
第二道防線：授權控制（Authorization）
驗證了「你是誰」之後，還要確認「你能做什麼」。這就是授權控制的角色。
OWASP API Security Top 10 中，Broken Object Level Authorization（BOLA） 長年佔據第一名。典型案例是：使用者 A 只需修改 API URL 中的 ID 參數，就能存取使用者 B 的訂單資料。
防護措施
- 每個 API 端點都必須檢查當前使用者是否有權存取該筆特定資料
- 採用 RBAC（角色型存取控制） 或 ABAC（屬性型存取控制） 模型
- 避免使用可預測的流水號作為資源 ID，改用 UUID 降低被猜測的風險
- 管理員 API 和一般使用者 API 應明確分離
第三道防線：速率限制（Rate Limiting）
速率限制就像大樓管理員——不管你有沒有門禁卡，短時間內頻繁進出就會被攔下來。
沒有速率限制的 API 極度脆弱：
- 暴力破解：攻擊者每秒嘗試數千組密碼
- DDoS 攻擊：大量請求癱瘓 API 伺服器
- 資料爬取：自動化腳本批量擷取你的商品資料或客戶名單
實作建議
- 依據端點敏感度設定不同的限制（登入 API 每分鐘 5 次，查詢 API 每分鐘 60 次）
- 回傳標準的 429 Too Many Requests 狀態碼，並在 Header 中告知剩餘額度
- 對已驗證使用者和未驗證請求設定不同的閾值
- 搭配 IP 黑名單與地理位置封鎖強化防護
想了解更多基礎資安觀念，可參考網站資安防護基礎。
第四道防線：輸入驗證與資料過濾
永遠不要信任來自外部的任何資料——這是資安領域的黃金法則。
API 接收的每一筆資料，無論來自自家前端、第三方系統還是行動裝置，都必須經過嚴格的驗證和過濾。常見的輸入攻擊包括：
- SQL Injection：在 API 參數中注入 SQL 語法，竊取或刪除資料庫內容
- NoSQL Injection：針對 MongoDB 等 NoSQL 資料庫的注入攻擊
- XSS（Cross-Site Scripting）：在 API 輸入中嵌入惡意 JavaScript 腳本
防護措施
- 對所有輸入欄位定義明確的資料型別和長度限制（例如：email 必須符合 email 格式、手機號碼只接受數字）
- 使用白名單驗證而非黑名單——只允許已知安全的格式通過
- 對 API 回傳的資料進行輸出編碼，防止儲存型 XSS
- 使用參數化查詢或 ORM，徹底杜絕 SQL Injection
更深入的 XSS 與 CSRF 防護策略，請參考網站 XSS 與 CSRF 防護。
第五道防線：傳輸加密（Transport Security）
資料在網路上傳輸時，如果沒有加密，就像寄明信片——沿途任何人都能看到內容。
強制 HTTPS
所有 API 通訊必須使用 HTTPS（TLS 1.2 以上）。這不只是建議，而是基本要求。HTTP 明文傳輸的 API 等於把使用者的帳號密碼和 Token 直接公開在網路上。
進階措施
- 啟用 HSTS（HTTP Strict Transport Security），強制瀏覽器永遠使用 HTTPS
- 對特別敏感的資料（如信用卡號、身分證字號），在 API 層額外實施欄位級加密
- 使用 Certificate Pinning 防止中間人攻擊（特別是行動裝置 App 呼叫 API 時）
關於 SSL/TLS 的完整配置指南，可參考 SSL/TLS 進階指南。
第六道防線：錯誤處理與資訊隱藏
API 的錯誤訊息如果太「貼心」，反而會成為駭客的情報來源。
不安全的錯誤回應
{
"error": "User admin@company.com not found in table users",
"stack": "at UserController.findUser (line 42)..."
}
這種回應直接告訴攻擊者：資料庫有 users 表、使用 email 作為帳號、後端框架的檔案結構。
安全的錯誤回應
{
"error": "認證失敗",
"code": "AUTH_001"
}
最佳做法
- 對外只回傳通用的錯誤訊息和錯誤代碼
- 詳細的錯誤資訊寫入內部日誌，而非回傳給使用者
- 登入失敗時不要透露「帳號不存在」或「密碼錯誤」——統一回覆「帳號或密碼錯誤」
- 確保生產環境關閉 Debug 模式
第七道防線：日誌監控與異常偵測
前六道防線是「防」，第七道防線是「知」——你必須知道有人正在嘗試突破你的防線。
應記錄的 API 事件
- 所有認證失敗的請求（帳號、IP、時間）
- 異常的存取模式（同一 IP 短時間大量請求不同使用者的資料）
- 權限提升嘗試（一般使用者試圖存取管理員 API）
- API 回傳 4xx/5xx 錯誤的頻率與分佈
自動化告警
光記錄不夠，還需要即時告警：
- 同一 IP 在 5 分鐘內認證失敗超過 10 次 → 自動封鎖並通知管理員
- 單一 Token 在 1 小時內存取超過 1,000 個不同的資源 ID → 觸發異常警報
- API 錯誤率突然飆升至 10% 以上 → 可能正在遭受攻擊
搭配完善的網站錯誤監控系統，能讓你在攻擊初期就發現異常，大幅降低損害。
API 安全檢核清單
在部署任何 API 之前，請確認以下項目：
- 所有 API 端點都要求有效的身份驗證
- 每個端點都有物件級別的授權檢查
- 已設定合理的速率限制
- 所有輸入都經過驗證與過濾
- 通訊全程使用 HTTPS/TLS 1.2+
- 錯誤回應不包含內部實作細節
- API 存取日誌完整記錄且設有告警規則
- API 文件不公開暴露在生產環境
- 已停用的 API 版本已完全下架
結語：API 安全是持續的過程
API 安全不是一次性的任務，而是需要持續維護和演進的過程。新的攻擊手法不斷出現，你的防護也必須跟上。
最重要的觀念是縱深防禦（Defense in Depth）——不依賴單一防護機制，而是建立多層防線。即使某一層被突破，還有其他防線能夠阻擋攻擊。就像開頭的透天厝比喻：鐵捲門、門鎖、反鎖、監視器、保全，每一道都讓入侵者的成本更高。
如果你的企業網站正在規劃 API 串接或客製化系統開發，從一開始就將安全設計納入架構中，遠比事後補強來得有效且經濟。想了解 客製化網頁設計 與 API 安全整合方案，歡迎聯絡元伸科技，讓我們協助你打造安全可靠的 API 服務架構。
