api-security-testing について
REST、GraphQL、gRPC、WebSocket の API を OWASP API Top 10 に沿って評価するセキュリティテストスキルです。API への直接リクエストで認可やリソース制限を確認し、再現可能な証拠を記録します。
主な機能
- 01OWASP API Top 10 に沿ったテスト
- 02API 仕様から操作を洗い出す
- 03オブジェクト・フィールド・機能の認可確認
- 04レート・サイズ・クエリ制限のテスト
- 05過剰なデータがないか生レスポンスを確認
- 06リクエスト・レスポンス・影響を記録
活用シーン
- 01ユーザーアカウント間の認可を評価
- 02GraphQL のイントロスペクションとクエリ制限を確認
- 03未記載または古い API エンドポイントを発見
- 04API レスポンスのフィールド露出を確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/api-security-testingを入力して読み込まれたか確認します。
同梱ファイルreferences/api-attacks.md
詳細
API セキュリティテスト（発見／悪用 — OWASP API Top 10）
概要
現代のアプリは API ファーストであり、API の不具合は Web ページとは異なります。不具合は表示処理ではなく、オブジェクト／フィールドごとの認可やリソース制限にあります。UI を完全に迂回し、API を直接テストしてください。
基本原則： UI はクライアントの 1 つにすぎません。攻撃者は API に直接リクエストを送ります。各エンドポイント、フィールド、メソッドは、それぞれ個別に認証・認可と制限を適用する必要があります。フロントエンドは何も保護しません。
適用する場合／スキップする場合
- 適用する場合： REST、GraphQL、gRPC、WebSocket など、プログラムから利用できる API をアプリが公開している場合。SPA やモバイルクライアントの背後にある API も含みます。
- スキップする場合： 誰も呼び出せる API がなく、サーバー側で HTML を生成するだけのアプリの場合 → 該当なし。
- 該当しない場合： 「api-security-testing: N/A — no API surface」と報告して終了します。
⚠️ 認可
自分が所有またはテストを許可された API を対象にしてください。状態が変化するテストには、テストアカウントと非本番環境を使用してください。
まず仕様を取得する
API 契約を取得し、そこに記載された操作と UI から判明したすべての操作をテストします。
- OpenAPI／Swagger（
/swagger、/openapi.json、/api-docs）、GraphQL のイントロスペクション、gRPC リフレクション、Postman コレクション、プロキシ経由でのモバイルアプリの通信。 - 文書化されたエンドポイントと、アプリが実際に呼び出すエンドポイントの差分を確認します。文書化されていないエンドポイントは大きな手がかりです。
OWASP API Top 10 — チェックリスト
| # | リスク | テスト |
|---|---|---|
| API1 | BOLA（オブジェクト認可） | アカウント間でオブジェクト ID を入れ替えます → access-control-testing を参照 |
| API2 | 認証の不備 | 脆弱なトークン／JWT／キー → authentication-testing を参照 |
| API3 | BOPLA（プロパティ認可） | 読むべきでないフィールドを読み取る（過剰なデータ露出）／書き込むべきでないフィールドを書き込む（マスアサインメント） |
| API4 | リソース消費の制限不足 | レート／サイズ／ページ数の制限がない、コストの高いクエリ、コスト／DoS |
| API5 | BFLA（機能認可） | 一般ユーザーとして管理者／特権操作を呼び出す |
| API6 | ビジネスフローへの無制限なアクセス | 人間のペースで行うことを想定したフローを自動化する（買い占め、スパム） |
| API7 | SSRF | サーバーが指定した URL を取得する → file-upload-and-ssrf を参照 |
| API8 | 設定ミス | 詳細すぎるエラー、制限の緩い CORS、セキュリティヘッダーの不足 |
| API9 | インベントリ管理の不備 | /v2 と並存する旧 /v1、ステージング API、文書化されていないエンドポイント |
| API10 | サードパーティ API の安全でない利用 | アプリが外部 API の応答を無条件に信頼する |
REST、GraphQL、gRPC、WebSocket の手順については、references/api-attacks.md を参照してください。
UI と比べて過剰なデータ露出
API は多くの場合、UI に表示される以上のデータを返します（passwordHash や内部フラグ、他のユーザーのフィールドを含むユーザーオブジェクト全体など）。表示されたページではなく、生の JSON 応答を確認してください。
GraphQL 固有のポイント（重要度が高い）
- イントロスペクションが有効 → スキーマ全体を把握できます。取得してください。
- バッチ処理／エイリアス → レート制限を回避し、1 つのリクエストでブルートフォース攻撃を実行できます。
- クエリの深さ／複雑さ → 再帰的にネストされたクエリによる DoS。
- フィールドレベルの認可 → あるクエリで保護されているフィールドが、別の経路／ミューテーションから露出することがあります。
出力
検出事項ごとに、エンドポイント／操作、メソッド、使用したアカウント、生のリクエスト／応答、該当する API Top 10 の分類、影響を記載します。BOLA／BFLA の検出事項は通常、High～Critical です。
引き継ぎ
詳細な認可テスト → access-control-testing；認証／JWT → authentication-testing；フローの悪用 → business-logic-testing；再現 → active-pentest；修正 → security-hardening。
よくある間違い
- UI 経由でしかテストしない — API を直接呼び出してください。そこが実際の攻撃対象です。
- 生の JSON ではなく、表示されたページを確認する — 過剰なデータ露出は生の JSON に隠れています。
- GraphQL のイントロスペクション／バッチ処理や gRPC リフレクションを忘れる — API の全体像を把握できます。
- 古い API バージョンを無視する —
/v1には/v2の修正が反映されていないことがよくあります。