APIセキュリティテストだけではクロスアセット攻撃チェーンを見逃す理由
APIだけを対象とするスキャナーは、モバイルアプリ、Webバンドル、コード内のシークレットやルートから始まる攻撃チェーンを見逃します。実際の2つのチェーンと8ステップのテストチェックリストを紹介します。
APIスキャナーが問題のないレポートを返す一方で、攻撃者はすんなりと侵入できてしまうことがあります。攻撃者のリクエストは正当なもので、本物のトークンを含んでおり、サーバーはそれに正しく応答します。問題は、そのトークンがどこから来たかです。それは、モバイルアプリにコンパイルされた文字列、JavaScriptバンドルに残されたルート、Gitの履歴に残ったままのシークレットなど、スキャナーが一度も確認しなかった場所にありました。
APIセキュリティテストだけでは不十分なのは、影響の大きいAPI侵害の多くがAPIから始まらないからです。それらは、モバイルアプリ、JavaScriptバンドル、ソースコードから取り出された認証情報、ルート、リクエスト形式から始まり、それが正当なリクエストとして再送されます。APIだけをテストするスキャナーには、チェーンの始まりがまったく見えません。
当社が評価したあるiOSアプリでは、ハードコードされたAuth0のシークレットが1,000件のレコードを含むユーザーディレクトリにつながっていました。その認証情報に関する最初の検出結果は、すでに「Fixed & Verified」とマークされていたにもかかわらずです。その経緯は後述します。このガイドは、モバイルやWebのクライアントにサービスを提供するAPIを担当するAppSecリードやDevSecOpsエンジニアに向けたものです。
エグゼクティブサマリー（TL;DR）
- 当社の評価では、最も深刻なAPIの検出結果の多くはAPIから始まっていませんでした。クライアントアプリやコードから取り出された認証情報やルートから始まり、それが正当なリクエストとして再送されていました。
- 一度に一つのアセットをテストするスキャナーは、それぞれがチェーンの半分しか見ていません。後からそれらのレポートを一つのダッシュボードに集めても、2つの半分はつながりません。
- こうしたチェーンを捉えるには、クライアントアプリ、コード、稼働中のAPIを同じ評価の中でテストし、修正はサーバー側で行います。
クロスアセット攻撃チェーンとは何か クロスアセット攻撃チェーン（cross-asset attack chain）とは、モバイルアプリ、Webフロントエンド、ソースリポジトリ、バックエンドAPIなど、複数のアセットにまたがって存在する一連の弱点です。個々の弱点は単独では軽微に見えます。しかし組み合わさると、攻撃者は本来決して到達できないはずのデータや機能にアクセスできるようになります。
典型的なチェーンは3つの手順で構成されます。
- 抽出：クライアントやコードから、トークン、署名鍵、文書化されていないルート、リクエスト形式などを取り出します。
- 再送：それを正当なリクエストとしてバックエンドAPIに送ります。
- 昇格：サーバー側の認可の欠陥を突いて、他のユーザーのオブジェクト（BOLA）、特権機能（BFLA）、より広いトークンスコープへと権限を広げます。
ここでの各ステップは、どれも単独では攻撃に見えません。1つ目は静的な文字列、2つ目は認証済みのリクエスト、3つ目は通常のAPIレスポンスです。侵害が見えてくるのは、これらを順番に読み解いたときだけです。
クロスアセット攻撃チェーンは実際にはどのようなものか
以下の2つのチェーンは、Ostorlabの実際の評価から得られたもので、それぞれこのブログでより詳しく公開しています。どちらの評価でもOstorlab Agentic Deep Scanを使用しました。これは、自律型のテストエージェントをアセットに対して実行するもので、1つ目のケースではモバイルバイナリ、2つ目のケースではソースコードが対象でした。いずれも、取り出した認証情報やルートを稼働中のバックエンドに対して再送したときに初めて、確定した侵害となりました。
1. iOSアプリにハードコードされたAuth0クライアントシークレットからテナント全体の管理者スコープへ
AIが複雑な脆弱性を捉える仕組みで取り上げた評価では、あるiOSアプリにAuth0のマシン間（M2M）のclient_idとclient_secretが同梱されていました。どちらもFlutterのDART_DEFINESを通じてビルド時に埋め込まれていました。アプリはそれらを使って一つの内部サービスを呼び出していました。
この認証情報に関する最初の検出結果は、アプリが呼び出す一つのオーディエンスに範囲が限定されたもので、重大度は「高」と評価され、すでに「Fixed & Verified」とマークされていました。この修正で塞がれたのはアプリが使用していた経路であり、認証情報が到達できるすべての範囲ではありませんでした。
静的スキャナーであれば、その文字列を報告するでしょう。APIスキャナーであれば、アプリが正当にリクエストするオーディエンスについては、適切にスコープが設定されたトークンを確認するはずです。しかし、エージェントは別の問いを立てました。M2Mクライアントには複数のAPIへのアクセスを付与できます。では、このクライアントは他に何を呼び出すことが認可されていたのでしょうか。
エージェントは、テナントの/oauth/tokenエンドポイントに対して38個の候補オーディエンスを試しました。Auth0 Management API（https://<tenant>.auth0.com/api/v2/）は、HTTP 200とともに、update:users、delete:users、create:client_credentialsを含む8つの管理者スコープを持つトークンを返しました。続いて、読み取り専用のGETを1回送るだけで、PIIを含むテナントの1,000件のレコードからなるユーザーディレクトリ全体が露出しました。書き込みは一切行っていませんが、このトークンを使えばユーザーの作成、更新、削除が可能でした。この2つ目の検出結果は「クリティカル」と評価され、まだ「Open」のままでした。
単一レイヤーのテストで見逃される理由：認証情報はバイナリの中にあり、過剰なスコープの付与はアイデンティティプロバイダーの設定の中にあります。どちらもAPI仕様には現れません。
2. 所有権を移転してしまう作成エンドポイント（BOLA）
手動レビューとOstorlab Agentic Deep Scanを組み合わせたGoPhishのソースコード評価では、グループ作成エンドポイント（POST /api/groups/）が暗黙のアップサートを実行していました。他のユーザーのグループのidを含む正当なJSONボディを送ると、そのグループの受信者データが上書きされ、所有権が攻撃者に移転していました。
Agentic Deep Scanは、作成ハンドラーがidを受け付けているというパターンをコードの中から浮かび上がらせました。その後、評価では、合成アカウントを用いた隔離されたローカルのGoPhishインスタンスに対し、2人目のユーザーとしてリクエストを再送することで、これを確認しました。この再送はデータを上書きするため、本番環境ではなくラボで行うべきものです。
単一レイヤーのテストで見逃されうる理由：リクエストは正しい形式で認証済みであり、欠陥は入力検証ではなく所有権のロジックにあるため、コントラクトチェックやスキーマベースのファジングには指摘すべきものがありません。複数ユーザーによるテストでこれを捉えられるのは、作成リクエストで他のユーザーのIDを送った場合だけです。ハンドラーを読めば、それをどこで試すべきかが正確にわかります。
単一レイヤーのAPIスキャナーがこうしたチェーンを見逃す理由
単一レイヤーのスキャナーがこうしたチェーンを見逃すのは、それぞれが自分のアセットしか見ていないため、クライアントで見つかったシークレットと、そのシークレットで解錠できるAPIとを結び付けるものが一つもないからです。ほとんどのセキュリティツールは、ソースコード、ゲートウェイやWAFのトラフィック、ステージングサーバーへのテストリクエストなど、スタックの一角だけをカバーしています。どれも壊れているわけではなく、それぞれが自分のアセットを個別にテストしているのです。
しかし、バックエンドAPIを呼び出すのは、モバイルバイナリ（iOSの.ipa、Androidの.apk）、シングルページのWebアプリ、パートナーとの連携、内部サービスであり、それらはすべて、設定情報や、多くの場合はシークレットを、攻撃者が読める場所へと配布しています。一つずつテストすると、各アセットは合格しても、それらの間をつなぐチェーンは見過ごされてしまいます。現在では、コード、実行時、APIのテストを組み合わせるプラットフォームも登場しており、これこそがこうしたチェーンに必要なものです。
APIの認証情報とルートはどこから漏えいするのか
APIの認証情報とルートは通常、攻撃者が取り出せる5つのソースから漏えいします。モバイルバイナリ、Webバンドル、ソースリポジトリとCI、APIドキュメント、そしてWebSocketなどの二次チャネルです。以下は、当社が評価の中で最も頻繁に遭遇するものです。
| ソース | 攻撃者が取り出すもの | APIへの典型的な影響 |
|---|---|---|
| モバイルバイナリ（APK / IPA / AAB） | アプリに同梱すべきでない機密の認証情報（M2Mクライアントシークレットや共有のclient_secretの値など。ネイティブアプリの公開client_idは見えることが想定されている）、ビルド時に注入された特権APIキー（FlutterのDART_DEFINESやAndroidのBuildConfigなど）、暗号鍵とリクエスト署名のロジック、隠されたエンドポイントやデバッグ用エンドポイント |
トークンの発行、リクエスト署名の回避、内部APIやステージングAPIの呼び出し |
| Webバンドル（SPAのJavaScript、ソースマップ） | UIに表示されない管理者用・内部用のルート、機能フラグで制御されたエンドポイント、サードパーティのAPIキー、GraphQLのオペレーション名 | 文書化されていないエンドポイント（シャドーAPI）、UIのチェックなしで到達できる特権機能（BFLA） |
| ソースリポジトリとCI | コミット履歴内のシークレット、デプロイトークン、ルート定義、認可ミドルウェアが欠けたハンドラー | 直接の認証済みアクセス、所有権チェックのないルートの正確な一覧 |
| APIドキュメントとコレクション（OpenAPI、Postman、GraphQLイントロスペクション） | リクエストの完全な形、まだ稼働している非推奨バージョン、オブジェクト識別子の形式 | 古いAPIバージョンを通じた大量の列挙とアクセス（不適切なインベントリ管理） |
| 二次チャネル（WebSocket、gRPC-web） | チャネルが露出させるエンドポイントのパスとオペレーション名、HTTPの認証ミドルウェアを通らないハンドシェイク | 認証されていないデータストリームやサブスクリプション（認証の不備、BFLA） |
OpenAPIファイルとテストアカウントだけで動作するスキャナーは、これらのアーティファクトを一切持たない状態から始まります。そのため、行儀のよいクライアントが使うAPIをテストすることになります。攻撃者が使うAPIはテストしません。
API外部のコンテキストがあると見つけやすくなるOWASP API Top 10のリスク
OWASP API Security Top 10（2023）のリスクは、サーバー側の欠陥です。BOLAとBFLAは、常にAPI側で修正されます。しかし、その中のいくつかは、クライアントアプリやソースコードなど、API外部のコンテキストがあると発見や検証が容易になります。
| OWASP APIのリスク | 発見や検証に役立つ外部のコンテキスト | APIのみのスキャンで見えるもの |
|---|---|---|
| API1: Broken Object Level Authorization (BOLA) | クライアントアプリから得たオブジェクト識別子の形式とリクエストの暗号化 | 自分のテスト用オブジェクトに対するリクエスト（想定どおり成功する） |
| API2: Broken Authentication | バイナリやリポジトリから取り出したクライアント認証情報や長期間有効なトークン | 漏えいした認証情報を誰かが渡さない限り、何も見えない |
| API3: Broken Object Property Level Authorization | クライアントのモデルやGraphQLの型で見つかった隠しフィールド | 仕様に記載されたフィールドのみ |
| API5: Broken Function Level Authorization (BFLA) | Webバンドル内の管理者用ルートと、WebSocketなどの二次チャネル | 仕様に記載されたHTTPルートと、テストアカウントに付与されたロールのみ |
| API8: Security Misconfiguration | 配布された認証情報に結び付いた、過剰なスコープを持つOAuthクライアント、オーディエンス、クラウドのロール | 把握しているエンドポイントにおける通信やヘッダーの問題 |
| API9: Improper Inventory Management | クライアントやコードで参照されているステージングホスト、古いバージョン、デバッグ用エンドポイント | 与えられたインベントリのみ |
残りの4つ（API4 Unrestricted Resource Consumption、API6 Unrestricted Access to Sensitive Business Flows、API7 SSRF、API10 Unsafe Consumption of APIs）は、通常API側からテストされます。
APIゲートウェイ、ASPMプラットフォーム、スキャナーパイプラインがこうしたチェーンを捉えられない理由
ほとんどのチームは、すでにAPIゲートウェイ、ASPMプラットフォーム、あるいは複数のスキャナーを実行するCIパイプラインを持っています。それぞれ役には立ちますが、どれも単独では、漏えいした認証情報をAPIに対してテストすることはありません。よくあるチェーンを考えてみましょう。モバイルアプリにハードコードされたAPIトークンが同梱され、攻撃者がそれを使ってバックエンドを呼び出し、設定ミスによってそのトークンに管理者権限が与えられている、というものです。
APIゲートウェイはリクエストを通してしまう
ゲートウェイは、リクエストの形式が正しいかを確認し、レート制限を適用し、トークンが本物で正しく署名されているかを検証します。この攻撃では、リクエストは正当で、トークンも本物です。公開アプリの中に同梱されたトークンが管理者権限を持つべきではないことを、ゲートウェイが知る術はありません。
ASPMによる集約では点と点がつながらない
アプリケーションセキュリティ態勢管理（ASPM）プラットフォームは、モバイル、コード、APIの各スキャナーからの検出結果を一つのビューに集約します。これはトリアージや担当者の割り当てに役立ちます。しかし、相関付けがスキャン完了後に行われる場合、アセットをまたいでテストされるものは何もありません。独自のスキャナーを同梱しているプラットフォームもあるため、重要な違いは製品カテゴリではなく、相関付けがいつ行われるかです。
| 観点 | ASPMによる集約 | スキャン中の相関付け |
|---|---|---|
| 相関付けが行われるタイミング | 各スキャナーが完了した後 | スキャン中、テストがまだ実行されている間 |
| 相関付けの対象 | すでに存在する検出結果 | 生の発見事項：トークン、ルート、リクエスト形式 |
| 漏えいしたトークンをAPIに対してテストできるか | 集約だけではできない。2つの検出結果を関連付けるのみ | できる。トークンが次のライブテストの入力になる |
| 出力 | 関連する2つの検出結果（重大度が異なることが多い） | リクエストとレスポンスのエビデンスを伴う、検証済みの一つのチェーン |
| 重大度 | 各スキャナーから引き継がれる | チェーンについて実証された影響に基づく |
スキャナーパイプラインはツールを順番に実行するだけで、連携はしない
CIでスキャナーを連結すると、それらは一つずつ順番に実行されますが、他のスキャナーが何を見つけたかを知るものはありません。モバイルスキャナーはAPKやIPAの中にクライアントシークレットを見つけても、それがどこで使えるのかがわからず、重大度の低い静的な検出結果として登録します。APIスキャナーは公開スキーマに基づいてバックエンドをテストし、そのシークレットの存在を知ることはありません。
マルチアセットスキャンはチェーン全体をどのようにテストするか
スキャン中の相関付けとは、ソースコード内のルートやクライアントバイナリ内のトークンなど、あるアセットでの発見が、ただちに稼働中のバックエンドに対するテストの入力になることを意味します。OstorlabのMulti-Asset Deep Agentic Scanは、この考え方に基づいて構築されています。Agentic Deep Scanが一度に一つのアセットを調査するのに対し、Multi-Asset Deep Agentic Scanは、モバイルアプリ、バックエンドAPI、Webフロントエンド、ソースコードなどの関連するアセットにまたがるエージェント型の調査を、単一のスキャンの中で一つ実行します。
スキャンの内部では、モバイルバイナリ、Webフロントエンド、バックエンドAPI、ソースコードのすべてが一つのライブ検証ステップに入力され、そこで漏えいしたトークンやルートがバックエンドに対してテストされます。スキャンは3つの段階で進みます。
- 発見：エージェントはモバイルバイナリ（APK、AAB、IPA）を逆コンパイルし、WebのJavaScriptバンドル、ソースマップ、リポジトリ、ドキュメントを読み込み、計装されたAndroidおよびiOS端末上でアプリを実行してそのトラフィックをキャプチャします。また、よく知られたOpenAPIやSwaggerの配置場所を探索し、GraphQLイントロスペクションを実行します。OpenAPI（Swagger 2.0またはOpenAPI 3.x）やGraphQLのスキーマがあれば最初からカバレッジが向上しますが、必須ではありません。
- 相関付け：エンドポイント、ベースURL、OAuthのオーディエンス、リクエストパラメーター、埋め込まれたトークンなどのクライアント側のアーティファクトを、バックエンドのルートやサービスと照合します。コードやバイトコード内で見つかったシークレットは、確定した脆弱性ではなく、調査すべき手がかりとして扱われます。
- 検証：もっともらしい攻撃経路はそれぞれエクスプロイトエージェントに渡され、稼働中のバックエンドに対してテストされます。たとえば、トークンで認証できるかどうか、あるいはエンドポイントが返すべきでないデータを返すかどうかを確認します。検証済みの検出結果には正確なリクエストとレスポンスが含まれるため、自社のチームで再現できます。
多くのシークレットスキャナーは認証情報らしき文字列を報告しますが、キーが有効かどうかを確認するものでさえ、それがAPIを通じて何に到達できるかまではテストしません。ここでは、チェーンと、それに伴うより高い重大度は、再現できた場合にのみ報告されます。単独の検出結果は、それ自体の重要性に基づいて引き続き報告されます。現時点では機能しない漏えいした認証情報であっても、修正する価値はあります。
現在のプロトコル対応状況：
- GraphQL：HTTP経由のイントロスペクションまたはアップロードされたスキーマによってマッピングし、生成したクエリとミューテーションでテストします。
- SOAP：ライブでテストします。
- gRPC：
.proto定義から、認可とデータ露出のリスクを解析します。ライブのgRPC呼び出しとサーバーリフレクションにはまだ対応していません。 - WebSocketとGraphQLサブスクリプション：Multi-Asset Deep Agentic Scanは、WebSocketトランスポート上でのライブテストにはまだ対応していません。
以下のチェックリストのステップ6で挙げているWebSocketの認可の欠陥は、OstorlabのAI Pentest Engineによる別の対象を絞った評価で発見されたものです。マルチアセットスキャンでは、WebSocketの認可は引き続き手動でのチェックとなります。
自律型のAPIテストをバックエンドに対して実行しても安全か
ガードレールとステージング環境の対象があれば安全です。稼働中のAPIをテストするエージェントは、損害を与えることなく影響を実証しなければならないため、Ostorlabは制御を多層的に重ねています。
- エージェントへの指示：エージェントは、最小限の安全な操作で影響を実証します。BOLAやBFLAの欠陥はレコードの変更ではなく認可されていない読み取りによって示し、トークンは読み取り専用のリクエストで確認します。エージェントは破壊的なコマンドの実行、リバースシェルの起動、永続化の確立、データの変更、認証情報の失効を行いません。
- AIモデルの外部にあるスーパーバイザー：独立した監督プログラムが、実行前にすべてのツール呼び出しと宛先をスキャンのスコープと照合し、スコープ外のリクエストをブロックし、エージェントがスコープ外に出ようとし続ける場合はスキャンを停止します。当社のAIエージェントのスコープ逸脱に関するポストモーテムで、このレイヤーが重要な理由を説明しています。
- エージェントの外部にある制御：ファイアウォールのルールによってスキャンエージェントが到達できる範囲を制限し、リクエスト量はスキャナーのホストで上限が設けられています。
それでも当社は、専用のテストアカウントを用いて、ステージング環境または本番前の環境に対してマルチアセットスキャンを実行することを推奨しています。内部APIについては、オンプレミススキャナーが自社インフラ内のコンテナとして動作し、ジョブを受け取って検出結果を返すための外向きの接続のみを開きます。WAFやIP許可リストの背後にあるステージングAPIについては、Ostorlabのドキュメントで公開されているスキャナーのIPアドレスを許可リストに追加してください。クライアント証明書はまだスキャンの設定項目ではないため、相互TLSの背後にあるAPIについては、mTLSが終端される地点の後ろでオンプレミススキャナーを実行してください。そうすれば、スキャナーがクライアント証明書を必要とすることはありません。
自社のスタックでクロスアセットのチェーンをテストする方法
オープンソースのツールと、数時間の集中した作業から始められます。以下の8つのステップに沿って、モバイルからAPI、コードからAPI、トランスポートをまたぐチェーンを見つけてください。
- APIのすべてのクライアントを洗い出す：APIを呼び出すモバイルアプリ、Webフロントエンド、パートナーとの連携、内部サービスをすべて含め、それぞれが保持する認証情報も記録します。
- クライアントが配布しているものを取り出す：最新のAndroidビルドを逆コンパイルします（
jadx -d out app.apkまたはapktool d app.apk）。iOSの場合は、復号済みのIPAに対してunzip app.ipa -d outを実行します。App StoreのビルドはFairPlayで暗号化されているため、復号するまでバイナリ内の文字列は検索できません。本番環境のJavaScriptバンドルとソースマップも同じフォルダーにダウンロードします。そのうえで、キーとトークン（grep -rEai "api[_-]?key|secret|token|bearer" out/。-aを付けると、grepはコンパイル済みバイナリ内の一致も出力します）とホスト名（grep -rEaoh "https?://[a-zA-Z0-9./_-]+" out/ | sort -u）を検索します。単一のバイナリであれば、strings -a <binary> | grep -Ei "secret|token"も使えます。 - 見つけた認証情報をスコープの範囲内ですべてテストする：OAuthクライアントごとに、テストが認可されている他のリソースサーバーやスコープに対してトークンをリクエストします（Auth0ではこのパラメーターを
audience、RFC 8707ではresourceと呼びます）。案件で許可されている範囲を超えて、やみくもに列挙しないでください。APIキーごとに、スコープ内のどのホストと環境がそのキーを受け付けるかを確認します。ハードコードされたシークレットの発見と検証に関する当社のガイドでは、漏えいしたキーで何ができるかを確認する方法を紹介しています。 - 発見したルートを仕様と比較する：クライアントやコードには現れるものの、OpenAPIやGraphQLのスキーマには存在しないルートは、シャドーAPIの候補です。意図的に文書化されていない、動的である、あるいはスコープ外である可能性もあるため、シャドーAPIとして扱う前に、稼働中であること、APIとして公開されていること、管理されていないこと、テストが認可されていることを確認してください。
- ロールとテナントを掛け合わせたアカウントマトリクスで認可をテストする：汎用ユーザー2人では不十分です。すべての操作について、テナントをまたいだ同一ロールでのアクセスと、テナント内でのロールをまたいだアクセスをテストします。
idを受け付ける作成エンドポイントも含めてください。 - HTTPだけでなく、すべてのトランスポートをテストする：それぞれに固有のチェックが必要です。WebSocketについては、接続時とすべての操作で認可をテストします。gRPCについては、メソッドレベルの認可とメタデータの処理をテストします。Webhookについては、署名、タイムスタンプ、リプレイ対策、テナントへのルーティングを検証します。OstorlabのAI Pentest EngineによるあるGraphQLの評価では、APIはHTTP上ではロールを適用していましたが、認証されていないWebSocketのサブスクリプションを受け付けていました。
- 古いバージョンとホストを確認する：
/v2/が最新の場合でも/v1/を呼び出し、クライアントで参照されているステージングホストを試します。APIバージョンの不一致がアカウント乗っ取りにつながった事例を紹介しています。 - リリースのたびに繰り返す：新しいモバイルビルドには、前回の評価では見えなかったシークレットが含まれている可能性があります。
このチェックリストを自動化したい場合：Multi-Asset Deep Agentic Scanは、抽出、認証情報、ルート、認可の各ステップを一つのスキャンで自動化します。モバイルアプリが配布しているものを取り出し、認証情報とルートを稼働中のAPIに対してテストし、再現できたチェーンを報告します。ステップ6のWebSocketのチェックは、現時点では引き続き手動です。
クロスアセット攻撃チェーンを防ぐ方法
これらの修正はアーキテクチャに関わるものです。サーバー側、またはクライアントの構築方法の中にあります。
- 特権的なシークレットをクライアントに置かない：モバイルアプリやWebバンドルに同梱したものはすべて公開されているものとして扱います。ネイティブアプリでは、PKCEを用いたAuthorization Codeフローでユーザーをサインインさせ、短期間有効なユーザーごとのトークンだけを保持するようにします。ブラウザーアプリでは、Backend for Frontend（BFF）を使ってトークンをクライアントから遠ざけられます。ハードコードされたシークレットに関する当社のガイドで、よくあるパターンを解説しています。
- マシン認証情報のスコープを厳しく限定する：各M2Mクライアントには、必要最小限のスコープで一つのAPIへのアクセスのみを付与し、他のオーディエンスに対するトークンリクエストにはアラートを出します。
- 経路だけでなく認証情報を再テストする：漏えいした認証情報を修正する際は、アプリが使用するものだけでなく、その認証情報がまだ到達できるすべてのオーディエンスとスコープを確認します。
- すべての操作でサーバー側で所有権を適用する：オブジェクトは認証済みユーザーから解決し、リクエストボディ内の
idだけで決して解決しないでください。作成時には、サーバーが所有する既存オブジェクトの識別子を拒否し（または挿入専用のセマンティクスを適用し）、所有権を確認します。新しいオブジェクトに対してクライアントが生成するUUIDは問題ない場合があります。 - トランスポートをまたいで一つの認可ポリシーを使う：WebSocketやgRPCは必ずしもHTTPのミドルウェアを再利用できないため、ポリシーを一元的に定義し、接続、各操作やリゾルバー、各メッセージやイベント、gRPCのインターセプターといった各境界で適用します。
- インベントリをセキュリティ制御として扱う：古いバージョンやステージングホストを廃止し、仕様をクライアントが実際に呼び出すものと同期させておきます。
よくある質問（FAQ）
APIセキュリティにおけるクロスアセット攻撃チェーンとは何ですか
クロスアセット攻撃チェーンは、モバイルアプリ、Webフロントエンド、ソースコード、バックエンドAPIなど、複数のアセットにある弱点を組み合わせたものです。典型的なチェーンでは、クライアントから認証情報やルートを取り出し、それを正当なAPIリクエストとして再送し、BOLAやBFLAなどの認可の欠陥を突いて権限を昇格させます。
APIスキャナーがモバイルアプリにハードコードされたシークレットを検出できないのはなぜですか
APIスキャナーは、与えられた認証情報と仕様を使って稼働中のバックエンドをテストします。モバイルバイナリを逆コンパイルしないため、アプリにコンパイルされたシークレットを目にすることはなく、それらのシークレットをAPIに対してテストする理由もありません。
ASPMとマルチアセットスキャンの違いは何ですか
ASPMプラットフォームは、各スキャンが完了した後に、個別のスキャナーからの検出結果を一つのダッシュボードに集約します。マルチアセットスキャンは、スキャン中の相関付けを行います。モバイルバイナリ内のトークンなど、あるアセットでの発見を同じスキャンの中で使用してバックエンドAPIに対するライブテストを実行し、再現できたチェーンだけを報告します。
クライアントやコードのコンテキストがあると見つけやすくなるOWASP API Top 10のリスクはどれですか
OWASP API Top 10のリスクはすべてサーバー側で修正されるものですが、オブジェクトレベルの認可の不備（API1）、認証の不備（API2）、オブジェクトプロパティレベルの認可の不備（API3）、機能レベルの認可の不備（API5）、セキュリティ設定ミス（API8）、不適切なインベントリ管理（API9）は、モバイルアプリ、Webバンドル、ソースコードから取得した認証情報、ルート、リクエスト形式があると、発見や検証が容易になることがよくあります。
モバイルアプリのバックエンドAPIでBOLAをテストするにはどうすればよいですか
アプリを逆コンパイルして、エンドポイント、識別子の形式、リクエストの署名や暗号化の有無を把握します。次に、一つのアカウントでオブジェクトを作成し、アプリの正確なリクエスト形式を再現しながら、2つ目のアカウントでそれらを読み取り、変更し、削除します。オブジェクトIDを受け付ける作成エンドポイントについても同様に繰り返します。
漏えいしたモバイルAPIキーはローテーションするだけで十分ですか
キーによって異なります。モバイルAPIキーの中には、公開されることを前提に設計され、アプリ、プラットフォーム、クォータによって制限されているものもあり、その場合は露出しただけでは侵害にはなりません。漏えいしたのが特権的なシークレットであれば、ローテーションだけでは不十分です。次のビルドでも新しいシークレットが同じ方法で配布されてしまうからです。失効させてローテーションしたうえで、クライアントから削除し、バックエンドサービスから短期間有効なユーザーごとのトークンを発行してください。
当社がマルチアセットテストを構築した理由
当社は、チームがコード、モバイルアプリ、APIに対して別々のスキャナーを実行し、その結果を手作業で突き合わせている一方で、重要なチェーンがクライアントバイナリから取り出された認証情報を経由して進んでいる状況を何度も目にしてきました。
そこで当社はMulti-Asset Deep Agentic Scanを構築しました。クライアントバイナリで見つかったトークンを稼働中のバックエンドに対するライブテストへとつなげ、再現できたチェーンだけを報告する、一つのループです。
APIテストツールをより幅広く比較したい場合は、2026年版APIセキュリティテストツールの比較をご覧ください。マルチアセットスキャンが自社のモバイルアプリやAPIで何を見つけるかを確かめるには、当社のセキュリティエンジニアリングチームによるデモをご予約ください。