権限・ロールのテスト観点｜情報漏洩を防ぐ確認項目

2026 9/01

2026年9月1日

「ログインできること」はテストしたのに、「ログインした後に何ができてしまうか」までは十分に確認できていない。受託開発の現場では、この抜けが重大なインシデントの入口になります。

権限まわりのバグは、他人のデータ閲覧・改ざん、情報漏洩、管理者機能の乗っ取りへ直結します。しかも画面上は正常に見えるため、通常の機能テストではすり抜けやすいのが厄介な点です。

本記事では、権限・ロールのテスト観点を体系的に整理し、情報漏洩を防ぐための確認項目を具体的なチェックリストまで落とし込みます。水平権限・垂直権限・API経由の回避・権限失効の反映といった「落としてはいけない観点」を、PMがチームやクライアントに説明できる粒度でまとめました。

権限バグは、発覚すればクライアントの信頼を一度で失いかねない最もリスクの高い欠陥の一つです。だからこそ、テスト計画の段階で観点を明文化しておく価値があります。

認証と認可の違い｜権限・ロールのテスト観点が抜けやすい理由

この観点を語る前に、まず「認証」と「認可」を分けて考える必要があります。この2つを混同したまま進めると、テスト範囲がまるごと抜け落ちます。

認証（Authentication）: あなたが誰であるかを確認する仕組み。ログイン、会員登録、パスワード、多要素認証などが該当します
認可（Authorization）: ログインした「その人」が、何を見て・何を操作してよいかを制御する仕組み。ロールや権限がこれにあたります

OWASPのガイドでも、認可は「要求された操作やサービスが特定の対象に許可されているかを検証するプロセス」と定義され、認証とは別物として扱われています（OWASP Authorization Cheat Sheet）。

テストで抜けやすいのは、認証（ログインできるか）ばかり確認して、認可（ログイン後に何ができるか）の検証が手薄になるパターンです。

観点	認証のテスト	認可（権限）のテスト
問い	正しい本人がログインできるか	ログイン後に許可された範囲だけ操作できるか
代表的な不具合	ログイン失敗、パスワード漏れ	他人のデータ閲覧、管理者機能の悪用
見た目	エラー画面が出るので気づきやすい	正常に見えるので気づきにくい
主な確認手段	画面操作	画面＋API＋URL・パラメータ改ざん

なぜ認可のテストは抜けやすいのでしょうか。理由は、正常系の画面操作では「自分の権限で自分のデータ」しか触らないため、権限を越えた操作を意図的に試さない限り問題が表面化しないからです。

会員登録やログインそのものの確認項目は、会員登録・ログインの確認項目を整理した認証機能のテスト観点で別途まとめています。本記事は、その先にある「認可」に振り切って解説します。

権限バグが情報漏洩・特権昇格に直結する仕組み

権限バグが軽視できないのは、被害が「機能が動かない」では済まないからです。データそのものが漏れ、書き換えられ、最悪は乗っ取られます。

代表的な権限バグを、被害の大きさとともに整理します。

権限バグの種類	何が起きるか	想定される被害
水平権限の侵害（IDOR）	他ユーザー・他社のデータにアクセスできる	個人情報・機密情報の漏洩
垂直権限の侵害（特権昇格）	一般ユーザーが管理者機能を実行できる	全データの改ざん・削除、乗っ取り
権限失効の未反映	退職者や剥奪済みユーザーが操作を続けられる	不正アクセス、内部不正
データ範囲のフィルタ漏れ	自組織以外のデータが一覧に混ざる	テナント間の情報混在

IDOR（Insecure Direct Object References） とは、URLやパラメータに含まれるID（例: /orders/1002）を書き換えるだけで、本来アクセスできないデータを直接参照できてしまう脆弱性です。ログイン済みの正規ユーザーが、他人のIDに差し替えるだけで成立してしまう点が危険です。

特権昇格（Privilege Escalation） は、一般ユーザーが本来持たない上位権限の操作を実行できてしまう状態を指します。管理者用のAPIや管理画面のURLを直接叩いてしまえるケースが典型です。

権限バグは、悪意ある第三者だけでなく、普通のユーザーが偶然たどり着いてしまうことでも発覚します。URLを一つ書き換えただけで他社の受注データが見えた、という事象は珍しくありません。

こうしたインシデントは、本番で起きてしまうと初動対応と再発防止に多大なコストがかかります。権限バグは「起きてから」の対応コストが特に大きい領域です。

見落としがちなのは、権限バグが「機能不具合」よりもはるかに大きなコストを生む点です。通常の不具合なら修正して再リリースすれば済みますが、権限バグによる情報漏洩は、漏れたデータそのものを取り戻せません。クライアントへの報告、影響範囲の調査、場合によっては公表や監督官庁への対応まで発生します。

「一つのURL書き換えで他社データが見えた」という事象は、技術的には小さなミスでも、事業上は最大級のインシデントになり得ます。上長やクライアントに費用対効果を説明する際も、この非対称なリスクは強い根拠になります。

IPAの資料でも、認可制御の不備は代表的なウェブサイトの脆弱性として繰り返し指摘されています（安全なウェブサイトの作り方（IPA））。設計・実装の段階から作り込みつつ、テストで確実に検出する二段構えが必要です。

ロール設計を可視化する｜ロール×機能×操作のマトリクス

権限のテストで最初にやるべきは、テストケースをいきなり書くことではありません。「誰が」「何に対して」「何をできるべきか」を一枚の表に可視化することです。

この整理をせずにテストを始めると、「管理者ならできて当然」「一般ユーザーはできないはず」という暗黙の前提だけでテストが進み、境界のケースが漏れます。

ロール×機能×操作のマトリクスは、行にロール、列に機能×操作（参照・作成・更新・削除など）を並べ、各セルに「許可／禁止」を明記した表です。デシジョンテーブルの考え方に近く、条件の組み合わせを網羅的に整理できます。Lee Copeland『はじめて学ぶソフトウェアのテスト技法』でも、複雑な条件分岐は表形式で整理することで抜け漏れを防げると解説されています。

以下は簡易なマトリクスの例です。

ロール＼操作	自分の受注参照	他人の受注参照	受注の削除	ユーザー管理	監査ログ閲覧
一般ユーザー	○	×	×	×	×
部門管理者	○	○（自部門のみ）	○（自部門のみ）	×	×
システム管理者	○	○	○	○	○
退職・失効ユーザー	×	×	×	×	×

このマトリクスの「×」のセルこそ、テストで実際に操作を試して禁止されることを確認すべき対象です。「○」だけを確認して満足すると、権限バグの大半を見逃します。

マトリクス作成の手順は次のとおりです。

システムに存在する全ロールを洗い出す（隠れた内部ロールも含める）
保護すべき機能・データ操作を列として列挙する
各セルに「許可／禁止」を仕様として明記する（空欄を残さない）
「禁止」セルを優先的にテスト対象として抽出する
ロール横断で矛盾がないか（下位ロールが上位を上回っていないか）を確認する

受託開発では、要件定義書に「管理者」「一般ユーザー」といった大枠のロールしか書かれていないことがよくあります。しかし実装段階では、部門管理者・閲覧専用・承認者・外部協力会社など、細かいロールが追加されているケースが少なくありません。

仕様書に載っているロールと、実装されているロールが食い違っていないか。マトリクス作成は、この「隠れロール」を洗い出す機会でもあります。

実装を確認しながらマトリクスを埋めていくと、「仕様にないロールが増えている」「本来分けるべき権限が一つのロールに丸められている」といった設計の綻びが見えてきます。テストの前段でこれを潰しておくと、後工程での手戻りが大きく減ります。

テスト観点そのものの洗い出し方に不安がある場合は、観点表で抜け漏れを防ぐテスト観点の洗い出し手順と合わせて進めると、権限以外の観点との整合も取りやすくなります。

水平権限のテスト観点｜他ユーザー・他テナントへのアクセス（IDOR）

水平権限とは、同じ権限レベルの他ユーザーのデータに対する制御です。ここが崩れると、A社のユーザーがB社のデータを見られる、といった情報漏洩に直結します。

水平権限のテストで確認すべき観点を整理します。

IDの差し替え: URLやリクエストボディのID（user_id、order_id 等）を他人のものに変更し、アクセスが拒否されるか
一覧のフィルタ: 一覧画面・検索結果に、自分がアクセス権を持たないデータが混ざらないか
連番・推測可能なID: IDが連番の場合、隣の番号を試すだけで他人のデータに到達しないか
間接参照: 添付ファイルのURLや画像URLなど、直接リンクで保護対象に届かないか
エクスポート機能: CSV・PDF出力時に、権限フィルタが適用されているか

水平権限のテストは「他人になりすまさず、自分のログインのままIDだけ書き換える」という最も現実的な攻撃を再現することが要点です。

具体的なテスト手順の一例です。

ユーザーAとユーザーB、2つのアカウントを用意する
ユーザーBでログインし、自分のデータのID（例: 1002）を控える
ユーザーAでログインした状態で、URLやAPIのIDを 1002 に書き換える
「アクセス権がありません」等で拒否されることを確認する
拒否されず閲覧・更新できた場合は、IDORとして重大バグに分類する

このとき、拒否が「画面上の非表示」だけで済んでいないかに注意します。ボタンを隠しているだけで、APIは通ってしまう実装は少なくありません。

水平権限のテストでは、テストデータの作り込みも成否を分けます。ユーザーAとユーザーBが、それぞれ「自分のデータ」を持っている状態を用意しておかないと、越境アクセスの確認そのものができません。テスト計画の段階で、複数ロール・複数ユーザー・複数テナントのアカウントを準備することを明記しておきましょう。件数の少ないデータでテストすると、フィルタ漏れが偶然表面化しないこともあるため、ある程度のデータ量を用意しておくと安心です。

マルチテナント型のSaaSでは、テナント（契約企業）単位の分離が水平権限の中核になります。テナント分離を含むSaaS特有の観点は、事故りやすい7領域を押さえるSaaSのテスト観点で詳しく扱っています。

垂直権限のテスト観点｜一般ユーザーによる管理者機能の悪用（特権昇格）

垂直権限とは、権限レベルの上下に対する制御です。一般ユーザーが管理者しか使えない機能を実行できてしまえば、特権昇格が成立します。

垂直権限のテストで確認すべき観点は次のとおりです。

管理画面URLの直接アクセス: メニューに表示されない管理者用URLを直接入力しても、一般ユーザーは拒否されるか
管理者用APIの直接呼び出し: 管理系エンドポイントを一般ユーザーのトークンで叩いて拒否されるか
パラメータによる権限指定: リクエストに role=admin のようなパラメータを付与しても昇格しないか
機能単位の権限: 「削除」「一括操作」「設定変更」など、危険度の高い操作ほど権限チェックが厳格か
UIの制御に依存していないか: ボタンの非活性化だけで防いでいて、サーバ側でチェックしていない箇所はないか

垂直権限の検証で最も重要なのは、「サーバ側で権限を判定しているか」の一点です。画面側の制御は迂回可能であり、防御にはなりません。

確認箇所	ありがちな実装ミス	テストでの確認方法
管理画面	メニュー非表示のみで、URL直打ちは通る	一般ユーザーで管理URLへ直接アクセス
危険操作ボタン	UIで非活性化するだけ	APIを直接呼び出して拒否を確認
権限パラメータ	クライアント送信値を信用する	改ざんしたロール値を送信して確認
新規機能	既存の権限チェックを付け忘れる	追加機能ごとに権限マトリクスで照合

具体例で考えてみましょう。ある業務システムで、一般ユーザーの画面には「削除」ボタンが表示されない設計になっていたとします。画面テストでは問題なく見えます。ところが開発者ツールで通信を確認し、管理者が削除したときのAPIリクエストを真似て一般ユーザーのトークンで送信すると、データが削除できてしまった——これが典型的な特権昇格です。

原因は、削除の可否をボタンの表示・非表示（画面側）だけで制御し、サーバ側で「このユーザーに削除権限があるか」を判定していなかったことにあります。画面テストだけでは、この抜けは絶対に見つかりません。

とくにリリースを重ねて機能追加していく受託開発では、新機能に権限チェックを付け忘れるという抜けが起きやすいものです。マトリクスに新しい列を足し、既存ロールとの関係を毎回確認する運用が有効です。

管理画面そのものの品質確認と、権限制御のテストは目的が異なります。本記事は権限制御に特化しているため、管理画面全般の操作性やデータ整合性は別観点として切り分けて計画してください。

画面だけで確認しない｜API・直リンク・パラメータ改ざんの検証

ここまで繰り返し触れてきたとおり、権限・ロールのテスト観点で最大の落とし穴は「画面だけでテストを完結させてしまうこと」です。実際の攻撃や事故は、画面を経由しない経路で起きます。

画面以外で確認すべき経路を整理します。

API直接呼び出し: 画面を介さず、APIエンドポイントに直接リクエストを送る経路
直リンク（ディープリンク）: メニューに出ないURLをブックマークやメールから直接開く経路
パラメータ改ざん: フォームの隠しフィールドやクエリパラメータを書き換える経路
リクエストの再送: ブラウザの開発者ツールや通信ツールで、過去のリクエストを改変して再送する経路
HTTPメソッドの差し替え: GET は許可でも DELETE は禁止のはずが、メソッドを変えると通る経路

「ボタンが表示されないから安全」は、権限テストにおいては根拠にならないと考えてください。UIは利便性のための制御であり、セキュリティ境界はサーバ側にあります。

APIレイヤーでの権限確認の具体的な進め方は、観点とチェックリストで押さえるAPIテストのやり方も参考になります。画面テストとAPIテストを別工程として計画に組み込むことが、権限バグの取りこぼしを減らします。

高橋寿一『知識ゼロから学ぶソフトウェアテスト』でも、セキュリティ観点のテストはペネトレーションテストのように「攻撃者の視点で通常と異なる操作を試す」姿勢が重要だと述べられています。権限テストはまさに、正常系をなぞるだけでは検出できない領域です。

画面を経由しない経路を確認するには、ブラウザの開発者ツールや通信を可視化するツールで、実際にどんなリクエストが送られているかを観察するのが近道です。難しい専用ツールを使わなくても、開発者ツールのネットワークタブでリクエストを確認し、パラメータを書き換えて再送するだけで、多くの権限バグは再現できます。まずは「正常な操作のときに、どのAPIがどんなデータを送っているか」を把握するところから始めるとよいでしょう。

大切なのは、テスト担当が開発者と同じ目線でリクエストを読めるようにしておくことです。画面の裏側で何が起きているかを理解できれば、「画面では止まっているが裏では通ってしまう」という抜けに気づけるようになります。逆に、画面操作しかできないテスト体制のままでは、権限バグの多くは構造的に検出できません。

こうした攻撃者視点の検証を内製で完結させるのが難しい場合は、専門ベンダーへの依頼範囲とベンダー選定を押さえる脆弱性診断の外注を検討する選択肢もあります。機能テストと脆弱性診断は目的が異なるため、両輪で考えると抜けが減ります。

権限変更・失効の反映とデータ範囲・マルチテナント分離

権限は「設定した瞬間」だけでなく、「変わった後」「失効した後」に正しく反映されるかまで見て初めてテストが完結します。ここは静的な確認では漏れやすい観点です。

権限変更・失効の即時反映

ロール剥奪後の即時反映: 権限を外した直後に、その操作が本当にできなくなるか
既存セッションへの影響: すでにログイン中のユーザーの権限を変更したとき、現在のセッションにも反映されるか
キャッシュの残存: 権限情報がキャッシュされ、古い権限のまま操作できてしまわないか
退職・アカウント無効化: 無効化したアカウントで、トークンやセッションが残っていても操作できないか

権限を剥奪したのに、ログイン中のセッションでは操作が通り続ける——これは内部不正の温床になる典型的な抜けです。

権限変更は「状態の遷移」として捉えると観点が整理しやすくなります。有効→無効、一般→管理者、管理者→一般といった遷移ごとに、期待される振る舞いを表にして確認するとよいでしょう。

実務では、権限変更の反映タイミングを仕様として明確に決めていないケースが目立ちます。「次回ログイン時に反映」なのか「即時反映」なのかで、テストの合否判定も変わります。テスト設計の前に、この仕様を関係者で合意しておくことが大切です。

データ範囲とマルチテナント分離

自組織のみ表示: 一覧・検索・集計で、自組織（自テナント）のデータだけが対象になっているか
フィルタ漏れ: 特定の検索条件やソート時に、他テナントのデータが紛れ込まないか
集計・レポート: 件数や合計金額の集計に、他テナントの値が混ざっていないか
共通マスタの扱い: 全社共通データと、テナント固有データの境界が正しいか

デフォルト権限・最小権限・監査ログ

最後に、設計思想レベルで確認すべき3点です。

観点	確認内容	なぜ重要か
最小権限の原則	各ロールに必要最小限の権限だけが付与されているか	過剰付与は漏洩・誤操作の温床
デフォルト拒否	明示的に許可した操作以外はすべて拒否されるか	許可漏れより安全側に倒せる
監査ログ	誰が・いつ・何をしたかを記録し追跡できるか	事故発生時の原因究明と抑止

OWASPのガイドでも、権限設計の基本として「最小権限（least privilege）」と「デフォルト拒否（deny by default）」が推奨されています。新しい権限を追加するときは、まず「拒否」を出発点に、必要な操作だけを開けていく発想が安全です。

この考え方はテストにもそのまま活きます。テスト設計でも「許可されるはずの操作」だけでなく「拒否されるはずの操作」を必ずセットで用意し、拒否が確実に効いていることを確認します。許可の確認だけで終わらせないことが、権限テストの品質を大きく左右します。

最小権限が守られているかは、時間の経過とともに崩れやすい観点でもあります。運用の中で「一時的に権限を付けたまま戻し忘れる」「退職者のロールが残る」といった積み重ねが、いつの間にか過剰付与を生みます。リリース時点で最小権限を確認するだけでなく、定期的に棚卸しする運用まで見据えておくと、長期的なリスクを抑えられます。

監査ログは、権限バグを未然に防ぐ仕組みではありませんが、事故発生時の被害範囲特定と再発防止に不可欠です。ログに残っていない操作は、後から追跡できません。

権限・ロールのテスト観点チェックリスト

ここまでの内容を、現場でそのまま使えるチェックリストにまとめます。テスト計画やレビューの際に、抜けがないかの確認にお使いください。

認証と認可の切り分け

[ ] 認証（ログイン）と認可（権限）を別のテスト範囲として計画したか
[ ] ロール×機能×操作のマトリクスを作成し、空欄を残していないか

水平権限（IDOR）

[ ] IDを他人のものに差し替えてアクセス拒否を確認したか
[ ] 一覧・検索・エクスポートに他ユーザーのデータが混ざらないか
[ ] 添付ファイル等の間接参照URLが保護されているか

垂直権限（特権昇格）

[ ] 管理画面URLへの直接アクセスが一般ユーザーで拒否されるか
[ ] 管理者用APIを一般ユーザーのトークンで叩いて拒否されるか
[ ] 権限判定をサーバ側で行っているか（UI制御に依存していないか）

経路の網羅

[ ] API・直リンク・パラメータ改ざん・メソッド差し替えを検証したか

変更・失効・範囲

[ ] ロール剥奪・アカウント無効化が即時に反映されるか
[ ] 既存セッション・キャッシュに古い権限が残らないか
[ ] 自組織・自テナントのデータだけが表示・集計されるか

設計原則

[ ] 最小権限・デフォルト拒否が守られているか
[ ] 監査ログで操作を追跡できるか

このチェックリストの中で一つでも「未確認」が残っているなら、そこが情報漏洩の入口になり得ると考えてください。

よくある質問｜権限テストでつまずくポイント

現場から寄せられやすい疑問を、Q&A形式で整理します。テスト計画を関係者に説明する際の補足にもお使いください。よくつまずくのは、次のような論点です。

内製と外注の切り分け
テストの優先順位づけ
実施タイミング
「画面で見えない」ことの扱い

この4つを事前に整理しておくだけで、権限テストの計画はぐっと具体的になります。

Q. 権限のテストは、どこまで自分たちでやり、どこから専門家に任せるべきですか。

A. 仕様どおりに権限が制御されているかの確認（機能面のテスト）は、開発チームやテスト担当で十分に実施できます。一方、攻撃者視点で未知の抜け道を探る作業は、専門的な知見や工数が必要です。まずは本記事のチェックリストで機能面を固め、より深い検証が必要な重要システムでは専門ベンダーの活用を検討する、という切り分けが現実的です。

Q. 全ロール×全機能を総当たりでテストすると工数が膨大です。優先順位はどうつけますか。

A. 被害の大きさで優先度を決めます。情報漏洩に直結する「他人のデータ参照」「管理者機能の実行」「削除・一括操作」を最優先とし、参照系より更新・削除系を重点的に確認します。マトリクスの「禁止」セルのうち、破られたときの被害が大きいものから着手してください。

Q. 権限のテストは、どのタイミングで実施するのが適切ですか。

A. 権限設計はシステムの土台であり、後から変更すると影響が広範囲に及びます。可能なら要件定義・基本設計の段階でロールのマトリクスを作り、実装と並行して観点を固めるのが理想です。少なくとも、結合テストの段階では権限の観点を明示的に組み込んでおきましょう。

Q. 「画面で見えないから大丈夫」という開発側の説明を、どう確認すればよいですか。

A. 画面での非表示は、あくまで利便性のための制御です。実際にAPIを直接呼び出して拒否されるかを確認するよう依頼してください。「サーバ側で権限を判定しているか」をテスト結果（拒否のレスポンス）で示せるかどうかが、判断の分かれ目です。

権限・ロールのテスト観点は、機能テストの延長では拾いきれません。攻撃者と同じ視点で「本来できないはずの操作」を意図的に試すことで、はじめて検出できます。まずはロールのマトリクスを一枚作るところから始めてみてください。

テスト体制の見直しや、権限まわりを含めたテスト設計の相談を検討されている方は、テスト体制の課題についてお気軽にご相談ください。現状の体制に合わせた進め方を一緒に整理できます。