APIセキュリティテスト: OWASP Top 10、ツールとチェックリスト

はじめに

APIは現代のアプリケーションで最も一般的な攻撃ベクターです。Gartnerによると、2024年までにAPIへの攻撃はエンタープライズWebアプリケーションで最も頻繁な攻撃ベクターとなっています。公開しているすべてのAPIは攻撃者にとって潜在的な入口であり、従来のWebアプリケーションセキュリティテストだけではそれらを保護するのに十分ではありません。

APIセキュリティテストとは、APIエンドポイントを脆弱性、認証バイパス、データ漏洩、インジェクション攻撃、ビジネスロジックの欠陥について体系的にテストする取り組みです。このガイドでは、OWASP APIセキュリティTop 10、コード例を含む実践的なテスト技術、利用可能な最良のツール、そして従うべき包括的なチェックリストを取り上げます。

APIを構築する開発者、セキュリティを検証するQAエンジニア、シフトレフトセキュリティを実装するDevSecOpsリードのいずれであっても、このガイドはAPIを保護するための実践的な技術を提供します。

OWASP APIセキュリティTop 10（2023年版）

OWASP APIセキュリティTop 10はAPIセキュリティリスクの業界標準フレームワークです。各脆弱性とテスト技術を以下に示します:

API1: Broken Object Level Authorization（BOLA）

最も一般的なAPI脆弱性です。攻撃者はリクエスト内のオブジェクトIDを操作して他のユーザーのデータにアクセスします。

テスト方法:

# ユーザーAとしてログインし、そのリソースを取得
curl -X GET https://api.example.com/users/101/orders \
  -H "Authorization: Bearer USER_A_TOKEN"
# ユーザーAの注文が返される ✓
# ユーザーAのトークンでユーザーBのリソースにアクセスを試みる
curl -X GET https://api.example.com/users/102/orders 

-H "Authorization: Bearer USER_A_TOKEN"
# ユーザーBの注文ではなく403 Forbiddenが返されるべき

修正策: 認証されたユーザーがリクエストされたリソースを所有している（またはアクセス権限がある）ことを常に確認します。クライアントが提供するIDだけに頼らないでください。

API2: Broken Authentication

攻撃者がトークン、キー、パスワードを侵害することを可能にする弱い認証メカニズム。

テスト対象:

• トークンなしで保護されたエンドポイントにアクセスできますか？（401が返されるべき）
• APIは期限切れのトークンを受け入れますか？
• ログイン試行にレートリミットはありますか？
• ログアウト・パスワード変更時にトークンが無効化されますか？
• トークンは安全に保存されていますか（HttpOnly Cookie、localStorageではなく）？

# テスト: 認証ヘッダーなし
curl -X GET https://api.example.com/users/me
# 期待値: 401 Unauthorized
# テスト: 期限切れトークン
curl -X GET https://api.example.com/users/me 

-H "Authorization: Bearer EXPIRED_TOKEN_HERE"
# 期待値: 401 Unauthorized
# テスト: ブルートフォース保護（急速なログイン試行）
for i in {1..100}; do
curl -s -o /dev/null -w "%{http_code}\n" 

-X POST https://api.example.com/auth/login 

-d '{"email":"victim@example.com","password":"guess'$i'"}'
done
# 期待値: 数回の試行後に429 Too Many Requests

API3: Broken Object Property Level Authorization

APIが隠蔽または読み取り専用にすべき機密オブジェクトプロパティを露出させている。

テスト方法:

# テスト: 一般ユーザーが管理者のみのフィールドを設定できますか？
curl -X PATCH https://api.example.com/users/101 \
  -H "Authorization: Bearer REGULAR_USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role": "admin", "isVerified": true}'
# 期待値: "role"と"isVerified"は無視されるか403が返されるべき

API4: Unrestricted Resource Consumption

APIがリクエスト率、ペイロードサイズ、リソース集約型の操作を制限していない。

テスト対象:

• 大きなペイロードを送信する（100MB JSONボディ）
• 非常に大きなページサイズをリクエストする（GET /users?limit=1000000）
• 高コストな操作を繰り返しトリガーする
• 過大なファイルをアップロードする

API5: Broken Function Level Authorization

一般ユーザーが管理者のみのAPIエンドポイントにアクセスできる。

# テスト: 一般ユーザートークンで管理者エンドポイントにアクセス
curl -X GET https://api.example.com/admin/users \
  -H "Authorization: Bearer REGULAR_USER_TOKEN"
# 期待値: 403 Forbidden
curl -X DELETE https://api.example.com/admin/users/102 

-H "Authorization: Bearer REGULAR_USER_TOKEN"
# 期待値: 403 Forbidden

API6: Unrestricted Access to Sensitive Business Flows

正当なビジネス機能の自動化による悪用（スカルピング、スパム、クーポン悪用など）。

API7: Server Side Request Forgery（SSRF）

APIが検証なしにユーザーが提供する外部URLをフェッチし、攻撃者が内部ネットワークをスキャンできる。

# テスト: URLパラメーターを通じた内部サービスへのアクセスを試みる
curl -X POST https://api.example.com/fetch-url \
  -d '{"url": "http://169.254.169.254/latest/meta-data/"}'
# ブロックされるべき - これはAWSメタデータを標的にしている
curl -X POST https://api.example.com/fetch-url 

-d '{"url": "http://localhost:6379/"}'
# ブロックされるべき - これは内部Redisを標的にしている

API8: Security Misconfiguration

セキュリティヘッダーの欠如、詳細なエラーメッセージ、不必要なHTTPメソッドの有効化。

# テスト: セキュリティヘッダーを確認
curl -I https://api.example.com/users
# 以下のヘッダーが存在することを確認:
# X-Content-Type-Options: nosniff
# X-Frame-Options: DENY
# Strict-Transport-Security: max-age=31536000
# Content-Security-Policy: default-src 'self'
# テスト: 詳細なエラーメッセージを確認
curl -X GET https://api.example.com/users/invalid
# スタックトレース、データベースの詳細、内部パスを露出すべきでない

API9: Improper Inventory Management

古いAPIバージョンにアクセス可能、未ドキュメントのエンドポイントが露出、開発・ステージングエンドポイントが公開されたまま。

テスト対象: /api/v2/が現行の場合に/api/v1/へのアクセスを試みます。/debug、/swagger、/graphql、/actuatorなどの一般的なパスを確認します。

API10: Unsafe Consumption of APIs

APIが検証なしにサードパーティAPIからのデータを盲目的に信頼している。

APIセキュリティテストツール

OWASP ZAP（Zed Attack Proxy）

OWASPが維持する無料のオープンソースセキュリティテストツールです。APIの一般的な脆弱性を自動的にスキャンできます。

# API ScanでAPIに対してZAPを実行
docker run -t zaproxy/zap-stable zap-api-scan.py \
  -t https://api.example.com/openapi.json \
  -f openapi \
  -r report.html

Burp Suite

WebおよびAPIセキュリティテストの業界標準ツールです。Burp Suite Professionalは自動スキャン、Intruder（ファジング）、手動テスト用Repeaterを提供します。

Postman + セキュリティスクリプト

既存のPostmanコレクションにセキュリティテストスクリプトを追加できます:

// セキュリティチェック用Postmanテストスクリプト
pm.test("レスポンスに機密データが含まれていない", () => {
  const body = pm.response.text();
  pm.expect(body).to.not.include("password");
  pm.expect(body).to.not.include("ssn");
  pm.expect(body).to.not.include("credit_card");
});
pm.test("セキュリティヘッダーが存在する", () => {
pm.expect(pm.response.headers.get("X-Content-Type-Options")).to.equal("nosniff");
pm.expect(pm.response.headers.get("Strict-Transport-Security")).to.exist;
});
pm.test("サーバーバージョンが開示されていない", () => {
pm.expect(pm.response.headers.get("Server")).to.not.include("Apache/2.4");
pm.expect(pm.response.headers.get("X-Powered-By")).to.not.exist;
});

Qodex.ai

Qodex.aiはOWASP Top 10の脆弱性についてAPIを自動的にスキャンする組み込みのセキュリティテストを含んでいます。AIエージェントは機能テストと並行してセキュリティテストケースを生成し、認証バイパス、インジェクション攻撃、データ漏洩をセキュリティの専門知識なしにカバーします。

Nuclei

高速なテンプレートベースの脆弱性スキャナーです。APIセキュリティテスト用の何千ものコミュニティ提供テンプレートがあります。

# APIの既知の脆弱性をスキャン
nuclei -u https://api.example.com -t api/ -severity critical,high

ツール比較

APIセキュリティテストチェックリスト

構築またはレビューするすべてのAPIにこのチェックリストを使用してください:

認証

• すべてのエンドポイントが認証を要求する（パブリックなものを除く）
• トークンが妥当な期間内に失効する
• リフレッシュトークンのローテーションが実装されている
• ログイン失敗試行にレートリミットが適用されている
• パスワードリセットフローが安全である
• APIキーがURLに露出していない（ヘッダーを使用する）

認可

• すべてのエンドポイントでオブジェクトレベルの認可（BOLA保護）
• 機能レベルの認可（管理者エンドポイントが制限されている）
• プロパティレベルの認可（機密フィールドが保護されている）
• HTTPメソッドを変更することで認可がバイパスできない

入力検証

• すべての入力が検証されている（型、長さ、フォーマット、範囲）
• SQLインジェクション保護（パラメータ化クエリ）
• NoSQLインジェクション保護
• リクエストボディサイズの制限が適用されている
• ファイルアップロードの検証（型、サイズ、内容）

データ保護

• HTTPSが強制されている（HSTSヘッダーが存在する）
• レスポンスに機密データが露出していない（パスワード、トークン、PII）
• 機密データがログに記録されていない
• CORSが制限的に設定されている
• レスポンスヘッダーが機密データのキャッシュを防いでいる

レートリミットとスロットリング

• すべてのエンドポイントにレートリミットがある
• 認証エンドポイントにはより厳格な制限がある
• レートリミットヘッダーが返される（X-RateLimit-*）
• 制限を超えた場合に429ステータスコードが返される

CI/CDへのセキュリティテストの統合

セキュリティテストはリリース前だけでなく、すべてのコード変更時に自動化して実行されるべきです。

# GitHub Actions - APIセキュリティスキャン
name: API Security Tests
on:
  push:
    branches: [main, develop]
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
  - name: APIサーバーを起動
    run: docker-compose up -d

  - name: APIの起動を待機
    run: npx wait-on http://localhost:3000/health

  - name: OWASP ZAPスキャンを実行
    uses: zaproxy/action-api-scan@v0.7.0
    with:
      target: http://localhost:3000/openapi.json
      rules_file_name: .zap/rules.tsv
      fail_action: true

  - name: カスタムセキュリティテストを実行
    run: npm run test:security

  - name: セキュリティレポートをアップロード
    if: always()
    uses: actions/upload-artifact@v4
    with:
      name: security-report
      path: zap-report.html

関連記事: Rugcheck APIキーの取得とAPIの使い方

セキュリティファーストのAPIテスト戦略を構築する

APIセキュリティテストは他のテスト種別と組み合わせることで最大の効果を発揮します:

• 機能テスト: 正しい動作を検証する（REST APIテストガイド）
• 負荷テスト: 負荷下のパフォーマンスを検証する（API負荷テストガイド）
• 統合テスト: サービス間の連携を検証する（API統合テストガイド）
• セキュリティテスト: 攻撃に対する防御を検証する（本ガイド）

利用可能なすべてのテストツールの包括的な概要については、APIテストツール比較をご覧ください。

よくある質問

APIセキュリティテストとは何ですか？

APIセキュリティテストとは、APIエンドポイントを脆弱性、認証バイパス、インジェクション攻撃、データ漏洩、認可の欠陥についてテストするプロセスです。目的は、攻撃者が悪用する前にセキュリティの弱点を特定して修正することです。

OWASP APIセキュリティTop 10とは何ですか？

OWASP APIセキュリティTop 10は、Open Worldwide Application Security Projectが維持する最も重大なAPIセキュリティリスクのリストです。Broken Object Level Authorization（BOLA）、Broken Authentication、Broken Object Property Level Authorization、およびその他7つの一般的なAPI脆弱性が含まれます。

APIセキュリティテストを始めるにはどうすればよいですか？

上記のOWASP APIセキュリティTop 10チェックリストから始めましょう。OWASP ZAPを使用してAPI仕様に対して自動スキャンを実行します。次に認証、認可、インジェクションの脆弱性を手動でテストします。Qodex.aiを使用してAPI仕様からセキュリティテストケースを自動生成しましょう。

APIセキュリティテストに最適なツールは何ですか？

OWASP ZAP（無料、自動スキャン）、Burp Suite（プロフェッショナルなペネトレーションテスト）、Qodex.ai（AI搭載セキュリティテスト生成）、Nuclei（テンプレートベーススキャン）。多くのチームは自動テストツールと手動テストツールを組み合わせて使用します。

SASTとDASTのAPIへの違いは何ですか？

SAST（静的アプリケーションセキュリティテスト）はアプリケーションを実行せずにソースコードを分析します。DAST（動的アプリケーションセキュリティテスト）はリクエストを送信してレスポンスを分析することで実行中のAPIをテストします。両者とも価値があり、SASTはコードレベルの問題を早期に発見し、DASTはランタイムの脆弱性を発見します。

APIセキュリティテストはどのくらいの頻度で実行すべきですか？

自動セキュリティスキャンはすべてのデプロイ時（CI/CD内）に実行すべきです。包括的なペネトレーションテストは四半期ごとまたは主要なリリース前に実施すべきです。DependabotやSnykなどのツールを使用して依存関係の新しい脆弱性を継続的に監視しましょう。