概要

API（Application Programming Interface）はシステム間の通信を担うインターフェースで、現代のWebアプリケーション・マイクロサービス・モバイルアプリの基盤です。SC試験では「認証・認可の不備」「JWTの安全な使い方」「レート制限」など、API 固有の脆弱性が問われます。

仕組みと動作原理

REST API の認証・認可モデル

方式特徴用途
APIキーシンプル。ヘッダまたはクエリに含めるサーバ間通信・公開API
Basic認証Base64エンコードのみ（暗号化なし）非推奨（TLS必須）
Bearer Token（JWT）ステートレス。署名付きトークン現代のWebアプリ・モバイル
OAuth 2.0認可フレームワーク。スコープで権限を制御第三者API連携
mTLSクライアント証明書による相互認証マイクロサービス間通信
REST APIの主な認証・認可方式
APIキー
サーバ間通信
Basic認証
非推奨
Bearer Token(JWT)
ステートレス
OAuth 2.0
第三者API連携
mTLS
相互証明書認証
API
リクエスト受付

JWT（JSON Web Token）の仕組みと落とし穴

JWTは ヘッダ.ペイロード.署名 の3パートをBase64URLエンコードしたトークンです。

JWTの典型的なセキュリティ問題：

脆弱性内容対策
alg: none 攻撃アルゴリズムを none に書き換えて署名を省略none を明示的に拒否する
弱い秘密鍵HMAC-SHA256 の秘密鍵が短すぎてブルートフォース可能256ビット以上のランダムな秘密鍵
署名の未検証サーバ側でデコードのみしてペイロードを信用必ず署名を検証
有効期限なしexp クレームが設定されていない適切な有効期限（15分〜1時間が一般的）を設定
アクセストークンの長期保存ローカルストレージに保存するとXSSで盗取されるHTTPOnly Cookieに保存

OWASP API Security Top 10（2023）

順位脆弱性概要
API1オブジェクトレベル認可の不備（BOLA）他ユーザのリソースIDを指定してアクセスできる
API2認証の不備認証メカニズムが弱い・バイパス可能
API3オブジェクトプロパティレベル認可の不備変更を許可されていないフィールドを書き換えられる
API4リソース消費の無制限レート制限なし・ページサイズ無制限
API5機能レベル認可の不備（BFLA）一般ユーザが管理者向けAPIを呼び出せる
API6機密ビジネスフローへの無制限アクセスボットによる大量注文・割引コードの総当り
API7サーバサイドリクエストフォージェリ（SSRF）APIを通じて内部ネットワークへのリクエストを送信
API8セキュリティの設定ミスデバッグ情報の公開・不要なHTTPメソッドの許可
API9インベントリ管理の不備古いAPIバージョンが残存・シャドウAPI
API10APIの不安全な利用サードパーティAPIからの応答を検証せずに使用

BOLAとBFLAの具体例

BOLA（Broken Object Level Authorization）：

# 本来は自分のデータのみアクセス可能なはずが…
GET /api/orders/12345  → 自分の注文（正常）
GET /api/orders/12346  → 他人の注文が返ってくる（BOLA）

対策：すべてのオブジェクトアクセスでログイン中のユーザが所有者かを確認。

BFLA（Broken Function Level Authorization）：

# 一般ユーザが管理者向けAPIを呼べてしまう
DELETE /api/admin/users/123  → 一般ユーザからでも実行できてしまう（BFLA）

対策：エンドポイントごとにロールベースの認可を実装。

BOLA攻撃が成立するまでの流れ
1
攻撃者
自分のオブジェクトIDでログイン
正規の認証は通過する
 2
攻撃者
リクエスト中のIDを他人のものに書き換え
例: /api/orders/12345 → 12346
 3
API
所有者チェックをせず処理
認可チェックの漏れ（脆弱な実装）
 4
攻撃者
他人のリソースを取得・操作
BOLAの成立

レート制限とスロットリング

手法説明
リクエスト数制限単位時間あたりのリクエスト数を制限（例: 100 req/min）
スロットリング制限超過時にリクエストを遅延させる（拒否しない）
IPベース制限同一IPからの過剰リクエストをブロック
ユーザ/APIキーベース制限認証済みユーザごとに制限

レート制限がないと、資格情報スタッフィング・ブルートフォース攻撃・スクレイピングなどに悪用されます。

SC試験での頻出ポイント

  • JWTの署名検証の重要性：ペイロードはBase64エンコードのみで「暗号化されていない」ことに注意
  • BOLAが最も多い脆弱性：OWASP API Top 10の1位。オブジェクトIDの推測しやすさと認可チェックの漏れが原因
  • レート制限の目的：ブルートフォース・スクレイピング・DoSの緩和
  • SSRFとAPI：外部URLを受け取るAPIエンドポイントが内部ネットワークへの踏み台になる
  • 古いAPIバージョンの残存（シャドウAPI）：v1が放置されていてv2で修正した脆弱性が残っているパターン

よくある誤問・ひっかけパターン

誤り① 「JWTはBase64エンコードされているので内容は見えない」→ 誤。Base64はエンコードであり暗号化ではありません。JWTのペイロードはデコードすれば誰でも読めます。

誤り② 「APIキーをURLクエリパラメータで送ることは一般的な方法である」→ 問題あり。URLはサーバログ・ブラウザ履歴・Refererヘッダに残るため、APIキーは Authorization ヘッダで送るべきです。

誤り③ 「認証があれば認可の確認は不要」→ 誤。「誰であるか（認証）」と「何ができるか（認可）」は別です。BOLAはログイン済みユーザが他ユーザのリソースにアクセスする脆弱性です。

関連用語

重要キーワード

用語説明
JWTヘッダ・ペイロード・署名をBase64URLエンコードしたトークン形式
BOLAオブジェクトレベルの認可不備。他人のリソースIDでアクセスできる脆弱性
BFLA機能レベルの認可不備。一般ユーザが管理者機能を呼び出せる脆弱性
レート制限単位時間あたりのAPIリクエスト数を制限して乱用を防ぐ仕組み
SSRFサーバ側にリクエストを発行させて内部ネットワークにアクセスする攻撃
シャドウAPI管理されていない古いAPIバージョン。セキュリティパッチが当たっていない