機密ページのキャッシュ制御とは？Cache-Control: no-storeの必要性・診断基準・設定方法

機密ページのキャッシュ制御とは（Cache-Control: no-store）

機密ページのキャッシュ制御とは、ログイン画面、管理画面、マイページのように個人や業務の情報を表示するページの応答に Cache-Control: no-store を付け、ブラウザやプロキシ、CDNに保存させないようにすることです。セキュリティAIチェッカーはこの項目（headers.cache）で、診断対象として入力されたURLがログイン・管理・アカウント系のページである場合に、応答に Cache-Control: no-store が付いているかを確認します。

ブラウザやプロキシ、CDNは、表示を速くするためにWebページの応答を保存（キャッシュ）します。公開情報なら問題ありませんが、機密ページがキャッシュされると、共用端末の後の利用者や、経路上のキャッシュサーバーを通じて第三者に表示されるおそれがあります。

no-store・no-cache・privateの違い（Cache-Controlの主な指示子）

MDNは「no-cache は『キャッシュするな』という意味ではない」と注意し、応答を保存させたくない場合は no-store を使うよう明記しています。WSTG-ATHN-06も、機密情報を含むページでは Cache-Control: no-store を設定すること、no-store を使えば must-revalidate、max-age、Expires などの追加指示は現代のブラウザでは一般に不要であることを示しています。

キャッシュ制御についてよくある誤解

• 「HTTPSならキャッシュされない」：HTTPSの応答もブラウザやCDN（TLS終端後）にキャッシュされます。
• 「Pragma: no-cache で十分」：Pragma はHTTP/1.0時代の要求ヘッダー向けの仕組みで、応答での効果は保証されません。Cache-Control を使ってください。
• 「HTMLの <meta http-equiv="Cache-Control"> で指定できる」：metaタグはHTTPキャッシュの判定に使われません。必ずHTTP応答ヘッダーで指定します。

「戻る」ボタンとbfcache：no-storeだけでは足りない場面

ブラウザには、直前のページを丸ごとメモリに保持して「戻る」を瞬時にする bfcache（Back/Forward Cache）があります。MDNは、no-cache は「戻る」等の履歴ナビゲーションでの再検証を保証しないと注意しています。

従来、ページ本体に Cache-Control: no-store が付いている場合、ブラウザはそのページをbfcacheに保存しませんでした。しかしChromeは、2025年3〜4月に全利用者への展開を完了した変更により、no-store のページもbfcacheへ保存するようになりました。ただし、Cookie等の認証状態が変化した場合はbfcacheから破棄され、保持時間も3分に短縮されます。

したがって、ログアウト時にセッションCookieを確実に削除することが、「戻る」で個人情報を再表示させないための前提になります。web.devは、pageshow イベントで認証用Cookieの有無を確認し、なければ再読み込みする実装も紹介しています。HTTPキャッシュ（ディスク・共有キャッシュ）への保存を防ぐ基本対策は、引き続き no-store です。

公開ページにno-storeは不要

no-storeを全ページに付けると、表示速度の低下、サーバー負荷の増加、bfcacheが効かないことによる体験の悪化を招きます。web.devも、no-store は機密情報を含むページに限定し、常に最新を表示したいだけのページには no-cache や max-age=0 を使うよう推奨しています。公開ページが対象外（na）になっているのはこのためです。

機密ページのキャッシュ制御の診断基準（セキュリティAIチェッカー）

取得対象

• 入力URLへのGET（リダイレクト最大4回追跡）で得た最終URLのパスと、その応答の Cache-Control ヘッダー。
• ログインページへリダイレクトされる管理画面URLを入力した場合は、リダイレクト後のログインページが評価対象になります。

機密ページとみなす条件

最終URLのパスに、次のいずれかの区切られた語が含まれる場合（大文字小文字を区別しない）。

• 対象語：admin、login、signin、sign-in、account、mypage、my-page
• 語の直前は /。語の直後は、/、パスの末尾、または「.php .html .htm .asp .aspx .jsp .cgi の拡張子でパスが終わる」のいずれか
• クエリ文字列は判定に使いません

判定条件

• 根拠欄には観測した Cache-Control の値（ない場合は「Cache-Controlがありません。」）を表示します。公開ページの対象外では「公開ページのため、この項目は対象外です。」と表示します。
• 入力URLの応答が403または429の場合は、アクセスが制限されたものとして診断全体がエラーになり、レポートは生成されません。
• トップページ（/）を入力した通常の診断では対象外になります。巡回で見つかったログイン・管理系ページは、関連項目「認証関連ページのno-store」が同じパス条件・同じ2xx条件で評価します。

自治体サイトでの判定例

機密ページがキャッシュされるとどんなリスクがあるか

• 共用端末での情報露出：図書館や窓口の端末で、前の利用者のマイページや申請内容が「戻る」操作やキャッシュから表示される。WSTG-ATHN-06は、ログアウト後に「戻る」で機密データが表示されるケースを検査対象としています。
• CDN・プロキシでの取り違え：ログイン後のページが共有キャッシュに保存されると、別の利用者に他人の個人情報ページが配信される重大事故につながります。
• 端末内への残存：ブラウザのディスクキャッシュに個人情報を含むHTMLが残り、端末の紛失・盗難やマルウェア感染時に読み取られます。

機密ページのキャッシュ制御の設定方法（Apache・PHP・nginx・IIS・Next.js・CDN）

Apache（.htaccess）：ログイン・管理系だけに付与

<IfModule mod_headers.c>
  <If "%{REQUEST_URI} =~ m#/(admin|login|signin|sign-in|account|mypage|my-page)(/|\.php|\.html?|$)#i">
    Header always set Cache-Control "no-store"
  </If>
</IfModule>

<If> はApache 2.4以降で使えます。管理画面ディレクトリが分かれているなら、そのディレクトリの .htaccess に Header always set Cache-Control "no-store" を置くのが簡単です。

PHP（アプリケーション側）

<?php
// ログイン画面・マイページの先頭（出力前）
header('Cache-Control: no-store');

PHPのセッションを使う場合、session_cache_limiter('nocache')（既定値）で送られるヘッダーは no-store, no-cache, must-revalidate を含みます。設定で private 等に変更していないか確認してください。

nginx

location ~* ^/(admin|login|mypage)(/|$) {
    proxy_hide_header Cache-Control;   # 上流の値と二重に出力しない
    add_header Cache-Control "no-store" always;
    proxy_pass http://app_backend;
}

この例の正規表現は主要なパスだけを挙げています。signin・account や /login.php など、実際のログイン・管理系URLに合わせて追加してください。また、location 内に add_header を書くと server レベルの add_header（他のセキュリティヘッダーを含む）は継承されないため、必要なヘッダーは同じ location にも記述してください。

IIS（web.config、管理ディレクトリ配下）

<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <remove name="Cache-Control" />
        <add name="Cache-Control" value="no-store" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Next.js（Vercel）

// next.config.js
module.exports = {
  async headers() {
    return [
      { source: '/(admin|login|mypage)/:path*', headers: [{ key: 'Cache-Control', value: 'no-store' }] },
    ];
  },
};

App Routerで認証情報を使うページは動的レンダリングにし、cookies() 等を参照するとキャッシュされない応答になります。最終的な応答ヘッダーで必ず確認してください。

CDNの設定

CDN（CloudFront、Cloudflare等）では、ログイン・管理系パスを「キャッシュしない」ルールにし、オリジンの no-store を尊重する設定にします。

確認方法（curl）

curl -sI https://yoyaku.city.example.lg.jp/login | grep -i '^cache-control'
# 期待値: Cache-Control: no-store（他の指示子が併記されていても可）

設定後は、ログイン画面のURLを入力してセキュリティAIチェッカーで再診断し、本項目が ○ になったことを確認します。

サイトを壊さないための注意点（ガードレール）

• サイト全体に no-store を付けないでください。公開ページの表示速度とbfcacheが損なわれ、CDNの効果もなくなります。
• Header set と Header always set が重複すると、エラー応答とそれ以外でヘッダーが二重になることがあります。設定後は通常応答とリダイレクト応答の両方を確認してください。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V14 Data Protection
• OWASP WSTG-ATHN-06 Browser Cache Weaknesses
• RFC 9111 HTTP Caching
• MDN Cache-Control
• web.dev Back/forward cache
• Chrome for Developers「Enabling bfcache for Cache-Control: no-store」
• PHP session_cache_limiter

「機密ページのキャッシュ制御」と関連する診断項目

• 認証関連ページのno-storehigh
• Service Workerの利用を把握low
• CookieのSecure属性high
• CookieのHttpOnly属性high
• CookieのSameSite属性medium
• SameSite=NoneとSecureの組み合わせhigh
• Cookieの有効期間が過度に長くないmedium
• CookieのDomain/Path範囲medium