English | 简中版 | العربية | Azərbaycan | Български | বাংলা | Català | Čeština | Deutsch | Ελληνικά | Español | فارسی | Français | हिंदी | Indonesia | Italiano | 日本語 | 한국어 | ພາສາລາວ | Македонски | മലയാളം | Монгол | Nederlands | Polski | Português (Brasil) | Русский | ไทย | Türkçe | Українська | Tiếng Việt

開發安全的 API 所需要核對的清單

以下是當你在設計, 測試以及發佈你的 API 的時候所需要核對的重要安全措施.

---

身份認證

• 不要使用 Basic Auth, 使用標準的認證協議取而代之。
• 不要再造 Authentication, token generating, password storing 這些輪子, 使用標準的。
• 在登錄中使用 Max Retry 和自動封禁功能。
• 加密所有的敏感數據。

訪問

• 限制流量來防止 DDoS 攻擊和暴力攻擊。
• 在服務端使用 HTTPS 協議來防止 MITM 攻擊。
• 使用 HSTS 協議防止 SSLStrip 攻擊。
• 關閉目錄列表。
• 對於私有 API，僅允許從列入白名單的 IP/主機進行訪問。

Authorization

OAuth 授權或認證協議

• 始終在後台驗證 redirect_uri, 只允許白名單的 URL.
• 每次交換令牌的時候不要加 token (不允許 response_type=token).
• 使用 state 參數並填充隨機的哈希數來防止跨站請求偽造(CSRF).
• 對不同的應用分別定義默認的作用域和各自有效的作用域參數.

輸入

• 使用與操作相符的 HTTP 操作函數, GET (讀取), POST (創建), PUT (替換/更新) 以及 DELETE (刪除記錄), 如果請求的方法不適用於請求的資源則返回 405 Method Not Allowed.
• 在請求頭中的 content-type 欄位使用內容驗證來只允許支持的格式 (如 application/xml, application/json 等等) 並在不滿足條件的時候返回 406 Not Acceptable.
• 驗證 content-type 的發佈數據和你收到的一樣 (如 application/x-www-form-urlencoded, multipart/form-data, 等等).

處理

• 檢查是否所有的終端都在身份認證之後, 以避免被破壞了的認證體系.
• 避免使用特有的資源 id. 使用 /me/orders 替代 /user/654321/orders
• 使用 UUID 代替自增長的 id.
• 如果需要解析 XML 文件, 確保實體解析(entity parsing)是關閉的以避免 XXE 攻擊.
• 如果需要解析 XML 文件, 確保實體擴展(entity expansion)是關閉的以避免通過指數實體擴展攻擊實現的 Billion Laughs/XML bomb.
• 在文件上傳中使用 CDN.
• 如果需要處理大量的數據, 使用 Workers 和 Queues 來快速響應, 從而避免 HTTP 阻塞.
• 不要忘了把 DEBUG 模式關掉.
• 可用時使用不可執行的堆棧。

輸出

• 發送 X-Content-Type-Options: nosniff 頭.
• 發送 X-Frame-Options: deny 頭.
• 發送 Content-Security-Policy: default-src 'none' 頭.
• 刪除指紋頭 - X-Powered-By, Server, X-AspNet-Version 等等.
• 在響應中強制使用 content-type, 如果你的類型是 application/json 那麼你的 content-type 就是 application/json.
• Do not return overly specific error messages to the client that could reveal implementation details, use generic messages instead, and log detailed information only on the server side.

持續整合和持續部署

• 使用單元測試和整合測試來審計你的設計和實現.
• 引入代碼審查流程, 不要自行批准更改.
• 在推送到生產環境之前確保服務的所有組件都用殺毒軟件靜態地掃瞄過, 包括第三方庫和其它依賴.
• 對您的代碼持續運行安全測試（靜態/動態分析）。
• 檢查您的依賴項（軟件和操作系統）是否存在已知漏洞。
• 為部署設計一個回滾方案.

監控

• Use centralized logins for all services and components.
• Use agents to monitor all traffic, errors, requests, and responses.
• Use alerts for SMS, Slack, Email, Telegram, Kibana, Cloudwatch, etc.
• Ensure that you aren't logging any sensitive data like credit cards, passwords, PINs, etc.
• Use an IDS and/or IPS system to monitor your API requests and instances.

---

也可以看看：

• yosriady/api-development-tools - 用於構建RESTful HTTP+JSON API的有用資源集合。
• You don't need JWT, just use a randomly generated API key. If you need asymmetric encryption or tamper prevention, here are some alternatives to JWT.

---

API Security Best Practices (Advanced)

Rate Limiting & Abuse Prevention

• Implement sliding window rate limiting per API key and IP.
• Use exponential backoff for repeated failed authentication attempts.
• Implement CAPTCHA or proof-of-work challenges after suspicious activity.
• Monitor and alert on unusual API usage patterns (time, volume, endpoints).

GraphQL-Specific Security

• Disable introspection in production environments.
• Implement query depth limiting to prevent nested query attacks.
• Use query cost analysis to prevent resource exhaustion.
• Whitelist allowed queries in production when possible.

Secrets Management

• Rotate API keys and secrets on a regular schedule.
• Use hardware security modules (HSM) for signing operations.
• Implement secret scanning in CI/CD pipelines.
• Never commit secrets to version control - use environment variables or secret managers.

Zero Trust Architecture

• Implement mutual TLS (mTLS) for service-to-service communication.
• Validate all requests even from internal services.
• Use short-lived tokens with automatic refresh.
• Implement request signing for sensitive operations.

---

貢獻

為此存儲庫創建一個 fork, 進行修改, 並提交 pull request 來貢獻. 如果您有任何問題, 請發送郵件至 [email protected].