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認証を利用せず、標準的な認証を利用する。
• 認証、トークンの生成、パスワードの保管において「車輪の再発明」をしないこと。すでに標準化されているものを利用する。
• ログインにおいては最大リトライ回数（Max Retry）とjail機能を利用する。
• 全ての機微情報において暗号化を活用する。

アクセス

• DDoSやブルートフォース攻撃を回避するため、リクエストを制限（スロットリング）する。
• MITM（Man in the Middle Attack）を防ぐため、サーバサイドではHTTPSを使用する。
• SSL Strip attackを防ぐため、SSL化とともにHSTSヘッダを設定する。
• ディレクトリ・リストをオフにする。
• プライベートAPIの場合、ホワイト・リストに登録されたIP/ホストからのアクセスのみを許可する。

認可

OAuth

• サーバサイドで常にredirect_uriを検証し、ホワイトリストに含まれるURLのみを許可する。
• 常にtokenではなくcodeを交換するようにする（response_type=tokenを許可しない）。
• stateパラメータをランダムなハッシュと共に利用し、OAuth認証プロセスでのCSRFを防ぐ。
• デフォルトのscopeを定義し、アプリケーション毎にscopeパラメータを検証する。

入力

• 操作に応じて適切なHTTPメソッドを利用する。GET（読み込み）, POST（作成）, PUT/PATCH（置き換え/更新）, DELETE（単一レコードの削除）。リクエストメソッドがリソースに対して適切ではない場合、405 Method Not Allowedを返す。
• リクエストのAcceptヘッダ（コンテンツネゴシエーション）のcontent-typeを検証する。サポートしているフォーマット（例: application/xml, application/json等）は許可し、そうでない場合は406 Not Acceptableを返す。
• POSTされたデータのcontent-typeが受け入れ可能（例: application/x-www-form-urlencoded, multipart/form-data, application/json等）かどうかを検証する。
• ユーザーの入力に一般的な脆弱性が含まれていないことを検証する（例: XSS, SQLインジェクション, リモートコード実行等）。
• URLの中に機密情報（認証情報, パスワード, セキュリティトークン）を利用せず、標準的な認証ヘッダを使用する。
• サーバー側の暗号化のみを使用する。
• キャッシュ、Rate Limit policies（例: Quota, Spike Arrest, Concurrent Rate Limit）を有効化し、APIリソースのデプロイを動的に行うため、APIゲートウェイサービスを利用する。

処理

• 壊れた認証プロセスを回避するため、全てのエンドポイントが認証により守られていることを確かめる。
• ユーザーに紐付いたリソースIDを使用してはならない。/user/654321/ordersの代わりに/me/ordersを利用する。
• オートインクリメントなIDを利用せず、代わりにUUIDを利用する。
• XMLファイルをパースする場合、XXE（XML external entity attack）を回避するため、entity parsingが有効でないことを確認する。
• XMLファイルをパースする場合、exponential entity expansion attackによるBillion Laughs/XML bomb攻撃を回避するためentity expansion が有効でないことを確認する。
• ファイルアップロードにはCDNを利用する。
• 大量のデータを扱う場合、バックグラウンドでWorkerプロセスやキューを出来る限り使用し、レスポンスを速く返すことでHTTPブロッキングを避ける。
• デバッグ・モードを無効にすることを忘れない。
• 可能な場合は、実行不可能なスタックを使用する。

出力

• 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.
• 認証情報, パスワード, セキュリティトークンといった機密情報を返さない。
• 処理の終了時に適切なステータスコードを返す（例: 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed等）。

CI & CD (継続的インテグレーションと継続的デリバリー)

• ユニットテスト/結合テストのカバレッジで、設計と実装を継続的に検査する。
• コードレビューのプロセスを採用し、自身による承認を無視する。
• プロダクションへプッシュする前に、ベンダのライブラリ、その他の依存関係を含め、サービスの全ての要素をアンチウイルスソフトで静的スキャンする。
• コードに対してセキュリティ・テスト（静的/動的分析）を継続的に実行する。
• 既知の脆弱性について、依存関係（ソフトウェアとOSの両方）を確認する。
• デプロイのロールバックを用意する。

モニタリング

• すべてのサービスとコンポーネントに集中ログインを使用する。
• すべてのトラフィック、エラー、リクエスト、およびレスポンスを監視ために、エージェントを使用する。
• SMS、Slack、Email、Telegram、Kibana、Cloudwatch、などのアラートを使用する。
• クレジット・カード、パスワード、ＰＩＮ、などの機密データをログに記録していないことを確認する。
• ＡＰＩリクエストとインスタンスを監視ためにＩＤＳやＩＰＳシステムを使用する。

---

参照：

• 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して、変更し、プルリクエストを送信し、自由にコントリビューションしてください。何か質問があれば [email protected] まで電子メールを送ってください。