Cache key, Vary & kebocoran antar pembaca

Cache key menentukan respons mana yang dianggap sama. Kalau ia tidak memasukkan sesuatu yang membuat respons berbeda, pembaca akan melihat halaman milik orang lain.

Cache key bawaan

https://portal.contoh.id/berita/rupiah-menguat?hal=2
└──────────────────────┘└─────────────────────┘└─────┘
        host                    jalur           query

TIDAK termasuk: cookie, Authorization, User-Agent, Accept-Language

Skenario kegagalan

1. Member A membuka /akun. Respons berisi namanya, saldonya, riwayat tagihannya.
2. Cache Rule keliru menandainya "eligible for cache".
3. Cloudflare menyimpannya dengan key: portal.contoh.id/akun
4. Member B membuka /akun.
5. Cache HIT. Member B melihat data Member A.

Kenapa Vary: Cookie bukan jawabannya

// Terlihat masuk akal. Tidak menyelesaikan masalah.
res.headers.set("Vary", "Cookie");

Aturan yang benar dan sederhana: respons personal tidak di-cache di edge sama sekali. Bukan di-cache dengan pemisahan yang cerdik — tidak di-cache.

Pertahanan berlapis

// Lapis 1: kode halaman
setCache(Astro.response, "personal");   // → private, no-store

// Lapis 2: middleware, untuk halaman yang lupa
if (jalurPersonal(ctx.url.pathname)) {
  res.headers.set("Cache-Control", "private, no-store");
}

// Lapis 3: Cache Rule bypass untuk jalur personal (aturan 1 di materi sebelumnya)
// Lapis 4: Cache Rule bypass saat cookie sesi ada

Empat lapis untuk satu aturan terdengar berlebihan sampai kamu mempertimbangkan konsekuensinya. Halaman baru akan ditambahkan oleh orang yang tidak membaca materi ini; lapis 2 sampai 4 melindungi dari itu.

Pemisahan cache yang sah

Ada kasus di mana memisahkan cache memang benar — yang membedakannya: pemisahannya berdasarkan kelompok, bukan berdasarkan identitas.

Cache Key → Custom:
  ☑ Device Type          (mobile / desktop / tablet)
  ☐ Cookie
  ☐ Header
  ☑ Query String: ignore utm_*, fbclid, gclid

Bahaya yang berlawanan: Set-Cookie yang ter-cache

// BAHAYA: menyetel cookie di halaman yang boleh di-cache
Astro.cookies.set("pengunjung", id, { maxAge: 86400 });
setCache(Astro.response, "artikel");     // ← publik!

Kalau Cloudflare meng-cache respons ini beserta header Set-Cookie-nya, maka setiap pembaca berikutnya menerima cookie yang sama. Untuk cookie pengunjung, itu berarti analitikmu menghitung sejuta orang sebagai satu. Untuk cookie sesi, itu berarti pengambilalihan akun massal.

Cloudflare secara bawaan tidak akan meng-cache respons yang punya Set-Cookie — itu perlindungan yang bagus. Tapi Cache Rule yang memaksa "Eligible for cache" bisa menimpanya. Jadi: halaman yang di-cache tidak boleh menyetel cookie apa pun. Kalau butuh, setel dari server island yang memang tidak di-cache.

Audit

U=https://portal.contoh.id

# Tidak boleh ada Set-Cookie pada halaman publik
curl -sI $U/berita/artikel-uji | grep -i set-cookie   # harus kosong
curl -sI $U/                   | grep -i set-cookie   # harus kosong

# Jalur personal harus BYPASS, apa pun cookie-nya
for p in /akun /akun/tagihan /langganan; do
  printf '%s → ' "$p"
  curl -sI "$U$p" -H 'Cookie: __Host-sesi=uji' | grep -i cf-cache-status
done

# Uji kebocoran: dua cookie berbeda, bandingkan isinya
curl -s $U/akun -H 'Cookie: __Host-sesi=A' -o /tmp/a.html
curl -s $U/akun -H 'Cookie: __Host-sesi=B' -o /tmp/b.html
diff -q /tmp/a.html /tmp/b.html    # HARUS berbeda