County open-data GenAI caches personalized answers on a CDN keyed only by client IP. What cache-design risk should security call out?
Select an answer to reveal the explanation.
Short Explanation
Keying personalized answers only by IP is like filing every resident’s reply under “someone on this block.” Wrong neighbors can get each other’s answers. IP uniqueness myths, magic encryption, and short TTLs do not fix key design.
Full Explanation
County open-data GenAI that caches personalized answers on a CDN keyed only by client IP risks serving one resident’s answer to another when IPs are shared—NAT, CGNAT, corporate proxies, libraries, or rotating addresses. Security should call out cross-resident answer leakage from insufficiently specific cache keys. Personalized civic GenAI responses need cache keys that include authenticated user or session identity (and appropriate Vary headers), not IP alone, so CDN hits cannot cross municipal constituents.
IP addresses do collide and are shared in cities; they do not guarantee anonymity or uniqueness for cache isolation. Keying only by IP does not automatically encrypt personalized answers for the correct recipient or bind ciphertext to the right session. Short CDN TTLs reduce the leakage window length but do not fix incorrect key identity if the wrong resident still receives a cached hit during the TTL.
Exam caveat: fully public, non-personalized open-data answers may use coarser keys; personalization changes the caching threat model and must be designed deliberately. Operational check: review CDN cache-key configuration for the GenAI edge, test two authenticated users behind one NAT, confirm Cache-Control and Vary prevent cross-user personalized hits, and monitor for cache-key collisions in access logs.