トップページが正常応答しているか？HTTPステータスコードの確認方法・原因・対策

トップページが正常応答とは（HTTPステータスコード2xx）

トップページが正常応答しているとは、診断対象として入力されたURL（多くは自治体公式サイトのトップページ）が、リダイレクトをたどった最終応答で HTTP 2xx（成功） を返している状態です。通常は 200 OK です。

HTTP/2 200
content-type: text/html; charset=UTF-8

住民が最初に訪れる入口が 4xx（403 Forbidden、404 Not Found など）や 5xx（500 Internal Server Error、503 Service Unavailable など）を返している場合、情報提供そのものが止まっているだけでなく、次のような「設定上の異常」が背後にある可能性があります。

• Webサーバーやロードバランサーの設定ミス、証明書更新・サーバー移行後の不整合
• CMSやアプリケーションの例外（データベース接続失敗など）
• WAF・CDNの過剰なブロック設定
• メンテナンス表示が長期間放置されている

HTTPステータスコードの分類（RFC 9110）

RFC 9110 はステータスコードを先頭の桁で5つのクラスに分類しています。

200 OK は「要求が成功し、対象リソースの表現を返している」ことを示します。4xx はリクエスト側の問題（認証が必要、権限がない、存在しない等）、5xx はサーバー側で処理できなかったことを示します。

リダイレクトと最終応答

https://www.city.example.lg.jp/ へのアクセスが /index.html や /top/ へ 301/302 で転送されるのは一般的な構成です。重要なのは「転送の最後にたどり着いたページ」が正常かどうかです。セキュリティAIチェッカーも転送を追跡し、最終応答のステータスを評価します。HTTPからHTTPSへの転送そのものは「HTTPからHTTPSへ転送」で別に確認します。

トップページの正常応答はなぜ重要か

ほかの診断項目の「前提」になる

セキュリティ診断の観点では、この項目はほかの多くの項目の前提です。トップページがエラーページであれば、セキュリティヘッダー・HTML・Cookieなどの判定は「エラーページに対する判定」になり、本来のページの状態を表しません。そのため重大度は high、重み3としています。

診断ツールから見た応答とブラウザから見た応答の違い

セキュリティAIチェッカーはブラウザではなくサーバーから直接アクセスします。そのため、次の理由でブラウザでの表示結果と異なることがあります。

• WAFやCDNが、ブラウザらしくないUser-Agentや、海外・クラウド事業者のIPアドレスからのアクセスを拒否している
• JavaScriptを実行しないと本文が表示されない構成（初期HTMLは200でも、画面描画は別のAPIに依存）
• 国内IPアドレスのみ許可するアクセス制限

これらは「ブラウザで見えるから問題ない」とは限りません。検索エンジンのクローラーや支援技術、海外在住者からのアクセスも同じように拒否されている可能性があるため、意図した制限かどうかを確認する価値があります。

トップページの正常応答についてよくある誤解

• 「200なら問題ない」わけではない：本文が「メンテナンス中です」「エラーが発生しました」でも200を返す実装（ソフトエラー）があります。この項目はステータスコードのみで判定するため、本文がエラー表示かどうかまでは判定しません。存在しないパスにも200を返す「ソフト404」は「存在しないURLのステータス」で扱います。
• 「403はセキュリティ的に安全」ではない：WAFやアクセス制限が本来公開すべきトップページを拒否しているなら、可用性の問題です。逆に、本来非公開のURL（管理画面など）を診断対象に入れて401や403が返るのは正しい挙動で、その場合は「公開ページではないURLを入力した」ことを示します（この診断では401は×、403は後述のとおり診断中止になります）。
• 503は一時的とは限らない：Retry-After を伴う計画メンテナンスなら問題ありませんが、継続的に503が返るならバックエンド障害を疑う必要があります。

トップページが正常応答の診断基準（セキュリティAIチェッカー）

取得方法

1. 入力URLを検証します（http/https以外、認証情報入りURL、localhost・.localhost・.local・.internal、プライベートIP・予約済みIPは診断不可としてエラー）。
2. DNSで解決したIPアドレスを固定（ピン留め）したうえで、Node.jsのHTTPクライアントで GET を1回送信します。User-Agent は MiniParse-Security-Review/Ver2 (+bounded-external-check)、Accept は text/html,application/xhtml+xml;q=0.9,*/*;q=0.5 です。本文は展開しないため Accept-Encoding: identity を付け、無圧縮の応答を要求します。
3. 301/302/303/307/308 と Location があれば最大4回まで転送を追跡します。上限を超えた場合は診断全体がエラー終了します。
4. タイムアウトは15秒、本文の上限は約2MBです。上限超過や接続失敗も診断全体のエラーになります（この項目単体の×にはなりません）。
5. TLS証明書は標準の信頼検証（rejectUnauthorized: true）で検証され、無効な証明書では接続自体が失敗します。
6. 最終応答が 403 または 429 のときは、WAFやレート制限に診断用アクセスを拒否されたものとして、レポートを作らず診断全体をエラーにします。
7. 最初の応答が2xxだった場合は、全項目の確認後にトップページをもう一度GETします（先頭4KBのみ、タイムアウト8秒）。この時点で403・429または無応答に変わっており、かつ直前まで診断中の同じオリジンへの応答も403・429または無応答が続いていた場合は、診断中に制限が作動して結果が不正確になるため、同じく診断全体をエラーにします（最後の再取得だけが拒否された場合は、制限の開始が診断の後とみなし、そのままレポートを返します）。

判定条件

• 根拠欄には HTTP 200 のように最終ステータスを表示し、改善文は「意図しない4xx/5xx応答を解消してください。」です。
• スコアは「pass=1.00、warn=0.45、fail=0」の係数を重みに掛け、対象外（na）を除いた重みの合計で割って100点満点に換算します。

自治体サイトでの判定例

トップページが正常応答しないとどんなリスクがあるか

• 住民サービスの停止：災害時・緊急時に自治体サイトが応答しないと、避難情報などの提供が途絶えます。
• エラー応答からの情報漏えい：5xxのエラーページにスタックトレース、SQL文、ファイルパス、フレームワークのバージョンが含まれると、攻撃者に内部構成を教えることになります（CWE-209）。エラーページの中身は「エラー応答のデバッグ情報」で別に確認します。
• 設定不備の兆候：証明書更新後のバーチャルホスト設定漏れ、移行時のドキュメントルート誤り、.htaccess の記述ミス（Apache/LiteSpeedで500）などは、別の防御設定（ヘッダー、アクセス制限）も同時に失われていることが多く、二次的な脆弱性につながります。
• 診断結果全体の信頼性低下：エラーページに対する判定になるため、実際のページのヘッダーやCookieが評価されません。

トップページが4xx・5xxを返すときの原因の調べ方と対策（Apache・nginx・IIS・Next.js）

1. 原因の切り分け（curl）

# ステータスと転送経路を確認（-L で転送追跡、-I でヘッダーのみ）
curl -sSIL https://www.city.example.lg.jp/

# User-Agent依存かどうかを確認
curl -sS -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0" https://www.city.example.lg.jp/
curl -sS -o /dev/null -w "%{http_code}\n" -A "MiniParse-Security-Review/Ver2" https://www.city.example.lg.jp/

User-Agentで結果が変わる場合は、WAF・CDNのBot対策ルールが原因です。診断が「アクセスを拒否しました（HTTP 403）」などのエラーで中止された場合もこれに当たります。どちらでも4xx/5xxなら、サーバーのエラーログを確認します。

2. Apache / LiteSpeed（.htaccess）

500の典型原因は .htaccess の未対応ディレクティブです（例：LiteSpeedやCGI/FPM環境での php_value）。変更直後に500になったら、直前の差分を戻して確認します。

# エラーページは詳細を出さない独自ページへ
ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.html

# メンテナンス時は503とRetry-Afterを返す（恒久運用しない）
# RewriteEngine On
# RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
# RewriteRule ^ - [R=503,L]
# Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 503"

3. nginx

server {
    listen 443 ssl;
    server_name www.city.example.lg.jp;
    root /var/www/html;
    index index.html index.php;

    error_page 404 /errors/404.html;
    error_page 500 502 503 504 /errors/50x.html;
    location = /errors/50x.html { internal; }
}

root や index の誤りでトップが403/404になることがあります。nginx -t で構文確認してから reload してください。

4. IIS

web.config の <httpErrors errorMode="DetailedLocalOnly"> を使い、外部には詳細エラーを出さない設定にします。既定ドキュメント（<defaultDocument>）にトップページのファイル名が含まれているかも確認します。

5. Next.js（Vercel）

app/not-found.tsx と app/error.tsx を用意し、例外時も詳細を出さないページを返します。トップで例外が出る場合は Vercel の Functions ログで原因を確認します。

6. CMS

CMS更新・プラグイン追加後の500は、PHPのバージョン非互換が多い原因です。ステージング環境で更新を検証し、本番では詳細エラー表示（display_errors）を無効にしてください。

7. 外形監視の導入（再発防止）

一時的な障害は診断のタイミングによって見逃されます。トップページと主要ページ（防災・お知らせ）のステータスを定期的に確認する外形監視を導入し、2xx以外が続いたら担当者へ通知する運用にすると、証明書更新漏れやCMS更新後の不具合を早期に発見できます。簡易的には、次のようなスクリプトをcronで5分ごとに実行する方法もあります。

#!/bin/sh
URL="https://www.city.example.lg.jp/"
CODE=$(curl -sS -o /dev/null -w "%{http_code}" --max-time 15 -L "$URL")
case "$CODE" in
  2??) exit 0 ;;
  *) echo "$(date '+%F %T') $URL returned $CODE" >> /var/log/site-monitor.log ;;
esac

監視の通知先は、休日・夜間でも確認できる連絡体制（委託事業者を含む）と合わせて決めておきます。

確認方法と注意点

• 修正後に curl -sSIL で最終行が HTTP/2 200 などになることを確認します。
• WAFの例外設定は「診断ツールだけを許可する」のではなく、通常ブラウザと同じ基準で正しく表示されるかを確認するのが本来の目的です。過剰なブロックで住民が閲覧できない状態がないか、アクセスログも確認してください。
• 長期のメンテナンス表示は200ではなく503＋Retry-After が適切です。ただし、恒久的に503のままにしないでください。
• エラー応答に付くセキュリティヘッダーが通常ページとそろっているかは「エラー応答のヘッダー整合性」で確認します。

よくある質問（FAQ）

参考資料

• RFC 9110 HTTP Semantics（Status Codes、Content-Type）
• OWASP Web Security Testing Guide
• OWASP ASVS（Application Security Verification Standard）

「トップページが正常応答」と関連する診断項目

• HTTPからHTTPSへ転送high
• 存在しないURLのステータスmedium
• エラー応答のデバッグ情報high
• エラー応答のヘッダー整合性medium
• OPTIONSが示す不要・危険なHTTPメソッドmedium
• 外部URLパラメータへのオープンリダイレクトhigh