API はモダンソフトウェアの接続組織であり、モバイルアプリ、マイクロサービス、サードパーティ統合を支えています。API はアプリケーションロジックとデータを直接公開するため、攻撃者の格好の標的になっています。API セキュリティは、これらのインターフェースを設計、テスト、防御し、悪用から守る規律です。
API が異なる理由
従来の Web ページとは異なり、API は JSON や XML などの構造化データ形式を通じて通信を行い、多くの場合は人間の監視が最小限です。つまり:
- エンドポイントあたりの攻撃面が大きい — 各 API ルートは本質的に独自の認証、検証、ビジネスロジックを備えた独立したミニアプリケーションです。
- マシン間の信頼 — サービスはリクエストに有効なトークンがあれば正当であると仮定することが多く、攻撃者はトークン盗聴やリプレイを通じてこれを悪用します。
- 急速な変化 — API は迅速に進化し、文書化されていない、または廃止された「シャドウ」エンドポイントがセキュリティレビューを通り抜けることが頻繁です。
一般的な脆弱性クラス
OWASP API Security Top 10 は、本番システムで見られる最も一般的な問題をまとめています:
- Broken Object Level Authorization (BOLA) — ユーザーがリクエスト内の ID を単に変更することで別のユーザーのデータにアクセスできます。これはサーバーが所有権を検証しないためです。
- 認証の破綻 — トークン処理が脆弱、セッション識別子が予測可能、またはログインエンドポイントにレート制限がない。
- 過度なデータ露出 — API がデータベースオブジェクト全体を返し、機密フィールドをフィルタリングすることをクライアントに依存しています。
- リソースとレート制限の欠如 — スロットリングがないと、攻撃者は認証情報をブルートフォースしたり、バックエンドリソースを枯渇させたりできます。
- 関数レベルの認可の破綻 — ロールチェックが欠けているまたは不一貫なため、通常ユーザーが管理者専用エンドポイントにアクセスできます。
- 一括割り当て — クライアント提供フィールド（
isAdminなど）をフィルタリングなしでデータベースモデルに直接受け入れます。 - セキュリティの設定ミス — 詳細なエラーメッセージ、公開されたデバッグエンドポイント、またはセキュリティヘッダーの欠落。
- インジェクション — サニタイズされていない入力が API パラメータを通じて SQL、NoSQL、またはコマンドインタプリタに到達します。
認証と認可の基礎
認証は API を呼び出す誰 かを確認します。認可は彼らが何 をすることが許可されているかを確認します。強固な API セキュリティには、両方のレイヤーがすべてのリクエストに対して独立して実行される必要があります:
- カスタムトークンスキームではなく、OAuth 2.0 や OpenID Connect などの業界標準プロトコルを使用します。
- JWT を適切に検証します — 署名、有効期限、発行者、オーディエンスクレームをチェックします。未署名または
alg: noneトークンを信頼しないでください。 - オブジェクトレベルのチェックをサーバーサイドで実行します。リソース ID を参照するすべてのリクエストは、呼び出し元が実際にそのリソースを所有しているか、アクセス権を持っているかを検証する必要があります。
- API キーとサービスアカウントに最小権限の原則を適用し、広範なアクセスを付与するのではなく、狭くスコープします。
入力検証と出力制御
ヘッダー、クエリ文字列、ネストされた JSON フィールドを含む、すべての API パラメータを信頼できない入力として扱います:
- スキーマ検証（JSON Schema や OpenAPI ベースのバリデータなど）を使用してデータ型、長さ、形式を検証します。
- デシリアライゼーション中の一括割り当て攻撃を防ぐために、予想されるフィールドの許可リストを使用します。
- クライアントが正当に必要とするフィールドのみを返します。レスポンスで内部オブジェクト全体をダンプすることは避けてください。
- エラーレスポンスを標準化して、スタックトレース、内部パス、データベース詳細を漏らさないようにします。
レート制限、監視、ロギング
よく認証された API でさえ、悪用パターンから保護が必要です:
- ユーザーごとおよび IP ごとのレート制限を実装して、ブルートフォースおよびスクレイピング試行を減らします。
- 認証イベント、認可失敗、および異常なアクセスパターンをログに記録して、後で分析します。
- 機密エンドポイントへのリクエストの急増や予期しない地理からのアクセスなど、異常をモニタリングします。
- 正確な API インベントリを維持します — 存在しないものは保護できないため、廃止またはシャドウエンドポイントを追跡して削除します。
実践的なテストアプローチ
API セキュリティは一度限りの監査ではなく、継続的なプロセスです:
- API 固有のツール（セキュリティスキャナーと組み合わせた Postman コレクションなど）を CI/CD パイプラインに組み込みます。
- 認可フローについての手動テストを実行します。自動スキャナーは BOLA とビジネスロジック上の問題を見逃すことがよくあります。
- API ドキュメント（OpenAPI/Swagger 仕様）を実装と同期させ、テスト中の盲点を避けます。
- サードパーティ API 統合をレビューして、自分のコードと同じ精査を行います。侵害されたパートナー API は攻撃ベクトルになる可能性があるためです。
まとめ
API セキュリティは、従来の Web アプリケーションセキュリティ原則と、スケール時のマシン間通信の独自の課題を組み合わせています。認可を正しく実装し、すべての入力を検証し、API サーフェスの可視性を維持することが、回復力のある防御の基礎です。
Web アプリケーションセキュリティと認証設計に関する関連する Korra Studio セグメントを参照して、これらの概念についてより深く、実践的な理解を構築してください。