ログインした後、注文番号を変えるだけで他人の注文情報が見えてしまう。
これは、本人確認が正常でも、対象データへの権限確認が不十分であれば起こり得る問題です。

IDORとBOLAは、こうした認可不備を説明する用語です。

この記事では、WebアプリケーションやAPIの開発・レビューに関わる方に向けて、IDORとBOLAの違い、具体例、対策、確認方法を解説します。
さらに、認可不備の発見になぜコードの文脈が必要なのか、AI推論型AppSecをどう活用できるのかを考えます。

注文番号を変えるだけで 他人の注文が見える例

一般ユーザーは自分の注文だけを閲覧できる、架空のオンラインショップがあるとします。
AさんとBさんは正規の会員（一般ユーザー）で、それぞれ次の注文を行っています。

注文者	注文番号	注文金額
Aさん	1001	5,000円
Bさん	1002	30,000円

Aさんが自分の注文詳細を開くと、画面から次のリクエストが送られます。
注文番号: 1001を指定し、その注文の詳細を取得するAPIです。
GET /api/orders/1001

Aさんのログイン状態のまま、注文番号をBさんの1002に変更すると、どうなるでしょうか。
GET /api/orders/1002

サーバーが「ログイン済み」「注文が存在する」ことだけを確認していると、Bさんの注文内容や配送先まで返してしまう可能性があります。
本来は、Aさんに閲覧権限がないことを確認し、情報を返さなければなりません。

不足しているのは、「この利用者は、この注文を見てよいか」という確認です。
注文の変更やキャンセルについても、それぞれの操作に対する権限を確認する必要があります。

IDORとBOLAの違いと共通点

IDOR (Insecure Direct Object Reference)は、「安全でない直接オブジェクト参照」と訳されます。
URLやリクエスト本文などの識別子を操作することで、権限のないデータを参照・操作できてしまう脆弱性です。

BOLA (Broken Object Level Authorization)は、「オブジェクトレベル認可の不備」と訳されます。
ここでのオブジェクトとは、注文情報や顧客情報など、アプリケーションが扱う個々のデータを指します。

BOLAは、利用者がそのデータを参照・操作する権限を適切に確認していない問題です。
OWASP API Security Top 10 2023では、API1として取り上げられています。

比較項目	IDOR	BOLA
ポイント	識別子の操作による権限のない参照や操作	個々のデータに対する認可の不備
注文APIでの該当箇所	注文番号を変えると他人の注文が見える	他人の注文に対する閲覧権限を確認していない

本記事の注文番号を書き換える例は、IDORともBOLAいずれも当てはまります。
IDORは識別子を操作した不正な参照・操作に着目し、BOLAは対象データへの認可の不備に着目した呼び方です。

認証やUUIDだけでは なぜ認可不備を防げないのか

認証が確認するのは「誰が利用しているか」です。
正規の会員でも、すべての注文を見る権限があるとは限りません。
また、推測しにくいUUIDなどを使っても、その識別子が分かった利用者に権限のない情報を返してよいわけではありません。

対策の基本は、サーバー側で信頼できる認証情報から利用者を特定し、対象データと操作に対する権限をリクエストごとに確認することです。
画面のボタンを隠すだけでは、APIへの直接アクセスを制御できません。
許可を確認できない場合は拒否します。

今回のショップなら、利用者が閲覧できる範囲に絞って注文を取得する方法が考えられます。
ただし、共有や代理購入、サポート担当者による参照がある場合は、そのルールも必要です。

以下はこのショップを組織ごとに利用するシステムへ拡張した場合の権限テストの例です。

利用者	対象と操作	期待する結果
Aさん	自分の注文1001を閲覧	許可
	同じ組織のBさんの注文1002を閲覧	拒否
	別組織の利用者の注文を閲覧	拒否
	Bさんの注文の配送先を変更	拒否
担当権限のあるサポート担当者	担当範囲内の注文を閲覧	許可
未ログイン	会員専用の注文情報を閲覧	拒否

「自分の情報を取得できる」ことに加え、「権限のない情報を取得・変更できない」ことを確認します。
閲覧用APIが安全でも、変更、削除、エクスポートなど別の処理で確認が抜けていないかの確認も重要です。

認可不備の発見には 処理のつながりを見る

注文取得の関数が正常に動いていても、権限確認が成立しているとは限りません。
APIの入口、サービス層、共通処理などを追い、データを返したり変更したりする前に、必要な認可を必ず経由するかを確認します。

例えば、APIの入口ではログイン済みであることだけを確認し、サービス層で注文を取得し、共通処理で閲覧権限を確認する設計もあります。

認可チェックの有無だけで判断すると、問題を見逃す場合も安全な処理を誤って疑う場合もあります。
次の表は、本記事の注文APIを使って、レビューで区別したい三つの状態を整理したものです。

コードの状態	処理全体で確認すること	この条件で判断すると
ログイン確認後に注文を取得	他の処理にも対象の注文への権限確認がない	認可不備
注文取得関数には認可がない	返却前に必ず共通処理で対象の注文への認可を行う	認可は成立
認可関数は存在する	一部のAPIは認可を経由せず他人の注文を返す	認可不備

取得関数だけを見れば、共通処理での認可を見落とす可能性があります。
反対に、認可関数の存在だけでは、迂回する経路を見逃します。
重要なのは、必要な処理経路で、対象データと操作に対する権限確認が成立しているかです。

AI推論型AppSecで 認可不備の発見を支援する

本記事で取り上げるAI推論型AppSec（アプリケーションセキュリティ）は、LLMなどのAIを用いて関連するコードや設定の文脈を読み解き、セキュリティ上の問題の候補と根拠を推論するアプローチです。

注文APIを例にすると、利用者の特定、注文との関係、権限確認の処理、データを返す経路を関連付け、認可を迂回できる可能性を調べるレビューを支援します。
指摘の説明や修正案の作成に加えて、問題の候補そのものを探す段階への活用が焦点になります。

関連する取り組みとして、生成AIを用いてAPIテストを自動化し、BOLAを発見した公開研究も報告されています。この研究は、動作中のAPIへのテストを含むもので、ソースコード解析とは異なる方法で認可不備の発見を支援しています。
※本記事の注文APIは説明用の例であり、特定の製品やAIが実際に検出した結果を示すものではありません。

AI推論型AppSecは、既存の静的解析や人によるコードレビューと組み合わせ、アプリケーション固有の関係や権限ルールを踏まえた評価を支援します。
AIの指摘を確認する際には、検出したかどうかだけでなく、次の根拠を確認すると、修正や追加検証につなげやすくなります。

確認する観点	指摘に求めたい説明
利用者と対象	誰が・どの注文にアクセスできてしまうのか
注文取得関数には認可がない	返却前に必ず共通処理で対象の注文への認可を行う
成立する経路	どのAPIや呼び出し経路で権限確認が抜けるのか
実装されている防御	共通処理などの認可を見落としていないか
業務ルール	どの許可や拒否の条件に反するのか
確認方法	どの利用者とデータで挙動を確かめればよいか

業務ルールを自然言語で伝え 解析の文脈を補う

AI推論型AppSecを活用する際は、ソースコードに加えて、業務上の権限ルールを解析の文脈として伝えることも有効です。

例えば、「一般ユーザーは自分の注文だけを閲覧できる」「サポート担当者は担当範囲の注文だけを参照できる」といったルールです。

AGENTS.mdなどにルールを整理し、対応するAIエージェントと共有する方法があります。解析時には、対応するツールのカスタムコードポリシーとして確認事項を定義できます。ファイルの参照やポリシーの適用範囲は、ツールの対応・設定に合わせて確認します。

AIが読み取る情報に、人が明示した業務ルールを組み合わせる。そのうえで指摘された経路をレビューし、実際のアクセス検証へつなげることが、解析を改善に生かすポイントです。
指摘がない場合も、権限外の操作が拒否されるかを確認します。

認可不備への理解を AI推論型AppSecの活用につなげる

IDORとBOLAに共通する問題は、「データを指定できること」を「そのデータにアクセスしてよいこと」として扱ってしまう点です。
サーバー側で対象データと操作に対する認可を行い、そのルールがすべての経路で守られているかを確認する必要があります。

AI推論型AppSecは、関連コードの文脈を読み解き、その確認を支援するアプローチです。認可不備の理解から、権限設計、コードレビュー、アクセス検証までをつなげることで、解析結果を具体的な改善に生かせます。

東陽テクニカでは、AI推論型AppSecの考え方や活用方法について情報を発信しています。
「自社の認可不備をどう確認すればよいか」「既存のSASTやコードレビューとどう組み合わせるか」といった検討について、お気軽にご相談ください。