認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説

ログインは正しく通っているのに、URLの数字を1つ変えただけで他人の注文書が開いてしまう。認可バイパス（Authorization Bypass）は認証を破られた状態ではなく、認証済みの利用者に対する「この資源を触ってよいか」の判定が抜けている、あるいは誤っている欠陥を指します。OWASP Top 10:2025では A01:2025 – Broken Access Control が最上位に置かれました。本記事では、水平方向のIDORと垂直方向の権限昇格が成立する条件、判定をデータアクセス層へ寄せる実装設計、SASTやDASTが原理的に取りこぼす理由と2アカウント差分テストの組み方を整理します。

まとめ：認可バイパス対策の結論と着手の優先順位

結論を先に置きます。認可バイパスを止める本命は、資源へ触れる直前で「セッションから取り出した主体」と「その資源の所有者・権限」を毎リクエスト照合し、照合できない要求を既定で拒否する設計です。画面にボタンを出さない、識別子を推測しにくくする、経路を公開しない。この3つは判定ではなく隠蔽であり、リクエストを直接組み立てられた時点で無力になります。

実装の型は2つです。リクエスト値を主体の決定に使わないこと、所有者条件をクエリ側へ埋め込みコントローラの分岐に頼らないこと。着手順は、主体×資源×操作の権限行列を書き起こす、判定をデータアクセス層へ集約する、2アカウントで同一エンドポイントを叩く差分テストをCIへ載せる、の3段になります。

逆に、単独では対策にならない手が3つあります。WAFのシグネチャ任せ、識別子のUUID化だけ、手動の画面確認だけで完了とみなす運用でした。理由は独自章で条件つきに整理します。

認可バイパスの定義と認証バイパスとの境界線・CWE分類での位置づけ

言葉の範囲を先に固めます。認可バイパスは単一の攻撃手法ではなく、判定の欠落と誤りをまとめた脆弱性クラスです。

認可バイパスが成立する3つの条件と攻撃者に渡る操作範囲の具体例

成立するのは3条件がそろったときです。第一に、資源が識別子や経路で指定できること。第二に、その識別子を利用者側が書き換えられること。第三に、サーバ側が「その主体がその資源を触ってよいか」を確かめずに処理を進めること。3つ目が欠けていなければ、前の2つがそろっても被害は出ません。

渡るのは閲覧権限だけではない。注文詳細エンドポイントで注文番号を1つずらせるなら、参照に加えてキャンセルや配送先変更まで届きます。管理画面の利用者一覧が一般権限で開くなら、権限の付け替えという次の足場が手に入る。認可の欠落は、情報漏えいと改ざんを同時に招きます。

認証バイパスとの違いと、両者が同時に発生する場面の切り分け方

認証バイパスは「誰であるか」の確認をすり抜ける欠陥、認可バイパスは「何をしてよいか」の確認をすり抜ける欠陥です。OWASP Top 10:2025でも Broken Access Control（A01）と Authentication Failures（A07）は別カテゴリでした。

両者が同時に起きる典型は、トークン検証が甘い実装です。JWTの署名検証を省いていると、ペイロードのロール要求を書き換えるだけで認証と認可を1回のリクエストで破れます。トークンの発行と検証の全体像はOAuth 2.0の認可フローと認証・認可の違いを先に押さえると切り分けやすい。判別は単純で、未ログインで再現するなら認証側、ログイン済みの一般利用者で再現するなら認可側です。

CWE-285・862・863・639の関係とIDOR・BOLAとの対応

CWEでは Class レベルの CWE-285「Improper Authorization」が頂点にあり、その下に CWE-862「Missing Authorization」と CWE-863「Incorrect Authorization」が並びます。CWE-863 の子が Base レベルの CWE-639 で、Insecure Direct Object Reference（IDOR）や Broken Object Level Authorization（BOLA）を別名に持ちます。

この分類は診断報告の読み方にも効きます。チェックが無いなら CWE-862、あるが比較対象を間違えているなら CWE-863、識別子を差し替えられるなら CWE-639。番号を見れば、修正が「追加」か「訂正」かを判断できます。

水平・垂直の2方向で整理する認可バイパスの代表的な攻撃パターン

攻撃面は方向で整理すると漏れません。同じ権限で横に移る動きと、上位権限へ縦に上がる動きでは、必要な検査も違います。

IDの書き換えによる水平方向の越境アクセスとUUID採用の限界

もっとも数が多いのがこの形です。GETのパスパラメータやPOSTの隠しフィールドに含まれるorder_idを1つずらすだけで他人のデータが返る。連番の整数なら総当たりの手間すら不要で、1万件の走査が数分で終わります。

識別子をUUIDへ変えれば推測は難しくなりますが、欠陥は残ります。UUIDは共有URL、メール本文、ブラウザ履歴、アクセスログ、外部サービスへのリファラから漏れる。一度漏れた値で無制限に参照できる状態は CWE-639 の定義そのままでした。UUID化は総当たりの成功率を下げる緩和策であって、所有者照合の代わりにはなりません。

隠しURLへの直接アクセスで起きる垂直方向の権限昇格の具体例

縦方向は、上位権限の機能へ一般利用者が直接到達する形です。管理者メニューを画面から隠しているだけなら、管理用のパスへ直接リクエストして処理が通る。強制ブラウズ（forced browsing）と呼ばれ、経路の推測はJavaScriptバンドルやAPIドキュメントから容易に進みます。

入口はURLに限りません。GraphQLの単一エンドポイントでは、フィールド単位の判定が抜けていると同じクエリの中で管理者専用フィールドだけが露出する。バッチやWebhookの受け口も同種で、内部からしか呼ばれない前提で認可を省いた処理は、経路の変更後に外部から到達可能になります。呼び出し元ではなく主体で判定する形にしておけば、前提が変わっても壊れません。

マスアサインメントで書き換わる権限フィールドとAPI3の関係

リクエストのJSONをそのままモデルへ流し込む実装では、想定していないプロパティまで更新されます。プロフィール更新のAPIにroleを混ぜて送れば、そのまま権限が書き換わる。OWASP API Security Top 10 2023では、この欠陥が API3:2023 – Broken Object Property Level Authorization として、旧版の Excessive Data Exposure と Mass Assignment を統合する形で整理されました。

対処は、更新してよいプロパティを型として宣言する許可リスト方式です。API境界の欠陥の全体像はOWASP API Top 10の主要リスクと実装対策にまとめました。

マルチテナントSaaSでテナント境界を越える参照が起きる経路

テナントIDを検索条件へ足し忘れた1本のクエリで、境界は崩れます。危ないのは正面の一覧APIではなく、後から足された検索・集計・エクスポート・通知といった周辺機能でした。主要導線が入念にレビューされる一方、周辺機能は既存のリポジトリメソッドを再利用して素通りします。

実際の事案でも、認証は通っているのに参照範囲の判定が抜けていた例が報告されています。生命保険契約照会システムの事案の内訳は認可制御不備がどう情報漏えいへつながったかで整理しました。境界はアプリ層の条件式より、データベースの行レベルセキュリティやテナント条件を強制する基底クラスで担保するほうが機能追加に耐えます。

認可チェックが抜ける構造的な原因とコードレビューで見つかる兆候

個々の実装ミスより、抜けが起きやすい構造を先に潰します。原因が構造にあるなら、1箇所を直しても同じ欠陥が再生産されるからです。

画面の出し分けとサーバ側の認可判定を取り違える実装設計の誤り

フロントエンドで権限に応じてボタンを出し分ける処理は、利用者体験の調整であって防御ではありません。SPAでは判定ロジックがバンドルに含まれ、条件式そのものが読まれます。disabledを外す、あるいはHTTPクライアントで直接叩けば、画面の制御は素通りする。

この取り違えは仕様書の書き方に起因することが多い。「管理者のみ表示」とだけ書かれた要件は画面仕様として実装され、サーバ側の受け入れ条件が定義されないまま完了します。要件定義の段階で「表示制御」と「実行拒否」を別項目に書き分けておくと、実装とテストの両方で拾えます。

コントローラごとに散らばった認可チェックが抜け漏れを生む構造

各コントローラの先頭に権限判定を書く方式は、エンドポイントが増えるほど破綻します。100本に対して100箇所の判定が必要になり、1箇所の書き忘れが即座に欠陥になる。しかも書き忘れは静的解析にとって存在しないコードであり、検出できません。

設計を逆転させます。共通のミドルウェアや基底クラスで全リクエストを既定拒否にし、明示的に許可を宣言したエンドポイントだけを通す。宣言の無いエンドポイントは403で落ちるため、書き忘れがテスト時点で必ず表面化します。

コードレビューで拾える危険な記述パターンと確認すべき3つの観点

レビューでは、書かれている行より「書かれていない行」を探します。全文検索で拾えるパターンを先に列挙しておくと、確認が機械的に進みます。

• リクエスト値から取得した利用者IDを、そのまま検索条件や更新対象に使っている箇所
• 主キーだけを条件にした取得メソッド（所有者やテナントの条件が付いていない）
• リクエストボディをモデルへ一括代入している箇所
• 権限判定がコメントアウトされている、または開発用フラグで無効化できる箇所

観点は3つに絞れます。主体をどこから取ったか、資源の所有者と照合したか、拒否がテストで確認されているか。3つ目が最も抜けやすく、正常系のテストしか無いエンドポイントは実質的に認可が未検証です。

アクセス拒否を既定にする認可設計と許可リスト方式へ寄せる実装手順

ここからは直し方です。判定を書き足す作業ではなく、判定を集める作業として進めます。

アクセス拒否を既定にする認可設計と許可リスト方式へ寄せる手順

既定拒否（deny by default）の実装は、順序を守ると短時間で入ります。

1. 主体（ロール・所属テナント・利用者ID）と資源と操作の3軸で権限行列を作る
2. 全エンドポイントを既定拒否にし、行列に載った組み合わせだけ許可を宣言する
3. 宣言の無いエンドポイントを一覧化し、意図的な公開か書き忘れかを1本ずつ判定する
4. 公開エンドポイントには公開である旨を宣言し、レビュー対象として残す

権限のモデルは、ロールで足りるか属性まで要るかで分かれます。組織階層や取引先ごとの可視範囲が絡むとロールだけでは表現しきれません。判断材料はロールベースアクセス制御の仕組みと導入判断に整理しています。

所有者チェックをデータアクセス層へ集約するスコープ付きクエリ

コントローラで「取得してから所有者を比較する」書き方は、比較の書き忘れが即座に漏えいへつながります。取得の時点で所有者条件を含める形へ変えれば、書き忘れは「0件が返る」という安全側の失敗になる。同じ1行の違いでも、失敗したときの向きが逆になります。

手堅いのは、リポジトリのメソッドシグネチャを主体込みにすることです。主キーだけを受け取るメソッドを基底クラスから消し、主体と主キーを同時に要求すれば、呼び出し側は所有者条件を省けません。

セッションから主体を取り出す実装とリクエスト値を信じない原則

主体の決定にリクエスト値を使わない。この1点が守れていれば、水平方向の越境は大半が止まります。IPAの「安全なウェブサイトの作り方」1.11も、根本的解決として利用者IDをセッション変数から取得し、要求されたキーが本人のものかを照合する方式を示しました。

境界を跨ぐ場面では注意が要ります。バックグラウンドジョブや管理バッチはセッションを持たないため、主体を引数として明示的に渡す設計になる。ジョブ投入時に主体を記録し、実行時に再検証する形が安全です。セッションIDの発行から失効までの扱いはセッション管理の実装と保存先選定で扱っています。

認可バイパスの検出手段の使い分けとテスト自動化の具体的な組み方

認可バイパスは、既存のセキュリティツールがもっとも苦手とする欠陥です。理由を理解したうえで、人と自動テストの分担を決めます。

SASTとDASTが認可バイパスを取りこぼす原理的な2つの理由

SASTが弱いのは、認可の正解が仕様側にあるからです。「この画面は経理部だけが見てよい」という条件はコードから導けず、静的解析は「判定が書かれていない」ことを欠陥と判断できません。危険な関数呼び出しを探す方式とは性質が違います。

DASTも同じ壁に当たります。単一のセッションでクロールする方式では、返ってきた200が「見てよいものを見た」のか「見てはいけないものを見た」のか判別できない。DASTの守備範囲と限界はDASTの仕組みとCI・CDへの組み込みに整理しました。検出には、複数の主体を用意して結果を比較する仕組みが要ります。

2アカウント差分テストで認可の抜けをCIから機械検証する手順

自動化の型は、同じリクエストを別の主体で投げて、返るステータスの差を見る方式です。

1. テナントAの一般利用者、テナントBの一般利用者、管理者の3アカウントを固定データとして用意する
2. テナントAの資源に対する全エンドポイントのリクエストを記録し、テストケースの雛形にする
3. 同じリクエストをテナントBの認証情報で再送し、403または404が返ることを検証する
4. 管理者専用エンドポイントを一般利用者の認証情報で再送し、拒否されることを検証する
5. 新規エンドポイントがこの雛形に含まれない場合、CIを失敗させる

5番目が効きます。ルーティング定義からエンドポイント一覧を機械的に取得し、テスト対象に含まれないものを検出すれば、機能追加時の検証漏れが構造的に止まります。

外部の脆弱性診断に依頼する対象範囲の決め方と再診断までの流れ

認可の欠陥は、業務仕様を理解した人が権限行列を持って手を動かさないと見つかりません。外部へ依頼するときも、画面一覧だけでなく権限行列とテスト用アカウントを渡せるかどうかで検出範囲が変わる。アカウントを1つしか渡さない依頼では、水平方向の検査そのものが実施できません。

範囲は、権限が絡む機能と外部から到達できるAPIを優先します。報告を受けた後は修正で終わりにせず、再診断まで含めた契約にしておくと、修正が別経路を塞ぎ残していないかを確認できる。範囲の切り方と再診断までの進め方は脆弱性診断・セキュリティ診断でも相談を受け付けています。

認可バイパス対策として採用しない設計と受託開発で見送るべき場面

ここは判断を言い切ります。相談の場で採らないと決めている選択肢と、その条件です。

WAFのシグネチャ任せを採用しない理由と例外的に許容する条件

WAFを認可バイパスの対策として数えることは採用しません。SQLインジェクションやXSSと違い、認可バイパスの攻撃リクエストは文法的に正常だからです。id=1002とid=1003の差を、アプリの権限情報を持たないWAFが判別する手段がない。止まらないのは実装の巧拙ではなく、判定に必要な情報がその層に無いという構造の問題でした。

例外は2つだけです。既知のCVEにパッチが当たるまでの、期限を切った仮想パッチ。もうひとつは管理画面へのIP制限のような経路そのものの遮断。どちらも攻撃の検知ではなく、到達範囲を狭める用途に限ります。

権限行列を作らないまま実装へ入る進め方を採らない理由と代替案

権限行列が無いまま実装へ入る進め方も採りません。正解が定義されていない以上、レビューもテストも「それらしいか」の主観判断になり、抜けを指摘する根拠が作れないからです。工数を理由に省略されがちですが、行列の作成はエンドポイント100本規模でも1〜2日で終わります。

代案は、画面設計と同時に主体×資源×操作の表を埋め、その表をそのままテストケースの入力にすることです。表の1セルが1テストになるため、作成コストは後段のテスト設計から回収できる。要件段階で権限の抜けを洗い出す進め方はSTRIDEでの脅威抽出手順とも噛み合います。

受託開発で独自の認可基盤を作らず既製品へ寄せるべき条件の整理

認可基盤の自作は、条件付きで見送ります。見送るのは、権限モデルがロールと所属組織で表現でき、外部IdPとの連携が前提で、運用側に権限設計を継続できる体制が無い案件です。この条件に当てはまるなら、IdPやフレームワーク標準の権限機構へ寄せ、アプリ側は所有者照合とスコープ付きクエリだけを担います。

逆に自作へ踏み込むのは、資源の属性や時間帯、承認状態で可否が変わるなど、宣言的なロール表現では表しきれない要件があるときです。その場合もポリシー判定を独立したモジュールへ切り出し、業務ロジックと混ぜない。判定と実行を混ぜた実装は、後からテストを書けなくなります。

よくある質問

認可バイパスの調査と修正でよく受ける質問をまとめました。

認可バイパスとIDORは同じ意味ですか？

IDORは認可バイパスの一形態です。CWEでは CWE-639「Authorization Bypass Through User-Controlled Key」の別名として IDOR と BOLA が挙げられており、利用者が操作できるキーを経由して他人の資源へ到達する型を指します。一方、管理者機能へ一般利用者が直接到達する垂直方向の権限昇格はIDORに含まれません。認可バイパスのほうが広く、IDORはその中の水平方向の代表例という関係になります。

認可バイパスはOWASP Top 10のどこに該当しますか？

OWASP Top 10:2025では A01:2025 – Broken Access Control に該当します。2025年版は第8版にあたり、13組織から提供された280万件超のアプリケーションのデータをもとに589件のCWEを分析し、248件を10カテゴリへ配分した構成でした。APIを対象とする場合は OWASP API Security Top 10 2023 のほうが解像度が高く、API1:2023 BOLA、API3:2023 BOPLA、API5:2023 Broken Function Level Authorization が対応します。

UUIDを使えば認可バイパスは防げますか？

防げません。UUIDは推測を難しくするだけで、値が漏れた後の参照を止める仕組みを持たないためです。共有URL、メール本文、ブラウザ履歴、外部サービスへのリファラなど、識別子が外へ出る経路は多数あります。CWE-639が問題にしているのは「利用者が操作できるキーで認可を回避できること」であり、キーの推測困難さではありません。所有者照合を入れたうえで、総当たりの抑止としてUUIDを併用する順序になります。

既存システムで直す優先順位はどう決めればよいですか？

3つの軸で並べます。第一に操作の種別で、参照よりも更新・削除を先に扱う。改ざんは復旧コストが大きく、発生の検知も遅れるためです。第二に到達性で、外部公開されているエンドポイントを内部限定より優先します。第三に扱うデータの性質で、個人情報や決済情報を返す経路を上位に置く。恒久対応が間に合わない範囲には、レート制限や識別子の不透明化を期限つきの緩和策として当てます。

認可の抜けを自動テストで検出することはできますか？

できます。同じリクエストを別の主体で再送し、403または404が返ることを検証する差分テストが基本形です。テナントAの利用者、テナントBの利用者、管理者の3アカウントを固定データとして用意し、正常系テストで記録したリクエストを再利用すると作成コストを抑えられます。さらにルーティング定義からエンドポイント一覧を取得し、差分テストに含まれないエンドポイントがあればCIを失敗させる仕組みを足すと、機能追加時の検証漏れが止まります。

関連記事

• セッション管理とは？セッションIDの発行から失効までの実装と保存先選定を解説：主体をどこから取り出すかを決める、認可判定の前段にあたる工程です。
• DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説：認可の検出に自動診断をどこまで使えるかの線引きに使えます。
• ディレクトリトラバーサルとは？攻撃の仕組みと正規化後検証による実装対策を解説：ファイル経路を利用者が操作できる場合に起きる、隣接した欠陥です。
• 入力バリデーションとは？防げる攻撃の範囲と許可リスト設計を実装目線で解説：入力検査だけでは認可の欠落を防げない理由を範囲の面から整理しています。
• 脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説：権限行列を設計段階で書き起こす進め方と組み合わせられます。