APIセキュリティ

APIセキュリティの全体像

APIは『プログラムが叩く窓口』なので、人間向け画面と違い機械的に大量・自動で攻撃される前提で守る必要があります。OWASPは Web向けの Top 10 とは別に API Security Top 10(最新は2023年版)を出しています。要点を絞って見ていきます。

最大リスク: BOLA(=IDOR)

API版Top10の堂々1位がAPI1 BOLA(Broken Object Level Authorization)。これはWeb版の A01 とほぼ同じで、俗に IDOR とも呼ばれます。

具体例: GET /api/orders/123 で自分の注文が見られるとき、攻撃者が 124 125...とIDを順に変えるだけで他人の注文を覗けてしまう。原因は『そのIDの持ち主が本当にあなたか』をサーバが毎回チェックしていないこと。

図を描画中...

対策はシンプルで強力: リクエストごとに『このリソースの所有者 == ログイン中のユーザー』を必ず確認する。

レート制限(Rate Limiting)

『1人が一定時間に呼べる回数』に上限を設けます。これが無いと:

• DoS/枯渇: 大量リクエストでサーバを潰される
• 総当たり(ブルートフォース): ログインAPIをひたすら叩いてパスワード破り
• スクレイピング: データを根こそぎ持っていかれる
• 課金爆発: 従量課金のクラウドやAPIで、料金が天井知らずに

上限を超えたら HTTP 429 (Too Many Requests) を返します。代表的な方式に Token Bucket / Leaky Bucket / Fixed Window / Sliding Window があります。

ログインAPIにレート制限を付ける理由は総当たり攻撃(OWASP A07)対策。これは面接頻出。

入力検証(サーバ側で必ず)

APIに来る入力はすべて疑う。型・長さ・範囲・形式を検証します。

• allowlist(許可リスト)方式 > denylist(拒否リスト)方式: 『OKなものだけ通す』方が、『NGなものを列挙して弾く』より堅い(NGは数え漏れる)。
• 検証はサーバ側で必須。クライアント側のJS検証はUXのためであって、セキュリティの当てにはできない(攻撃者はブラウザを通さず直接APIを叩ける)。

シークレット管理

APIキー・DBパスワード・秘密鍵の扱い:

• 絶対NG: コードやGitリポジトリにハードコードする。公開リポジトリはもちろん、privateでも漏洩リスク。
• 正解: 環境変数や専用のシークレットマネージャ(HashiCorp Vault、AWS Secrets Manager等)で管理し、定期ローテーション+最小権限+監査ログ。
• Gitにpushしてしまったら: その鍵は漏洩済みとして即無効化・再発行する。コミット履歴から消すだけでは不十分(誰かが既に取得済みかもしれない)。

OWASP API Top 10(2023)抜粋

項目	概要	対策
API1 BOLA	ID直打ちで他人のリソース取得(IDOR)。最大リスク	リクエスト毎に所有者・権限確認
API2 Broken Authentication	トークン/認証の不備	強い認証、トークン失効、MFA
API3 Broken Object Property Level Authz	過剰なデータ露出・mass assignment	返却/受理するフィールドを明示制御
API4 Unrestricted Resource Consumption	レート/リソース無制限による枯渇・課金爆発	レート制限、ページング、タイムアウト
API5 Broken Function Level Authz	管理者用APIに一般ユーザーが到達	機能ごとの認可、デフォルト拒否

つまずきポイント

• 『公開APIにレート制限が無いとどうなる?』→ DoS・総当たり・大量取得・課金爆発。429を返す。即答できるように。
• BOLA/IDORは『認可の抜け』。認証(ログイン)は通っているので気づきにくいが、ID毎の所有者チェックを毎回やれば防げる。
• mass assignment: クライアントが送ってきたフィールドを丸ごとDBに反映すると、isAdmin=true のような送るべきでない項目まで更新されてしまう。受理するフィールドを明示的に絞る(API3)。

---

📊 図解

APIゲートウェイの通過フロー(フローチャート)

認証・レート制限・入力検証・所有者チェックの各関門を通過して初めて処理されます。

図を描画中...