ログインできたら安心？会員サイト公開前の権限チェック

ログインできたのに、なぜ確認が必要なのか

会員サイトを作ると、まず自分のアカウントで一連の操作を試します。登録からログイン、予約、履歴の表示まで進めば、基本の流れはできています。ただし、ここで確認できたのは「自分が利用できること」です。「利用できないはずの人を止められること」は別に確かめる必要があります。

ログイン時の本人確認は「認証」、誰が何をできるかの判断は「認可」と呼ばれます。この記事では、認可を「権限の確認」と言い換えます。建物に入るための本人確認と、建物の中で入ってよい部屋の区別を思い浮かべると分かりやすくなります。入口が同じでも、すべての部屋を全員に開けるわけではありません。

OWASPの「Authorization Cheat Sheet」も、本人確認と権限の判断を区別しています。ログイン済みであることが、すべての情報へのアクセスを認める理由にはならないという考え方です。会員向けの注文履歴、問い合わせ内容、ダウンロード資料などは、誰のものかを含めて扱う必要があります。

これは利用者を疑うための確認ではありません。画面の不具合や設定の変更によって、意図せず他人の情報が表示される状況を減らすための準備です。公開直前に初めて相談すると判断が止まりやすいため、仕様を決める段階から、見せる対象と操作の範囲を整理しておきましょう。

人・情報・操作の組み合わせを先に決める

確認を始める前に、「誰が」「何に」「どんな操作をしてよいか」を並べます。一般会員、サポート担当、管理者といった立場だけでなく、同じ一般会員でも本人の情報と別の会員の情報を分けることが大切です。複数の会社が使うサービスなら、会社の境界も必要になります。

例えば、会員は自分の予約を確認・変更でき、サポート担当は問い合わせ対応に必要な範囲を参照し、管理者は担当者の権限を管理する、といった整理が考えられます。これは説明のための一般例です。実際の権限は、自社の業務と取り扱う情報に合わせて決めます。「管理者なら何でも見える」で済ませず、業務上の必要性も確かめてください。

また、情報を見る操作と、書き換える操作は分けて考えます。一覧を閲覧できる担当者が、顧客の連絡先を修正できてよいとは限りません。資料の表示、ファイルの出力、招待、削除、権限変更なども、それぞれ判断する対象です。画面にボタンがあるかどうかだけで整理すると、裏側で行われる処理が抜けやすくなります。

権限の表には、許可する組み合わせに加えて、許可しない組み合わせも残します。判断が決まっていない欄は「未決定」として担当者を置きます。空欄を開発者の解釈に任せないことが、公開直前の手戻りを減らす助けになります。

権限の整理は、運営側だけで決めず、実際に業務を担当する人にも確認してもらいます。問い合わせ対応では一部の情報が必要でも、データ全体の出力までは不要かもしれません。日常の作業に必要な範囲と、例外的に必要になる範囲を分けておくと、通常の担当者へ広すぎる権限を与えずに運用を考えられます。例外時の承認方法も、開発とは別に運用ルールとして残しましょう。

• 本人の情報と、他の会員の情報を分ける。
• 閲覧・変更・削除・出力など、操作ごとに判断する。
• 同じ役割でも、所属会社や担当範囲の境界を決める。
• 未決定の組み合わせを残し、確認担当を決める。

公開前は「できる」と「できない」を対にして確かめる

許可した操作ができることと、許可しない操作が止まることを、対にして確認します。一般会員が自分の予約を変更できるなら、他の会員の予約を変更できないことも確認対象です。この対があると、不具合が「必要な機能を使えない」のか、「使わせてはいけない機能を使えてしまう」のかが伝わりやすくなります。

確認には、運営者が管理するテスト用アカウントと、個人情報を含まない試験用データを使います。実在する会員の情報を試験材料にしないよう、対象環境と操作してよい範囲を先に決めてください。本番のメール送信、決済、削除などに影響する操作は、そのまま実行せず、開発担当者と確認方法を調整します。

画面のメニューを非表示にすることは、使いやすさのためには役立ちます。しかし、それだけで情報へのアクセスが止まっているとは判断できません。サーバー側、つまりデータを保管・処理する側でも、操作のたびに権限を確かめる設計かを開発担当者に確認します。具体的な検証方法は、許可された範囲で専門担当者が決める部分です。

状態が変わる場面も忘れないでください。担当者の異動、管理権限の取り消し、会員の退会、契約終了などです。変更前に使えていた操作が、変更後には期待どおり止まるかを確認します。画面上の表示だけでなく、変更の反映タイミングや、利用者に案内する内容も仕様として明らかにしておくと、問い合わせ対応まで整理できます。

結果は、開発担当者が直せる形で残す

「権限がおかしい」という一言では、どこを直すべきかが伝わりません。確認した役割、対象の情報、行った操作、本来の結果、実際の結果をそろえて記録します。環境や確認日時、使った試験データの識別情報も、再確認に必要な範囲で添えます。個人情報や認証情報を、そのまま報告書へ貼り付けない配慮も必要です。

説明用の記録例なら、「一般会員は本人の予約だけを表示できる想定だが、試験で別の会員の予約情報が表示された」という書き方になります。これは実際に発見した不具合の報告ではありません。期待と実際の差を一文にすることで、発注者にも影響が分かる、という例です。修正後には、当初の操作を再確認し、他の役割に影響が出ていないかも見直します。

確認できなかった項目も報告に残しましょう。管理者アカウントが用意できなかった、外部サービスとの連携を試していない、といった制約は、合格と同じ扱いにはできません。「問題なし」と「未確認」を分けておくことで、公開するか、追加確認を行うかの判断材料になります。

公開前の確認を相談する際は、Custosの公開前診断の案内も参考にしてください。ログインが必要な範囲、複数の役割、サーバー側の権限などは、どこまで確認対象にできるかを事前に相談することが大切です。URLを渡せば内部の権限をすべて確認できる、という意味ではありません。

依頼時には、通常の会員向け画面だけでなく、担当者が使う管理画面の存在も伝えてください。現在の公開前診断はWebアプリが対象で、ネイティブのAndroid・iOSアプリは対象外です。また、コードレビューや修正代行を含むものではありません。権限の設計や内部処理まで専門的に調べたい場合は、その目的を明らかにして、追加の確認や別の診断が必要か相談しましょう。

まとめ：会員の境界を決めてから、公開後も見直す

会員サイトの公開前確認は、ログインに成功するかだけでは完結しません。本人と他人、一般会員と担当者、契約中と終了後などの境界を決め、許可する操作と止める操作の両方を確かめます。確認した結果は、仕様との違い、影響、再確認の方法が分かる形で残すことが重要です。

まずは主要な機能を選び、利用者の立場と操作の一覧を作ってみてください。その表に「期待する結果」「確認結果」「未確認の理由」を加えれば、発注者と開発担当者が話すための共通資料になります。すべてを一度に増やすより、扱う情報と業務上の影響から、先に確認する範囲を決めましょう。

公開後も、機能追加や担当者の変更で権限の前提は変わります。公開前の動作確認を区切りにせず、公開後の脆弱性診断や定期的な見直しにつなげてください。外から見える弱点の診断と、ログイン内部の業務上の権限確認は、確認できる範囲を分けて組み合わせることが大切です。