Summary
この文書の要点
- 非公開サイトはURL秘匿ではなく認証で守る。
- 許可ユーザーや許可ドメインを明示的に管理する。
- Google認証は本人確認として使い、管理権限は内部DBや許可リストで別に判定する。
- ルートガード、APIガード、ホスティング側制限を重ね、単一の防御に依存しない。
どこが設計の難所か
小さな管理サイトでは、公開URLを共有しなければ大丈夫と考えがちです。しかし、検索に載らなくてもURLが漏れる可能性はあります。認証なしの管理画面は情報露出のリスクになります。
静的サイトとして配信する場合、サーバー側でリクエストごとに認証する仕組みがないことがあります。認証が必要なデータはAPI側で守り、静的HTMLに秘密情報を含めない設計が必要です。
管理サイトは一般公開ページと違い、存在する機能そのものが機密情報になることがあります。ログインできないだけではなく、未認証時にどこまで情報を返すか、エラー画面に何を出すかも設計対象です。
境界をどう切るか
Google認証で本人確認し、アプリ側で許可ユーザーまたは許可ドメインを確認します。管理APIは認証トークンを検証し、権限のないユーザーにはデータを返しません。画面側はログイン状態に応じて表示を切り替えます。
設計では、ホスティング入口、認証、内部権限、APIアクセスを分けます。FirebaseやGoogle OAuthで認証し、アプリ側では許可されたユーザーか、どの操作ができるかを別に判定します。
実装で効く細部
Firebase AuthenticationやOAuth連携を使う場合でも、トークン検証はAPI側で行います。許可ユーザー一覧は設定やDBで管理し、退職や担当変更時にすぐ無効化できるようにします。
React側では、初期ロード時に認証状態を復元し、未確認、未ログイン、権限なし、利用可能を別状態として表示します。API側はID tokenやセッションを検証し、管理者権限を毎回確認します。
- フロントエンドのルートガードだけでなく、API側で必ず権限判定する。
- 未許可ユーザーのログイン試行を監査ログへ残す。
- 管理サイトのrobots、キャッシュ、エラーメッセージで不要な情報を露出しない。
壊れ方を観測する
検証では、未ログイン、許可外ユーザー、期限切れトークン、URL直打ち、API直接呼び出しを確認します。静的ファイルに機密データが埋め込まれていないかもビルド成果物で確認します。
検証では、未ログイン、許可外アカウント、権限停止、期限切れトークン、直接APIアクセスを確認します。画面が隠れていることではなく、APIが拒否していることをテストします。
捨てた選択肢とトレードオフ
強い保護が必要な管理画面では、静的配信だけでなくサーバー側認証を持つ構成の方が適します。軽い管理サイトでは、認証付きAPIと静的UIの組み合わせが現実的なこともあります。
Google認証に寄せると運用は簡単になりますが、外部アカウントの管理に依存します。内部の許可リストやロールを持てば運用変更に対応しやすくなりますが、管理画面自体の運用も必要です。
現場に残す判断軸
非公開管理サイトは、URLを隠すのではなく認証と権限で守ります。静的配信を使う場合でも、データを返すAPI側の検証を中心に設計することが重要です。
非公開管理サイトは、認証を付けたら終わりではありません。入口からAPIまで同じ権限判断を通すことで、静かながら堅い管理画面になります。
