Webアプリを作るとき、画面の表示を速くしたり、ログイン状態を保ったりするために
「キャッシュ」や「Cookie」を使うことが多いと思います。
しかし、この2つを間違った設定で使うと、
「他の人に自分の情報が見えてしまう」「勝手にログインされた」
といった重大なセキュリティ事故につながります。
1. キャッシュとCookieの役割の違い
まずはキャッシュとCookieの違いを確認しておきます。
| 主な役割 | 保存場所 | 危険になるケース | |
|---|---|---|---|
| キャッシュ | 一度取得したデータを再利用して、表示を速くする | ブラウザ、アプリ、CDNなど | 機密情報をキャッシュしてしまう |
| Cookie | ユーザーを識別するための小さなデータ（ログイン情報など） | ブラウザ | 他人にCookieを盗まれる、意図しない送信 |
端的に言うと、
- キャッシュは「速さ」のための仕組み
- Cookieは「あなたが誰か」を示す仕組み
この2つは混同されがちですが、同じ感覚で使うとセキュリティ上の問題が起こりやすくなります。
2. キャッシュの安全な使い方
キャッシュはとても便利ですが、どの情報をキャッシュしていいかが明確でないと危険です。
（1）キャッシュしていい情報・してはいけない情報
| キャッシュしてもよい？ | 例 | |
|---|---|---|
| 公開情報 | ⭕️ | トップページ、商品一覧、画像など |
| 個人情報 | ❌ | マイページ、購入履歴、会員情報など |
| 認証が必要なページ | ❌ | ログイン後のダッシュボードなど |
（2）キャッシュを制御するヘッダ
サーバーはレスポンスに「Cache-Control」というヘッダをつけて、
「このデータをキャッシュしていいか」「どれくらい保存していいか」を指定します。
| 設定例 | 意味 | 使う場面 |
|---|---|---|
Cache-Control: no-store, private |
一切キャッシュしてはいけない | ログイン後ページ、個人情報ページ |
Cache-Control: public, max-age=300 |
5分間キャッシュしてよい | 公開データやニュース一覧など |
Cache-Control: public, max-age=31536000, immutable |
1年間キャッシュしてよい（変更されない） | 画像、CSS、JavaScriptなど |
ちなみに...
no-cache という設定は「保存禁止」ではなく、「保存してもいいが、使う前に必ず確認する」という場合に使用します。
保存自体を禁止したい場合は no-store を使います。
（3）ログアウト時のキャッシュ削除
ログアウトした後に、ブラウザの戻るボタンを押したら
「まだマイページが見えてしまう」という経験はありませんか？
これは、ブラウザが古いページをキャッシュから表示している影響です。
これを防ぐために、以下のようなヘッダを返すことで
キャッシュやCookieを強制的に削除できます。
Clear-Site-Data: "cache","cookies","storage"
3. Cookieの安全な使い方
Cookieは「ログインしている人を区別する」「設定を保存する」ための仕組みです。
しかし、Cookieは悪意のあるサイトやスクリプトに悪用されることもあります。
（1）Cookieを安全にするための設定
| 設定項目 | 推奨設定 | 説明 |
|---|---|---|
Secure |
付ける | HTTPS通信のときだけCookieを送信 |
HttpOnly |
付ける | JavaScriptからアクセスできない（XSS対策） |
SameSite |
Lax または Strict
|
他サイトからの送信を制限（CSRF対策） |
Max-Age / Expires
|
短めに設定 | 有効期限が長すぎるとリスクが高まる |
（2）SameSite の違い
| 値 | 他サイトから送信される？ | 主な用途 |
|---|---|---|
Strict |
されない | セキュリティ重視のアプリ（銀行など） |
Lax |
通常のリンクでは送信されるが、フォーム送信では送られない | 一般的なWebアプリ |
None; Secure |
他サイトからも送信される（ただしHTTPSのみ） | シングルサインオン（SSO）など特殊用途 |
2025年現在、主要ブラウザではSameSiteを指定しないと自動的にLax扱いになります。
つまり、以前よりもセキュリティは強化されていますが、
外部サービスとの連携が動かなくなるケースもあります。
（3）Cookieの範囲を広げすぎない
Domain や Path の設定を広げすぎると、
本来アクセスしてほしくないページからもCookieが送られることがあります。
安全のためには、以下が重要だと思います。
- できるだけドメインやパスを限定する
- 不要なCookieは使わない
4. キャッシュとCookieの「組み合わせ」によるトラブル
-
ログアウト後もページが残って見える
→ キャッシュを禁止 (no-store) にしていない。
→ 対策：Cache-Control: no-store, privateとClear-Site-Data。 -
他人のセッションが見えてしまう
→ Cookieを含むレスポンスをキャッシュしてしまった。
→ 対策：Cookieを返すレスポンスは必ずprivateまたはno-store。 -
外部サービスの連携が動かない
→SameSite=LaxでCookieが送られない。
→ 対策：安全なHTTPS通信でSameSite=None; Secureを指定。
5. 安全な設定の組み合わせ例
ログインがあるWebアプリ
| 設定 | |
|---|---|
| Cookie | Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=3600 |
| ページのキャッシュ | Cache-Control: no-store, private |
| 静的ファイル | Cache-Control: public, max-age=31536000, immutable |
| ログアウト時 | Clear-Site-Data: "cache","cookies","storage" |
一般的な公開サイト（ログインなし）
| 設定 | |
|---|---|
| Cookie | 基本的に不要 |
| ページのキャッシュ | Cache-Control: public, max-age=60 |
| 画像・JS | Cache-Control: public, max-age=31536000, immutable |
6. チェックリスト
-
認証が必要なページには
Cache-Control: no-storeを設定しているか -
Cookie に
SecureとHttpOnlyがついているか -
SameSiteの設定を意識して選んでいるか -
ログアウト時にキャッシュやCookieが残っていないか
-
CDN（キャッシュサーバー）が Cookie を含むレスポンスを保存していないか
7. まとめ
キャッシュとCookieは、アプリの使いやすさや速度を高めるために欠かせません。
「速いけれど安全ではない」ではなく「速くて安全なアプリ」を開発するためには、
次の3つを意識する必要があります。
-
キャッシュしていい情報と、してはいけない情報を分ける
-
Cookieには常に安全属性（Secure, HttpOnly, SameSite）をつける
-
ログアウトや権限変更時にはキャッシュを消す
採用情報
アシストエンジニアリングでは一緒に働くフロントエンド、バックエンドエンジニアを募集しています！
少しでも興味のある方は、カジュアル面談からでもお気軽にお話ししましょう！
お問い合わせはこちらから↓
https://official.assisteng.co.jp/contact/