Skip to content

README-ja.md

Latest commit

 

History

History
122 lines (90 loc) · 9.31 KB

README-ja.md

File metadata and controls

122 lines (90 loc) · 9.31 KB

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、などのアラートを使用する。
  • クレジット・カード、パスワード、ＰＩＮ、などの機密データをログに記録していないことを確認する。
  • ＡＰＩリクエストとインスタンスを監視ためにＩＤＳやＩＰＳシステムを使用する。

参照：

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