A city portal caches authenticated resident pages on a shared CDN edge. During a web assessment, what risk should the tester prioritize documenting?
Select an answer to reveal the explanation.
Short Explanation
Picture a shared locker room where someone hangs your badge on the public pegs by mistake. Caching private, logged-in pages on a shared CDN edge is like that — the next visitor may pull someone else's private page. The finding is about cache deception/poison class leakage, not about CDNs magically breaking TLS or SQL.
Full Explanation
When a city portal places authenticated resident pages into a shared CDN edge cache, the priority finding is confidentiality leakage: another visitor can receive a previously cached personalized response if cache keys, Vary headers, or Cache-Control directives fail to isolate sessions. Shared-edge caching of logged-in content is a cache-deception or cache-poisoning-adjacent class that municipal assessors must document even when the origin application appears otherwise correct.
Claiming CDN nodes always block TLS is false—CDNs routinely terminate or pass TLS and still serve HTTPS. Asserting browsers ignore Cache-Control because a municipal logo is present invents a nonexistent client rule. Saying CDNs make SQL injection impossible is incorrect because origin requests still reach application and database tiers for uncached or dynamic work.
Exam caveat: public static assets may safely use shared caches; authenticated or PII-bearing responses must not. Distinguish Cache-Control: private/no-store from public caching of static branding files.
Operational check: request an authenticated civic page, note Set-Cookie and Cache-Control, then replay a similar unauthenticated or alternate-session request against the same URL and cache key signals to see whether private content is reused. Record evidence under the web findings section and recommend never caching authenticated municipal responses at shared edges.