Refererをアクセス制御に使っていないか？document.referrerによる閲覧制限の危険性・診断基準・対策

Refererをアクセス制御に使っていないかとは

Refererをアクセス制御に使っていないかとは、「ログイン画面（またはトップページ）から来た場合だけ表示する」「自サイトからのリンク経由でなければ追い返す」という制御を、HTTP の Referer ヘッダーや JavaScript の document.referrer で実現していないかを確かめる診断項目です。

// 危険な例：遷移元URLで閲覧可否を決めている
if (document.referrer.indexOf("/login.htm") == -1) { location.href = "/"; }

Referer は送信元が自由に設定・削除できる情報です。CWE-293（Using Referer Field for Authentication）は、Referer フィールドは容易に改変でき、完全性の確認手段として妥当ではないと説明しています。セキュリティAIチェッカーは、トップページHTMLのスクリプトで document.referrer を比較し、その結果で遷移・認証に関わる処理を行っている兆候を検出します。

Referer と document.referrer の違い

参照元は正規の利用者でも空になる

MDN の説明のとおり、既定の参照元ポリシー strict-origin-when-cross-origin では、クロスオリジン遷移時はオリジンだけに切り詰められ、HTTPS から HTTP への遷移では送られません。Referrer-Policy: no-referrer、ブラウザのプライバシー設定、拡張機能、ブックマークやアドレスバーからの直接アクセスでも空になります。

つまり Referer による制御は、攻撃者には簡単に偽装される一方で、正規の利用者は理由なく弾かれるという、セキュリティと利便性の両方で不利な仕組みです。

Refererで閲覧を制限してはいけない理由

サーバー側の Referer チェックも認可にはならない

サーバー側で Referer を見る実装（.htaccess の RewriteCond %{HTTP_REFERER} 等）も、同じ理由で認可にはなりません。ただし、画像の直リンク抑止のような「負荷対策」用途は、セキュリティ境界ではないと理解したうえで使われることがあります。

CSRF 対策の補助として Origin／Referer を検証するのは別の目的（送信元の妥当性確認）であり、トークン方式などと組み合わせる前提で OWASP でも言及されます。この項目が問題にするのは「誰が閲覧してよいか」の判定に使うケースです。

要件の根拠

よくある誤解

• 「Referer はブラウザで書き換えられないから安全」：ブラウザ経由でなければ自由に送れます。保護対象を取得するのに正規のブラウザを使う必要はありません。
• 「ログイン画面からしかリンクしていないから URL は知られない」：URL はブラウザ履歴、アクセスログ、共有されたリンク、検索エンジンのクロールで漏れます。

Web Storage の値で「ログイン済み」とみなす実装は「クライアント保存値を認証判定に使っていない」、Cookie や Referer を偽装したときに見える範囲が増えないかの実地確認は「Cookie・Referer偽装でアクセス範囲が増えない」で扱います。

Refererをアクセス制御に使っていないの診断基準（セキュリティAIチェッカー）

取得対象

• 診断対象URL（最終URL）のトップページHTML 1件（インラインスクリプトを含む）。外部JSは取得しません。追加通信はありません。
• サーバー側で HTTP Referer を検査しているかは、受動的な取得では観測できません。Cookie・Referer 偽装による差分は「Cookie・Referer偽装でアクセス範囲が増えない」が別途確認します。

判定に使う条件

HTML中に、次の3要素がこの順で近接して現れるかを、大文字小文字を区別せずに調べます。

1. document.referrer
2. その後160文字以内に、比較・照合を表す語（indexOf、includes、startsWith、endsWith、match、search、test、==／===／!=／!==）
3. さらに300文字以内に、遷移または認証を表す語（location = …、location.href = …、location.replace(、location.assign(、login、signin、auth、ログイン、認証、許可）

document\s*\.\s*referrer[\s\S]{0,160}?(?:indexOf|includes|startsWith|endsWith|match|search|test|===?|!==?)[\s\S]{0,300}?(?:location(?:\s*\.\s*href)?\s*=(?!=)|location\s*\.\s*(?:replace|assign)\s*\(|login|signin|auth|ログイン|認証|許可)

判定条件

近接条件を設けているのは、アクセス解析タグが document.referrer を単に送信する（{ref: document.referrer}）ケースや、「戻る」ボタンのための参照など、アクセス制御と無関係な利用を△にしないためです。静的検査では実際の制御効果を断定できないため、一致時も×ではなく△（要確認）とします。

得点への影響

重み5の critical 項目です。○は5点、△は2.25点（5×0.45）、×は0点。対象外は分母から除外されます。

自治体サイトでの判定例

検出の限界

• 外部JS内の判定、変数を経由して離れた位置で比較する実装、サーバー側の HTTP_REFERER 判定は、この項目では検出しません。○は「トップページHTMLに兆候が無い」ことを示すだけです。
• 逆に、解析タグなどで document.referrer の直後（合計約460文字以内）に search・test・== などの語と login・auth・location = などの語が偶然並ぶと、アクセス制御と無関係でも△になり得ます。△の場合は該当スクリプトを読み、参照元の比較結果で表示可否を決めているかを確認してください。

手動確認の手順

# Referer 無しで保護ページが返るか
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.lg.jp/limited/page.htm
# Referer を偽装すると返るか（返るならサーバー側 Referer 判定の疑い）
curl -s -o /dev/null -w "%{http_code}\n" -H "Referer: https://www.example.lg.jp/limited/login.htm" https://www.example.lg.jp/limited/page.htm

どちらも200で本文が返る場合、ブラウザ内の Referer 判定は意味を持っていません。2つ目だけ200の場合はサーバー側 Referer 判定であり、同様に偽装可能です。

Refererでアクセス制御しているとどんなリスクがあるか

攻撃シナリオ

1. 攻撃者が限定公開ページのソースから document.referrer 判定と遷移先を読み取る。
2. 保護対象URLを直接 curl で取得するか、Referer を偽装して取得する。
3. 研修資料、内部連絡、名簿、入札関連の事前資料などが閲覧・転載される。

想定される被害

• 非公開情報の漏えい、個人情報が含まれる場合の漏えい等報告対応
• 「リンク元を限定しているので安全」という誤認による長期間の放置
• 正規利用者がブックマークやプライバシー設定のために閲覧できない業務上の支障

Refererに頼らないアクセス制御の設定方法（Apache・nginx・IIS・Next.js）

基本方針

1. 閲覧可否は、サーバー側で認証済みセッションを検証して決める（ASVS V8.3.1）。
2. Referer・document.referrer による判定は削除する。残す場合も「表示上の案内」に限定し、セキュリティ機能として扱わない。
3. 公開してよい情報か、認証が必要な情報かを最初に区別する。一般公開して問題ない資料なら、そもそも制御を外すのが最も確実です。

Apache（.htaccess）— Referer 判定をやめ、認証を掛ける

# 誤った例（削除する）
# RewriteCond %{HTTP_REFERER} !^https://www\.example\.lg\.jp/ [NC]
# RewriteRule \.(?:htm|pdf)$ - [F]

# 最小限の代替：Basic 認証（HTTPS 必須）
AuthType Basic
AuthName "Restricted"
AuthUserFile /home/example/.htpasswd
Require valid-user

Basic 認証は HTTPS 上でのみ使い、利用者ごとのアカウント発行と退職時の削除を運用に組み込みます。業務システムとしては、アプリケーション側のセッション認証や SSO の利用が望まれます。

nginx

location /limited/ {
    auth_request /auth/check;   # アプリでセッションを検証
    error_page 401 = /login;
}

valid_referers ディレクティブ（ngx_http_referer_module）は、公式ドキュメントでも「Referer は容易に偽装できるため、目的は完全な遮断ではなく、通常のブラウザからの大量リクエストの抑止」と説明されており、認可には使いません。

IIS

「URL 書き換え」で {HTTP_REFERER} を条件にした拒否ルールは認可にならないため、対象フォルダーに Windows 認証またはフォーム認証を設定し、匿名認証を無効にします。

Next.js（Vercel）

// app/limited/[slug]/page.tsx（抜粋）
import { cookies } from "next/headers";
import { redirect } from "next/navigation";
import { verifySession } from "@/lib/session"; // サーバー側でセッションストアと照合

export default async function Page() {
  const sid = (await cookies()).get("__Host-sid")?.value;
  if (!sid || !(await verifySession(sid))) redirect("/login");
  // 認可済みのときだけコンテンツを描画
}

headers().get("referer") で分岐する実装は避けます。

CMS

限定公開機能（会員ページ、パスワード保護、イントラ専用公開）を使い、テーマのJavaScriptで参照元を見る仕組みは削除します。添付ファイルの直接URLにも同じ保護が掛かるかを確認してください。

サイトを壊さないためのガードレール

• Referer 判定を削除するだけで認証を追加しないと、ページが完全公開になります。必ず「代替の認証を有効化 → 動作確認 → 旧判定を削除」の順で進めます。
• 「Referrer-Policy」は情報漏えい防止のための設定であり、この項目の対策ではありません。

設定後の確認方法

# 未認証では 302/401/403 のいずれかになること
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.lg.jp/limited/page.htm
# Referer を偽装しても結果が変わらないこと
curl -s -o /dev/null -w "%{http_code}\n" -H "Referer: https://www.example.lg.jp/" https://www.example.lg.jp/limited/page.htm

よくある質問（FAQ）

参考資料

• CWE-293: Using Referer Field for Authentication
• MDN Referer
• OWASP ASVS 5.0.0 V8 Authorization
• OWASP WSTG-ATHN-04 Testing for Bypassing Authentication Schema
• OWASP WSTG-ATHZ-02 Testing for Bypassing Authorization Schema
• nginx Module ngx_http_referer_module
• nginx Module ngx_http_auth_request_module
• IPA「安全なウェブサイトの作り方」

「Refererをアクセス制御に使っていない」と関連する診断項目

• クライアント保存値を認証判定に使っていないcritical
• Cookie・Referer偽装でアクセス範囲が増えないcritical
• Referrer-Policymedium
• 認証後コンテンツを静的ファイルで直接配信していないcritical
• 認証後静的ファイルの未認証到達性critical
• 未認証APIの情報露出兆候high
• OAuth/OIDCの非推奨フロー兆候high