- Konu sahibi
- #1
Hassas sayfalarda tarayıcı önbelleği nasıl yönetilmelidir?
Hassas sayfalar; hesap paneli, sipariş ayrıntıları, kişisel bilgiler, ödeme adımları ve yönetim ekranları gibi kullanıcıya özel veri içeren sayfalardır. Bu sayfalarda en güvenli varsayılan, HTTP yanıtına
Cache-Control: no-store ekleyerek tarayıcıya ve aradaki önbelleklere yanıtı saklamamasını söylemektir. Oturum kapatma ve yetki değişikliği de sunucu tarafında oturumu geçersiz kılmalıdır; yalnızca önbellek başlıklarına güvenmek yeterli değildir.Önbellek yönergeleri nasıl çalışır?
no-store, yanıtın önbelleğe kaydedilmemesini ister. Hassas içerik için temel yönerge budur. private, yanıtın yalnızca kullanıcıya ait tarayıcı önbelleğinde tutulabileceğini, ortak proxy veya CDN gibi paylaşılan önbelleklerde tutulmaması gerektiğini belirtir; fakat veriyi tarayıcıda bırakabildiği için hassas sayfalarda tek başına yeterli değildir.no-cache adı yanıltıcıdır: Yanıtın hiç saklanmamasını değil, kullanılmadan önce sunucudan doğrulanmasını ister. Saklanması istenmeyen hassas yanıtlar için no-store uygun varsayılandır; bu başlık tek başına tüm gizlilik risklerini ortadan kaldırmaz. Pragma: no-cache ve Expires: 0 eski istemcilerle uyumluluk amacıyla eklenebilir, ancak modern istemcilerde asıl kontrol Cache-Control başlığıdır.HTTP önbelleği ile geri/ileri gezinme önbelleği (bfcache) aynı mekanizma değildir. Chrome bazı no-store sayfalarını da koşullu olarak bfcache içinde tutabilir; başlık geri düğmesinde boş ekran garantisi vermez. Bu nedenle testte hem yeni istek davranışını hem de oturum kapattıktan sonra geri düğmesine basıldığında görülen sonucu kontrol edin. Sunucu, geçersiz oturumla gelen isteklerde hassas içeriği değil, yeniden giriş yanıtını üretmelidir.
Uygulanabilir temel yapılandırma
Uygulamanızın hassas HTML yanıtlarına aşağıdaki başlıkları ekleyin:
Kod:
Cache-Control: no-store
Pragma: no-cache
Expires: 0Bunu yalnızca tarayıcı tarafında JavaScript ile yapmayın; başlık sunucu yanıtında bulunmalıdır. Uygulama katmanında merkezi bir middleware veya ortak yanıt filtresi kullanmak, bir yönetim sayfasının unutulması riskini azaltır. Giriş yapmış kullanıcıya dönen tüm kişisel HTML yanıtlarını varsayılan olarak bu politikaya almak, tek tek sayfa seçmekten daha güvenlidir.
İstemciye ulaşan başlıkları kontrol etmek için örnek istek:
Kod:
curl -sS -D - -o /dev/null https://example.com/accountBu örnek Linux/macOS içindir; Windows’ta curl.exe ve gövde hedefi olarak NUL kullanılabilir. Oturumsuz curl yalnız giriş sayfasını veya yönlendirmeyi görebilir. Asıl kişisel yanıtı, test hesabıyla giriş yapılmış tarayıcının Network panelinden kontrol edin; oturum çerezini paylaşmayın. Çıktıda no-store varsa yalnız o yanıtın temel başlığı doğrulanmıştır. Başlık yoksa veya yalnızca
private ya da no-cache bulunuyorsa hassas içeriğin tarayıcıda saklanma ihtimalini ortadan kaldırmış sayılmazsınız. CDN, reverse proxy veya web sunucusu yanıtı değiştiriyorsa kontrolü son kullanıcıya ulaşan yanıt üzerinde yapın.Hangi içerik nasıl ele alınmalı?
Kararı içerikteki veri türüne göre vermek pratikte şu şekilde yapılabilir:
| İçerik | Önerilen politika | Gerekçe |
|---|---|---|
| Kişisel hesap veya yönetim HTML'i | no-store | Verinin tarayıcıda ve ortak önbellekte kalmasını önlemek |
| Kullanıcıya özel JSON/API yanıtı | no-store | Yanıtın başka oturuma sunulmasını önlemek |
| Herkese açık, değişmeyen görsel veya stil dosyası | Uzun süreli önbellekleme düşünülebilir | Kişisel veri içermediği için performans avantajı sağlar |
| Aynı URL'de bazen herkese açık, bazen kişisel içerik | Kişisel yanıtı no-store yapın veya URL'leri ayırın | Yanlış yanıtın paylaşılmasını önlemek |
Tablodaki ayrım önemlidir: Tüm siteyi gereksiz biçimde önbelleksiz yapmak performansı düşürebilir; hassas HTML ile herkese açık statik dosyaların politikasını birbirinden ayırmak daha doğru yaklaşımdır. Ancak kişisel veri içeren bir yanıt için performans uğruna
private veya yalnızca no-cache seçilmemelidir.Kontrol ve hata teşhisi
- Giriş yapılmamış, giriş yapılmış ve oturumu kapatılmış durumlar için hassas sayfaların yanıt başlıklarını ayrı ayrı kontrol edin.
- Giriş yapılmış yanıtın
Cache-Controldeğerininno-storeolduğunu doğrulayın; yalnızca geliştirici araçlarının “Disable cache” seçeneğine güvenmeyin. - Aynı sayfayı başka bir kullanıcı hesabıyla açın ve önceki kullanıcının ad, e-posta, sipariş veya yönetim verisinin görünmediğini kontrol edin.
- Oturumu kapatın, geri düğmesine basın ve sayfayı yenileyin. Sayfa görsel olarak geçmişten açılsa bile yenileme geçersiz oturumla hassas veri döndürmemelidir.
- CDN veya reverse proxy kullanıyorsanız önbellek günlüklerini ve son kullanıcıya ulaşan yanıt başlıklarını inceleyin. Hassas yanıtın ortak önbellekten geldiğini gösteren bir durum varsa ilgili yolu önbellek dışında bırakın ve daha önce saklanmış nesneleri temizleyin.
Başarısız test, genellikle başlığın uygulama yerine yalnızca bir katmanda ayarlanması, önbelleğin eski yanıtı sunmaya devam etmesi veya oturum doğrulamasının yalnızca istemci tarafında yapılması anlamına gelir.
Vary: Cookie gibi bir başlık, yanlış paylaşım riskini bazı durumlarda azaltabilir; ancak hassas yanıtlar için no-store yerine güvenlik garantisi değildir. Oturum kapatmada çerez silinse bile sunucudaki oturum veya yenileme belirteci geçersiz kılınmalıdır.Sık sorulan sorular
Hassas sayfalarda yalnızca HTTPS kullanmak yeterli midir?
HTTPS, aktarım sırasında dinlemeye karşı koruma sağlar; tarayıcıya veya ortak önbelleğe kaydedilmiş bir yanıtın sonradan gösterilmesini tek başına engellemez. Bu nedenle HTTPS ile birlikte uygun önbellek başlıkları ve sunucu tarafı oturum kontrolü gerekir.Giriş ekranı da önbelleksiz olmalı mı?
Giriş ekranında kullanıcıya özel veya daha önce yazılmış hassas bilgiler gösteriliyorsano-store kullanmak uygundur. Tamamen genel, kişisel veri içermeyen giriş sayfası teknik olarak farklı yönetilebilir; ancak ortak politika olarak önbelleksiz bırakmak teşhis ve yanlış yapılandırma riskini azaltır.