API'de X-Cache: HIT neden tek başına güvenlik açığı değildir?

Bir API yanıtında X-Cache: HIT görmek, inceleme için başlangıç noktasıdır. Güvenlik değerlendirmesi ise yanıtın kime ait olduğunu ve hangi bağlamda yeniden kullanıldığını açıklamalıdır. Herkese açık bir katalog verisinin önbellekten sunulması beklenen davranış olabilir. Kullanıcıya özel bir kaydın başka kullanıcıya verilmesi farklı bir sorundur.

Üstelik X-Cache standart bir güvenlik sonucu değildir; anlamı sağlayıcıya göre okunmalıdır. Örneğin Fastly, bazı sentetik yanıtları ve stale yanıtları da HIT olarak raporlayabilir. Çok katmanlı yapılarda başlık birden fazla durum içerebilir. Bu nedenle tek kelimeyi bütün sistemin davranışı gibi yorumlamayın. Fastly X-Cache başvurusu

Başlıkları birlikte okuyun

Age, yanıtın origin'de oluşturulmasından veya başarıyla doğrulanmasından beri geçen tahmini süreyi ifade eder. Ara cache'lerde geçirilen süreyi ve ağdaki aktarım sürelerini de kapsar; yalnız son ortak cache'te bekleme sayacı değildir. Authorization taşıyan isteğin yanıtı da otomatik olarak “asla cache'lenemez” sayılmaz. RFC 9111, ortak cache'in bu yanıtı sonraki isteklerde kullanmasını kısıtlar; public, s-maxage veya must-revalidate gibi izin veren direktiflerin kendi koşulları sağlanmalıdır. RFC 9111, bölüm 3.5 ve 4.2.3

Yaygın direktifleri de ayırmak gerekir. Niteliksiz private, ortak cache'in saklamasını engeller; özel cache saklayabilir. no-store saklamayı yasaklar. Niteliksiz no-cache, yeniden kullanım öncesinde başarılı doğrulama ister; saklamayı bütünüyle yasaklamaz. Vary ise belirtilen istek başlıklarının yanıt seçimine katılmasını sağlar. Bunların hiçbiri uygulamanın yetkilendirme kontrolünü üstlenmez. MDN Cache-Control, RFC 9111, Vary

İki kurgusal hesabı düşünelim

Yalnız eğitim amaçlı bir senaryoda A hesabının /v1/users/me/invoices/latest yanıtında ownerMarker: "ALICE-LAB", B hesabının normal yanıtında ownerMarker: "BOB-LAB" bulunsun. İstenen davranış, her hesabın kendi kaydını görmesidir. Kullanıcıya özel yanıtın saklanmaması gereken bir yapılandırmada Cache-Control: private, no-store tercih edilebilir; ayrıca sunucunun doğru kullanıcıyı yetkilendirmesi gerekir.

Şimdi ayrı bir hatalı yapılandırma varsayalım: cache anahtarı yalnız yolu kullanıyor ve kullanıcı bağlamını ayırmıyor. A'dan sonra B aynı yolu çağırdığında A'nın işaretini görüyorsa, veri izolasyonu bakımından araştırılması gereken somut bir sonuç vardır. Aynı status kodu veya aynı gövde uzunluğu bu sonucu göstermez; içerikteki sahiplik ve beklenen erişim politikası önemlidir.

Bu gözlem yine de hatanın özellikle cache'ten kaynaklandığını tek başına kanıtlamaz. Origin'in yanlış kullanıcı için yanıt üretmesi, tarayıcıdaki yerel cache veya eski arayüz verisi de ayrıştırılmalıdır. Tarayıcıya özel cache ile ortak cache ayrımı için MDN HTTP caching rehberi yararlıdır.

Bulguyu yorumlamadan önce

İzinli test ortamında şu soruların yanıtını birlikte arayın:

• Her hesabın bağımsız başlangıç yanıtı ve erişim hakkı biliniyor mu?
• İstek sırası ters çevrildiğinde sonuç nasıl değişiyor?
• Gerçek yanıt gövdesi mi inceleniyor, yoksa arayüzde kalan eski veri mi?
• Cache katmanı ve origin kayıtları aynı olayı destekliyor mu?
• Tenant, kullanıcı ve temsil farkları yeniden kullanım politikasında doğru ele alınıyor mu?

Cache anahtarı bu ayrımı etkiler; kullanılan üründe başlık, cookie ve sorgu parametrelerinin nasıl dahil edildiği ayrıca incelenmelidir. CloudFront cache key açıklaması bunun bir ürün örneğidir. Anahtara kullanıcı bilgisi eklemek de bütün yetkilendirme ihtiyaçlarını kendiliğinden çözmez.

Sonuçta iyi bir bulgu, yalnız HIT başlığını göstermez: beklenen erişimi, gerçekleşen veri paylaşımını ve bunun cache ile bağlantısını ayrı ayrı açıklar. Doğrulama kavramını derinleştirmek için RFC 9110'un validators bölümü de okunabilir.