結論（認証・アクセス制御）
認証・アクセス制御の診断では、sessionStorageやRefererのような利用者が自由に作れる値で閲覧可否を決めていないか、ログイン後に見せるはずの静的ファイルやAPIがCookieなしで取得できないか、OAuth/OIDCで非推奨のフローを使っていないかを確かめます。7項目のうち5項目が最重要（critical）です。
認証・アクセス制御の診断項目一覧（7項目）
クライアント側だけの認証、Referer依存、認証後ファイルの直接公開、OAuthの非推奨フローなどを確認します。各項目名から、意味・診断基準・リスク・具体的な対策を解説したページへ移動できます。
| No. | 診断項目 | 重大度 | 概要 |
|---|---|---|---|
| 73 | クライアント保存値を認証判定に使っていない | critical | クライアント保存値を認証判定に使っていないかは、sessionStorageやlocalStorageの値だけで「ログイン済み」とみなす危険な実装を見分ける診断項目です。 |
| 74 | Refererをアクセス制御に使っていない | critical | Refererをアクセス制御に使っていないかは、遷移元URL（Referer・document.referrer）で閲覧可否を決める危険な実装を見分ける診断項目です。 |
| 75 | 認証後コンテンツを静的ファイルで直接配信していない | critical | 認証後コンテンツを静的ファイルで直接配信していないかは、ログイン後に menu.htm などの静的ファイルへ遷移させ、URLを知れば誰でも見られる構成を見分ける診断項目です。 |
| 101 | Cookie・Referer偽装でアクセス範囲が増えない | critical | Cookie・Referer偽装でアクセス範囲が増えないとは、任意のCookieや自サイトのRefererを付けても保護ページが見られない状態です。 |
| 102 | 認証後静的ファイルの未認証到達性 | critical | 認証後静的ファイルの未認証到達性は、ログイン後に見せる.htmlや.csvのURLを直接開いたとき、ログインなしで中身が返ってしまうかの確認です。 |
| 103 | 未認証APIの情報露出兆候 | high | 未認証APIの情報露出兆候とは、ログインせずに取得できるAPIやJSONの応答に、password・token・email・roleなど機微な項目名が含まれている状態です。 |
| 127 | OAuth/OIDCの非推奨フロー兆候 | high | OAuth/OIDCの非推奨フロー兆候を解説。 |
認証・アクセス制御の診断とは
認証・アクセス制御の診断は、ログインした人だけに見せるはずのページやデータが、ログインしていない第三者にも取得できる状態になっていないかを確かめるものです。セキュリティ診断127項目のうち、認証の仕組みと閲覧可否の判定に関する7項目がこの分類に入ります。
認証は「誰であるか」を確かめること、アクセス制御（認可）は「その人が何を見てよいか」を決めることです。どちらも、判定の根拠を利用者が自由に作れない場所、つまりサーバー側のセッションに置くことが大原則です。
この分類で問題になる典型例は、判定をブラウザ側に任せてしまう作りです。sessionStorageやlocalStorageに「ログイン済み」を保存して画面を切り替える、document.referrer で「ログイン画面から来た場合だけ表示する」、JavaScriptでパスワードを確認してから menu.htm のような静的ファイルへ移動させる、といった実装がこれにあたります。sessionStorageの値は開発者ツールのコンソールで自由に作れ、Refererは curl やプロキシツールで任意の値を送れます。静的ファイルは、サーバー設定で認証を掛けない限り、URLを知っていれば誰にでも返されます。
もう1つの観点はAPIとOAuthです。公開ページから参照されているAPIが、画面には表示しない項目まで返していれば、JSONの応答を開発者ツールで見るだけで情報が露出します。OAuth/OIDCでは、トークンがURLに入るImplicit flowや、クライアントが利用者のパスワードを扱うROPCは、現在は使わないよう求められています。
7項目の全体像（3つのグループ）
この分類の7項目は、大きく3つのグループに分けて考えると整理しやすくなります。
| グループ | 診断項目 | 確認する内容 |
|---|---|---|
| ブラウザ側に任せた判定の兆候 | 「クライアント保存値を認証判定に使っていない」、「Refererをアクセス制御に使っていない」、「認証後コンテンツを静的ファイルで直接配信していない」 | トップページのHTMLに、認証系のキーを getItem／setItem する処理、document.referrer の比較による遷移、認証の入口から静的ファイルへの遷移があるか |
| 未認証での到達性の確認 | 「認証後静的ファイルの未認証到達性」、「Cookie・Referer偽装でアクセス範囲が増えない」 | 認証後の静的ファイルをCookieなしで直接要求して内容が返るか、任意のCookieやRefererを付けると拒否が許可に変わるか |
| APIと外部認証 | 「未認証APIの情報露出兆候」、「OAuth/OIDCの非推奨フロー兆候」 | Cookieなしで取得したAPIのJSONにパスワード・トークン・メールなどのキー名があるか、response_type=token や grant_type=password の兆候があるか |
1つ目のグループは、HTMLの静的検査で「危ない作りの兆候」を見つける前段の確認で、判定は△（要確認）までです。2つ目のグループは、実際にCookieなしやヘッダー偽装で要求を送り、到達できてしまうかを確かめる後段の確認で、内容が返れば×（要改善）と確定します。兆候と到達性の両方を見ることで、誤検知を抑えつつ実害のある不備を見つけられます。
優先して確認すべき項目
重大度が「最重要（critical）」の5項目は、問題があるとログインなしで保護対象の情報を見られるおそれがあるため、最初に確認します。
- 認証後静的ファイルの未認証到達性：パスワード欄のあるページの遷移先や、会員・管理系パスの静的ファイルをCookieなしで要求し、ログイン画面以外の中身が2xxで返れば×です。証拠欄には件数だけを表示し、取得した内容は表示しません。
- Cookie・Referer偽装でアクセス範囲が増えない：保護されていそうなURLに、何も付けない・任意Cookie・Referer・両方の4条件で要求し、何も付けない要求が拒否なのに偽装した条件で2xxになれば×です。
- 認証後コンテンツを静的ファイルで直接配信していない：認証の入口と、スクリプトやフォームによる静的ファイルへの遷移が同じページにあると△です。通常の a href によるリンクは条件にしていません。
- クライアント保存値を認証判定に使っていない：認証・トークン系の名前のキーを扱う兆候があると△です。トークンを保持してAPIへ送り、サーバーが検証する設計自体は直ちに違反ではありません。
- Refererをアクセス制御に使っていない：document.referrer の比較と遷移・認証の処理が近接していると△です。画像の直リンク抑止のような負荷対策の用途は、この項目が問題にするケースではありません。
次に「重要（high）」の2項目を確認します。「未認証APIの情報露出兆候」は、password・access_token・session_id などのキーがあれば×、email・role・user_id だけなら△です。防災情報やオープンデータのように誰でも取得してよいAPIは認証不要で正しく、問題になるのは応答の中身です。「OAuth/OIDCの非推奨フロー兆候」は、解説文書や未使用コードの可能性もあるため×ではなく△とし、Authorization Code＋PKCEへの移行を検討する手がかりにします。
直すときの進め方と注意点
認証の作り直しは、手順を誤ると「保護が外れて完全公開になる」か「正規の利用者がログインできなくなる」かのどちらかを招きます。次の順で進めるのが安全です。
- まずサーバー側のセッションで認証する仕組みを用意する：サーバーで認証し、HttpOnly・Secure・SameSite付きCookieのセッションで保持します。PHPなら、ログイン時に session_regenerate_id(true) を呼び、session.use_strict_mode=1 でサーバーが発行していないIDを受け付けないようにします。
- 保護したいファイルを公開領域の外へ移す：実ファイルを公開ディレクトリの外へ移し、セッション検証後に配信するスクリプト経由でのみ返します。旧静的URLは404か403にします。推測されにくいファイル名、robots.txtでの除外、noindexはいずれもアクセスを防ぎません。
- 古い判定は代替の認証を有効にしてから消す：Referer判定やsessionStorageの確認を先に削除すると、その時点でページが完全公開になります。サーバー側の認証が動いていることを確認してから旧判定を削除します。
- APIは応答を必要な項目だけで組み立てる：画面に表示しない項目も、APIが返した時点で露出しています。認証必須のAPIは全エンドポイントでサーバー側の認証を確認し、露出していたトークンやパスワードは失効・再発行します。
- OAuthの旧フローは移行を確認してから止める：認可サーバーでImplicitやROPCを無効にする前に、そのクライアントを使う全アプリがAuthorization Code＋PKCEへ移行済みであることを確認します。先に止めるとログインできなくなります。
自治体・公共機関のサイトで特に注意すること
自治体サイトでは、職員向けの簡易ポータル、議会資料の限定公開ページ、外部委託で作られた会員向けページなどで、ブラウザ側だけで判定する簡易な「パスワード付きページ」が見つかることがあります。「ログイン画面から来た人だけ見られる」「Cookieが付いていれば会員扱い」といった実装も、委託開発や簡易な会員ページで今も見られます。よくある注意点として、次のようなものがあります。
- JavaScriptでパスワードを照合し、静的な .htm や .txt へ移動させる簡易ログインは、移動先のURLを直接開くだけで閲覧できる。照合用のパスワードやハッシュもソースに含まれる。
- 「ログイン画面からしかリンクしていないから大丈夫」と考えがちだが、URLはブラウザ履歴、アクセスログ、共有されたリンク、検索エンジンのクロールで漏れる。
- WordPressの標準REST APIは、投稿を公開しているユーザーの表示名やスラッグを未ログインでも返すため、不要なエンドポイントは無効化するか認証必須にする。
- すでに流出していた可能性がある場合は、アクセスログで該当URLへの外部からの200応答を確認し、個人情報が含まれていれば組織の手順に従って報告する。
保護しているページとAPIの一覧を作り、それぞれがサーバー側のセッションで守られているかを定期的にCookieなしの直接アクセスで確かめると、こうした不備を防ぎやすくなります。
よくある質問（FAQ）
認証・アクセス制御の診断項目は、どの順番で確認すればよいですか？
まず実際の到達性を確かめる「認証後静的ファイルの未認証到達性」と「Cookie・Referer偽装でアクセス範囲が増えない」を確認し、×があれば最優先で塞ぎます。次に兆候を見る3項目（クライアント保存値、Referer、静的ファイルへの遷移）の△を手動で確かめ、最後に重要（high）の未認証APIの情報露出とOAuth/OIDCの非推奨フローを確認します。
JavaScriptでパスワードを確認するログインは、認証・アクセス制御として安全ですか？
安全ではありません。照合は利用者のブラウザ内の処理なので、移動先のファイルのURLを直接入力すれば誰でも取得できます。パスワードやそのハッシュがHTMLやJSのソースに含まれるため、総当たりも容易です。認証と認可はサーバー側のセッションで検証します。
認証・アクセス制御の診断で△（要確認）になった場合、必ず脆弱性がありますか？
必ずではありません。兆候を見る項目はHTMLの静的検査のため、アクセス解析のキー名や無関係なスクリプトでも一致することがあります。保護したいページをCookieなしで直接取得して本文が返らないかを手動で確かめ、認証用途でなければ対応は不要です。
認証・アクセス制御の診断で問題なしなら、会員ページ全体が安全ですか？
安全とは限りません。診断は公開情報から推定した一部のURLやAPIだけを確認します。会員ページ・管理画面の全URLについて、認証の有無と権限ごとのアクセス可否表（認証マトリクス）を作って手動で確認し、APIはAPI一覧（OpenAPI定義等）を使った認証・認可テストを別途実施してください。
認証・アクセス制御の7項目はまとめて確認できますか？
セキュリティAIチェッカーにURLを入力すると、この7項目を含む127項目を公開情報から自動で診断し、項目ごとの判定と改善の優先順位を表示します。