api-security-testing

API のセキュリティテスト

API の障害の仕方は Web UI とは異なります。クロールできる描画済みの画面がなく、注目すべき脆弱性はインジェクション関連ではなく認可関連であり、同じエンドポイントでもトークンによって動作が異なります。このワークフローでは、Strix の自律型エージェントを使ってこうした特性を対象にテストします。カバレッジのチェックリストには、現在の OWASP API Security Top 10（2023）を使用します。Web アプリ向けの同等の手順では、現在のエディションである OWASP Top 10:2025 を使用します。詳細は owasp-top-10-testing を参照してください。

インストール、LLM の設定、CLI のすべてのフラグ、マネージドクラウドの手順については、penetration-testing-with-strix スキルを参照してください。strix --version が失敗する場合や、対象が API ではない場合は、そちらをお読みください。Docker も LLM キーも使わずに実行する場合は、同じバイナリでマネージドプラットフォームを利用できます。strix cloud login を実行してから、strix cloud scans start ... を実行してください（詳細は managed-pentesting-with-strix を参照）。

1. エージェントに必要な情報を集める

API を何も情報がない状態でテストするのはほぼ不可能なので、まず情報を集めます。

入力	重要な理由
スキーマ — OpenAPI/Swagger ファイル、Postman コレクション、GraphQL エンドポイント（イントロスペクション）、または gRPC の .proto	推測ではなく、すべてのエンドポイントを列挙できます。カバレッジを大きく高める最も効果的な方法です。OpenAPI/Swagger または Postman の仕様書（.json／.yaml／.yml）は、Strix が対象として直接受け取れます。.proto は直接受け取れないため、--workspace-file を付けて渡してください。
2 組の認証情報／トークン。できれば異なるテナントのもの	BOLA/IDOR（API1:2023）は、現在も API の最大のリスクです。テナント A のオブジェクトにテナント B のトークンでアクセスして、初めて 実証 できます。
低い権限と高い権限のトークン	関数レベルの認可不備（API5:2023 — user が管理者専用ルートを呼び出すケース）を実証するために必要です。
オブジェクト ID の例	有効な識別子を探す時間を省き、エージェントがすぐに ID の改ざんをテストできます。
テスト対象外のルート	決済、一斉通知、破壊的な管理者用エンドポイントなどです。
API の前段にあるレート制限／WAF	エージェントがリクエストの制限で予算を使い果たすのを防ぎます。テストを調整できるよう、これらの情報も伝えてください。

不足している情報はユーザーに尋ねてください。トークンを捏造したり、所有者の許可を得ていない API をスキャンしたりしないでください。

2. スキャンを実行する

仕様は指示文中の文章ではなく、ターゲットとして渡してください。Strix は OpenAPI／Swagger（.json／.yaml）と Postman コレクションのエクスポートを直接解析するため、エージェントは実際のエンドポイント一覧をもとに開始できます。

strix -n -t ./openapi.yaml -t https://api.staging.example.com --max-budget 20 \
  --instruction "Tenant A token: <tokenA> (org 1111, user id 11, order id 501).
Tenant B token: <tokenB> (org 2222, user id 22).
Admin token: <tokenAdmin>.
Focus: BOLA across orgs (API1), function-level authz on /admin/* (API5), object property level authz on PATCH /users/{id} — both mass assignment and over-exposed fields in list responses (API3), unrestricted resource consumption (API4).
Out of scope: POST /billing/*, POST /notifications/broadcast."

• **OpenAPI の代わりに Postman を使う場合：**コレクションのエクスポートをターゲットとして使用できます（-t ./collection.postman_collection.json）。または、-t postman://<collection-uuid> でオンラインから取得できます（必要に応じて "postman://<collection-uuid>?env=<environment-uuid>" を指定します）。環境変数に POSTMAN_API_KEY が必要です。
• **複数のサービスを一度に指定する場合：**ファイルにターゲットを1行ずつ記述し、--target-list ./targets.txt を渡します。-t と繰り返し指定したり、組み合わせたりできます。
• より詳細な解析のためにバックエンドのソースを追加する場合：-t ./services/api -t https://api.staging.example.com を指定します。コードにアクセスできると、エージェントはレスポンスから推測するのではなく、認可チェックやオブジェクトの所有権について検討できます。
• **gRPC：**エンドポイントをターゲットに指定し、定義ファイルをワークスペースファイルとして渡します。例：-t https://grpc.staging.example.com --workspace-file ./service.proto。ターゲットとして認識される仕様は .json、.yaml、.yml のみです。そのため、-t ./service.proto を指定すると「Path exists but is not a directory」というエラーになります。
• **GraphQL：**GraphQL エンドポイントを指定し、イントロスペクションが有効かどうかを伝えます。バッチ処理やエイリアスの悪用、深度／複雑度の制限、フィールド単位の認可をテストするよう明記してください。
• **お使いのマシンから到達できない内部／プライベート API：**マネージドプラットフォームのネットワークコネクターを使用してください。managed-pentesting-with-strixを参照してください。
• 認証情報やコンテキストのブロックが長くなる場合は --instruction-file を使用し、トークンがシェルの履歴やコミット対象のファイルに残らないようにしてください。
• エージェントに読み込ませるだけで、テスト対象にはしない補助ファイル（エンドポイントのワードリストやテナンシーモデルに関する手書きのメモなど）には、--workspace-file ./notes.md を渡します。Strix はファイルを /workspace にコピーします。お使いのマシン上のファイルは変更されません。保存先のパスを指定するには :DEST を追加します。例：--workspace-file ./wordlist.txt:lists/wordlist.txt。

3. 検出結果を検証する

まず strix_runs/<run>/penetration_test_report.md を確認し、次に vulnerabilities/*.md を確認してください。各ファイルには、問題を実証した正確なリクエストが記載されています。報告する前に（たとえば curl で）再実行してください。認可に関する検出結果では、レスポンスに空の 200 が含まれているのではなく、実際に他のテナントのデータが含まれていることを確認してください。

findings.sarif は GitHub code scanning にアップロードでき、vulnerabilities.json はチケット管理に使える構造化インデックスです。

4. 修正して再テストし、継続的にテストする

fix-security-vulnerabilities-with-strixを使って修正します（単一のエンドポイントではなく、認可チェックを修正してください）。その後、同じターゲットに対して再実行し、エクスプロイトが使えなくなったことを確認します。ci-security-scanning-with-strixを使ってプルリクエストの CI に組み込み、新しいエンドポイントのリリース時にテストされるようにしてください。