弱点補強 — HTTP キャッシュと CDN：他人のページが返る × 鍵の設計 × 期限切れの殺到 × 価格切替をまたぐ古い表示

概要

数値はすべて手元の nginx 1.31.6＋Python origin での実測（3回の範囲）。会員・価格・問い合わせ件数は架空。Cloud CDN では測っていない。

問題

MOps 販促システムチームは、10月1日 12:00 の秋セール開始に合わせてアプリ会員に push 通知を送る。過去の同規模の配信では通知直後に LP（/campaign/autumn）へ 420 req/s が集中し、origin の p99 が 2 秒を超えた。その対策として origin の前にキャッシュ層を入れた（本番は Cloud CDN、受け入れ検証は nginx proxy_cache）。

LP は会員ごとに中身が違う（「こんにちは ○○ さん・保有ポイント・あなた専用クーポンコード」）。セール価格 7,980 円は 10月3日 23:59:59 で終わり、以後は通常価格 9,980 円。

push 通知のリンクは /campaign/autumn?utm_source=push&utm_campaign=autumn2026&utm_content=<会員ID>（会員ごとに違う）。

後輩A「キャッシュの鍵に $cookie_sid を足せば会員ごとに別々にキャッシュされるので漏れません。1行で直ります」
後輩B「個人情報が絡むページにキャッシュは怖いので、LP は全部 no-store にして Pod を3倍に」

設問

1. Bad の問題点を 7 つ以上（何が誰に起きるか、関係する仕様）
2. ステージングの受け入れテストが全件緑だった理由
3. 後輩A・B の提案を測って評価
4. 改善後の origin コードとキャッシュ層の設定（価格切替をまたいで旧価格を出さない）
5. Bad に流すと赤になるテスト（本物のキャッシュ層を挟んで）
6. 監視・切替条件・既に起きた漏えいへの対応（法令上の報告の要否を含む）

制約・前提条件

• origin は Python 3.12+。キャッシュ層は本番 Cloud CDN、検証は nginx。どちらか一方の挙動に依存した安全性は避ける
• 会員ごとの部分（名前・ポイント・クーポン）は消せない（「あなた専用」表示が CVR を上げると分かっている）。utm_* も計測チームが使うので消せない
• セール価格は終了時刻を1秒でも過ぎたら出さない（表示とカートの食い違いは問い合わせと、景品表示法の有利誤認の疑いにつながる）
• CDN の invalidation は反映に数分かかり回数制限もあるため、通常運用の前提にしない

Bad → Good（対比）

# ミドルウェア: 全 GET にキャッシュヘッダ
if path.startswith("/api/"):
    headers["Cache-Control"] = "max-age=60"   # Authorization 付きは保存されないはず
else:
    headers["Cache-Control"] = f"public, max-age={LP_TTL}"  # 300
    headers["Vary"] = "User-Agent"

# LP: Cookie で会員を引いて名前・クーポンを埋め込む
greeting = f"こんにちは {member['name']} さん ... {member['coupon_code']}"
price = SALE_PRICE_YEN if time.time() < SALE_END else REGULAR_PRICE_YEN
headers["Set-Cookie"] = f"sid={member['sid']}; ..."

# nginx
proxy_cache_key $scheme$host$request_uri;
proxy_ignore_headers Set-Cookie;
# proxy_cache_lock 未設定（既定 off）

headers.setdefault("Cache-Control", "private, no-store")

# LP の外枠: Cookie・クエリ・UA を読まない
'<div id="me" data-src="/api/me/summary"></div>'
policy = SharedCachePolicy.until_next_change(now, next_price_change(now))
"public, max-age=0, s-maxage=≤60, stale-while-revalidate=≤30, stale-if-error=≤600"

# /api/me/*: private, no-store（既定のまま）。Set-Cookie はここだけ

# nginx
location / { proxy_pass http://origin; }
location /campaign/ {
  proxy_cache_key $scheme$host$uri;
  proxy_cache_lock on; proxy_cache_background_update on;
  proxy_no_cache $http_authorization;
}

設計の図（SVG）

鍵（何が同じなら同じ応答とみなすか）と、中身を変える入力の一覧を一致させるのが設計の中心。Bad は「Cookie が鍵に無いのに中身を変える」（粗すぎ）と「utm が鍵にあるのに中身を変えない」（細かすぎ）の両方を持っていた。

ヒント（段階的開示）

📋 コピーclass SharedCachePolicy:              # 共有キャッシュに保存してよい応答の寿命（値オブジェクト）
    s_maxage: int
    stale_while_revalidate: int
    stale_if_error: int

    @classmethod
    def until_next_change(cls, now, next_change):
        remaining = floor(next_change - now) - 時計の余裕   # ← nginx の時計は秒単位
        ttl = min(基準 TTL, remaining)
        room = remaining - ttl                               # stale もこの中に収める
        ...

def _send(...):
    headers.setdefault("Cache-Control", "private, no-store")  # 既定は保存させない

問題点分析（8点）

受け入れテストが緑だった理由

QA は push リンクから 200 人分を開いた。push リンクは会員ごとに違う utm_content を持つので鍵が全員違い、全員ミス。一度もヒットしないから漏れもしなかった。

後輩の提案の評価（実測）

1,000 訪問 × 3 回。後輩A は nginx の鍵だけ書き換えて測定（sim_proposalA_out.txt）。

後輩A: 採らない

• 直る: LP の漏えいと Cookie の受け渡し
• 直らない: API の漏えい（アプリは Bearer で呼ぶので Cookie を鍵に足しても API の鍵は全員同じ）
• 新たに壊れる: ヒット率 0%（1 人 1 回しか開かない LP を会員ごとに保存しても 2 回目が来ない）。origin の処理時間は Bad より 4 割増。キャッシュ容量が会員数×UA 数に比例。安全性が「鍵に Cookie 名を正しく書いたか」という前段の 1 行に依存

後輩B: 正しさは本物。ただし費用で採らない

• 直る: 漏えいはすべて止まる（no-store はどの前段も保存しない）。価格の誤表示も直る
• 代償 導出: 420 req/s × 描画 30 ms ＝毎秒 12.6 秒分の CPU。Good は描画 60 秒に 1 回＋会員 API 420 × 3 ms ＝毎秒 1.26 秒分で、約 10 分の 1（30 ms・3 ms はどちらも仮定）
• 危ないのは「会員ごとの応答を共有すること」で、キャッシュそのものではない。no-store にする範囲は会員 API だけで済む

改善後コード（Good）

設計表: 応答を 3 種類に分け、それぞれ「中身を変える入力」と Cache-Control を 1 対 1 に決める。

origin_good.py（要点。全 162 行はコードディレクトリ）

📋 コピーSHARED_TTL_SEC = int(os.environ.get("LP_TTL", "60"))  # 共有キャッシュの基準寿命
STALE_WHILE_REVALIDATE_SEC = 30    # 期限切れ後、裏で取り直す間に古い版を返してよい秒数
STALE_IF_ERROR_SEC = 600           # origin 障害時に古い版を返してよい秒数（10 分）
MIN_CACHEABLE_SEC = 1              # これ未満しか残っていなければ保存させない
# 共有キャッシュの時計は秒単位で、期限の比較も秒単位。実測で切替後 0.3 秒まで旧価格が出たため 1 秒手前で切る
CACHE_CLOCK_MARGIN_SEC = 1
PRIVATE_NO_STORE = "private, no-store"


@dataclass(frozen=True, slots=True)
class SharedCachePolicy:
    """共有キャッシュ（CDN・nginx）に保存してよい応答の寿命。

    完全コンストラクタ: 寿命が負になる・stale が切替時刻を越える組み合わせは作れない。
    """

    s_maxage: int
    stale_while_revalidate: int
    stale_if_error: int

    def __post_init__(self) -> None:
        if min(self.s_maxage, self.stale_while_revalidate, self.stale_if_error) < 0:
            raise ValueError(f"negative lifetime: {self}")

    @classmethod
    def until_next_change(cls, now: float, next_change: float | None) -> SharedCachePolicy | None:
        """次の内容の切替時刻を越えない寿命を決める。

        Args:
            now: 現在の UNIX 時刻。
            next_change: 次に表示内容（価格など）が変わる UNIX 時刻。予定が無ければ None。

        Returns:
            寿命。切替まで MIN_CACHEABLE_SEC 未満しか無ければ None（保存させない）。
        """
        if next_change is None or next_change <= now:
            return cls(SHARED_TTL_SEC, STALE_WHILE_REVALIDATE_SEC, STALE_IF_ERROR_SEC)
        remaining = math.floor(next_change - now) - CACHE_CLOCK_MARGIN_SEC
        if remaining < MIN_CACHEABLE_SEC:
            return None
        ttl = min(SHARED_TTL_SEC, remaining)
        room = remaining - ttl
        return cls(ttl, min(STALE_WHILE_REVALIDATE_SEC, room), min(STALE_IF_ERROR_SEC, room))

    def header(self) -> str:
        # max-age=0: ブラウザには保存させない（ブラウザの中身は私たちから消せないため）
        return (f"public, max-age=0, s-maxage={self.s_maxage}, "
                f"stale-while-revalidate={self.stale_while_revalidate}, stale-if-error={self.stale_if_error}")


class Handler(BaseHTTPRequestHandler):
    def _send(self, status: int, body: bytes, headers: dict) -> None:
        headers.setdefault("Cache-Control", PRIVATE_NO_STORE)
        ...

    def _campaign_shell(self) -> tuple[int, bytes, dict]:
        """誰が見ても同じ LP の外枠。Cookie・クエリ・User-Agent を一切読まない（読まないから共有できる）。"""
        time.sleep(RENDER_SEC)
        now = time.time()
        price = SALE_PRICE_YEN if now < SALE_END else REGULAR_PRICE_YEN
        body = ("<html><body><h1>秋のセール</h1>"
                '<div id="me" data-src="/api/me/summary"></div>'   # 会員ごとの部分はブラウザが別に取りに行く
                f'<p class="price">{price:,} 円</p></body></html>').encode()
        policy = SharedCachePolicy.until_next_change(now, next_price_change(now))
        headers = {"Content-Type": "text/html; charset=utf-8",
                   "Cache-Control": policy.header() if policy else PRIVATE_NO_STORE}
        return 200, body, headers

    def _personal(self, member: dict | None, refresh_session: bool) -> tuple[int, bytes, dict]:
        """会員ごとの応答。Cache-Control は既定の private, no-store のまま（_send が付ける）。"""
        ...
        if refresh_session:
            headers["Set-Cookie"] = f"sid={member['sid']}; Path=/; Max-Age=1800; HttpOnly; Secure; SameSite=Lax"
        return 200, body, headers

nginx_good.conf（要点）

📋 コピー# 既定: 保存しない（proxy_cache を書かない location は一切キャッシュされない）
location / {
    proxy_pass http://origin;
}
# 保存してよいのは、誰が見ても同じ中身だと origin が約束したページだけ
location /campaign/ {
    proxy_pass http://origin;
    proxy_cache edge;
    proxy_cache_key $scheme$host$uri;        # utm_* は鍵に入れない。LP はクエリで中身を変えない契約
    proxy_cache_lock on;                     # 期限切れの瞬間に origin へ行くのは 1 本だけ
    proxy_cache_lock_timeout 3s;
    proxy_cache_lock_age 3s;
    # stale の可否は origin のヘッダだけで決める。proxy_cache_use_stale を書くとヘッダより優先され、
    # 価格の切替時刻を越えて古い価格を出す
    proxy_cache_background_update on;
    proxy_no_cache $http_authorization;      # 多層防御（nginx は RFC 9111 §3.5 を自分では守らない）
    proxy_cache_bypass $http_authorization;
}

Cloud CDN 対応表（本番へ持ち込むとき）

テストと変異（本物の nginx を起動して叩く）

📋 コピーdef test_second_member_never_sees_first_members_data(stack):
    _page_for(stack, ALICE)                     # Alice が先に開いて、キャッシュが温まる
    body, _ = _page_for(stack, BOB)             # 同じ URL を Bob が開く
    assert ALICE["member_id"] not in body
    assert ALICE["coupon_code"] not in body


@pytest.mark.parametrize("path,auth", [("/api/me/summary", "cookie"), ("/api/me/coupons", "bearer")])
def test_personal_responses_declare_private_at_origin(stack, path, auth):
    """nginx を通さず origin を直接見る（変異3で緑のまま通った穴）。"""
    ...
    assert {"private", "no-store"} <= directives

実行例（input → output。実測）

SharedCachePolicy.until_next_change（基準 TTL 60 秒）

切替まで 3600 秒 → public, max-age=0, s-maxage=60, stale-while-revalidate=30, stale-if-error=600
切替まで   95 秒 → public, max-age=0, s-maxage=60, stale-while-revalidate=30, stale-if-error=34
切替まで    8.4 秒 → public, max-age=0, s-maxage=7, stale-while-revalidate=0, stale-if-error=0
切替まで    1.5 秒 → private, no-store（保存させない）
切替の後（予定なし） → public, max-age=0, s-maxage=60, stale-while-revalidate=30, stale-if-error=600

S3 の代償: 切替前の約 2 秒は no-store なので全部 origin へ。本番 420 req/s なら約 840 本 × 30 ms ≒ 25 秒分の CPU が 2 秒に集中する 導出。

迷った案と採らなかった理由

直した後に見るもの・止め方・事後対応

ポイント解説

1. 鍵に無い入力で中身が変わる応答は、必ず他人に返る: 漏えい件数はヒット件数と同じ（344〜345）。逆に中身を変えない utm が鍵にあったせいでヒット率 34% に落ち、受け入れテストで漏えいが見えなくなった
2. 安全性を前段の挙動に預けない: nginx は §3.5 を守らない、Cloud CDN は stale-if-error を無視する。origin の private, no-store を唯一の拠り所にし、前段の許可リストは二層目
3. 既定は保存させない、共有してよい応答だけが名乗る: public を付ける道を SharedCachePolicy 1 か所に閉じた。新しい URL を足したときに安全側に倒れる
4. 期限は時刻で切る。測ると前段の時計の粒度が出てくる: floor だけでは 21 件の旧価格。1 秒の余裕は仕様を読むだけでは出ず、測って初めて出た
5. 多層防御の一層が効くと、もう一層の故障がテストに出ない: 層ごとに単独で検査する

実務への応用

• 全 GET を棚卸し: 「URL・中身を変える入力・Cache-Control・前段で保存されるか」を 1 行ずつ。Cookie／Authorization で中身が変わるのに private でない行が候補
• 受け入れテストに「2 人目」: 同じ URL を別の会員で 2 回目に開く。ステージングの Cloud CDN に向けて流す
• Terraform で固定: cdn_policy.cache_mode = "USE_ORIGIN_HEADERS"、include_query_string = false。FORCE_CACHE_ALL を OPA（conftest）で禁止
• 可観測性: DataDog で「cache HIT かつ Set-Cookie あり」の件数（0 が正常）。OTel スパンに http.response.header.cache-control
• 証券会社の経験: 株価ボードの気配は全員で共有、口座残高は口座ごと。混ぜたまま配信を速くすると、他人の残高が見える事故になる

扱わなかった範囲・一次資料

• Cloud CDN 上での実測 — nginx だけで測った。Authorization・stale-if-error・Vary・serve-while-stale の扱いが違う。本番前にステージングで同じ sim とテストを流す
• Web Cache Deception（Omer Gil, Black Hat USA 2017）・Web Cache Poisoning（James Kettle, 2018）— 原理は同じ「鍵に無い入力」だが攻撃者側の話なので別の回に
• bfcache・Service Worker — ログアウト後の表示は別に確かめる
• 景品表示法・個人情報保護法の最終判断 — 技術側の要件と条文の該当可能性にとどめ、判断は法務

参照日 2026-10-04。
RFC 9111 HTTP Caching（§3.5, §5.2.2.7, §5.2.2.10）https://www.rfc-editor.org/rfc/rfc9111.html
RFC 5861 stale-while-revalidate / stale-if-error https://www.rfc-editor.org/rfc/rfc5861
nginx ngx_http_proxy_module https://nginx.org/en/docs/http/ngx_http_proxy_module.html（Set-Cookie 付きは既定で保存しない、lock_timeout 後の応答は保存しない、ヘッダの stale 指定は設定より優先度が低い。Authorization による保存禁止の記述なし）
Cloud CDN caching overview https://docs.cloud.google.com/cdn/docs/caching（FORCE_CACHE_ALL の警告、coalescing 既定有効、serve-while-stale 既定 86,400 秒、stale-if-error は効かない）
Steam 2015-12-25 キャッシュ事故（約 34,000 人のページが他人に表示）The Register https://www.theregister.com/2015/12/30/steam_security_blip_explained/ ／ SteamDB https://steamdb.info/blog/recent-caching-issues-on-steam/
個人情報保護委員会 漏えい等の対応 https://www.ppc.go.jp/personalinfo/legal/leakAction/ ／ 通則編ガイドライン 3-5 https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/

今日のまとめ

キャッシュの鍵に無い入力（Cookie・Authorization）で中身を変える応答は、必ず他人に返る。会員ごとの部分を別 URL の private, no-store に出し、「誰が見ても同じ」外枠だけが寿命を名乗る形にすると、漏えい 0 件のまま LP ヒット率は 34% から 99.9% に上がった（実測、1,000 訪問）。寿命は価格の切替時刻で切り、前段の時計の粒度ぶん（1 秒）手前に余裕を取る。

自己評価（あとで記入）