元伸科技
你家大門有幾道鎖？API 也需要同等防護
老實說，跟桃園很多老闆聊資安時，大家都同意一件事：自己家住透天厝，鐵捲門、玄關門鎖、室內反鎖、監視器、保全 — 一道都不會少。但同樣這位老闆的網站 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 從 1001 改成 1002，就看到了使用者 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 以上）。除非你的 API 純粹是內網測試環境，否則這沒有商量空間。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 串接或客製化系統開發，從架構設計階段就把安全放進去，遠比上線後再補強更省成本，也更不容易留破口。
元伸科技 24 年深耕、服務 3,000+ 企業客戶，從 客製化網頁設計 到 API 串接安全整合都有完整實作經驗。如果你對自家系統的 API 安全狀況沒把握，歡迎來聊聊現況，我們可以幫你看一下風險點在哪。
📞 03-366-1000 ｜ 🌐 www.ozchamp.com ｜ 免費諮詢 24hr 回覆
