「APIキーやトークンで認証してるから安全」
「社内向けAPIだから外部から攻撃されない」
「認証は実装した。あとはアプリ側でよろしく」

  1. 認証（Authentication）は、セキュリティの出発点に過ぎません。
    認証をパスした後に、どれだけの脅威があるかを知ると、認識が変わります。

1. 認証の次に来る5つの脅威

脅威①：認可の欠陥（BOLA/IDOR）

認証済みのユーザーAが、ユーザーBのデータにアクセスできてしまう問題です。

// 壊れる例
GET /api/invoices/12345
// ユーザーAがIDを変えるだけでユーザーBの請求書を取得できる
GET /api/invoices/12346

対策：リクエストごとに「このユーザーは本当にこのリソースにアクセスしてよいか」をサーバー側で検証する。

脅威②：レート制限の欠如

認証済みAPIに対して、1秒間に1万件のリクエストを送り続けると：

  • サービスがダウンする（DoS）
  • ブルートフォースによるデータ探索ができてしまう
  • コスト爆発（クラウドAPIの場合）

脅威③：入力検証の欠如

APIの入力パラメータを信用してそのままDBに渡すと、SQLインジェクションやコマンドインジェクションの温床になります。

脅威④：機密情報のレスポンス漏えい

json

// 壊れる例：必要以上の情報を返す
{
  "user_id": "123",
  "email": "user@example.com",
  "password_hash": "...", // 不要
  "internal_role": "admin", // 不要
  "api_key": "sk-..." // 絶対不要
}

脅威⑤：監査ログの欠如

誰が・いつ・どのAPIを・どんなパラメータで呼んだかを記録しないと、インシデント発生後の調査が不可能になります。

2. 認可設計：リクエストごとに必ず検証する

OWASPのAPI Security Top 10で最上位に来るのが**BOLA（Broken Object Level Authorization）**です。

安全な設計のポイント：

  • リソースIDはDBの連番ではなくUUIDを使う（推測困難にする）
  • アクセス前に「このリソースはこのユーザーのものか」をサーバー側で必ず確認
  • フレームワークに依存せず、アプリケーションレイヤーで明示的に実装する

3. レート制限の実装

API Gatewayやミドルウェアレイヤーで実装するのが基本です。

設計のポイント：

  • ユーザー単位・IP単位の両方で制限する
  • 制限に引っかかった場合は429 Too Many Requestsを返し、理由を明示
  • 制限値はAPIの性質に合わせて設定（認証APIは特に厳しく）

4. 監査ログ：何を記録するか

APIの監査ログに最低限含めるべき項目：

  • リクエスト時刻、エンドポイント、HTTPメソッド
  • 認証ユーザーID
  • クライアントIPアドレス
  • レスポンスコード
  • リクエストボディのサイズ（本文は除く場合も多い）
  • 処理時間

これをSentinelやSplunkに連携することで、APIレイヤーの異常検知が可能になります。

5. 異常検知：通常と異なるAPIの使われ方

正常なAPI利用パターンを学習させ、逸脱を検知します。

異常パターンの例：

  • 特定ユーザーが深夜に大量のGETリクエストを連続送信
  • 普段使わないエンドポイントへの突然のアクセス増加
  • 地理的に不自然な場所からのAPIアクセス

6. Colorkrew Securityの考え方

Colorkrew Securityでは、APIセキュリティの設計レビューと実装支援を行っています。

APIセキュリティは認証の次から始まります。
認可・レート制限・監査ログ・異常検知まで、“壊れない設計"を一緒に作りましょう。