A server returns each user's account statement from resources/read and marks the result cacheScope "public", reasoning that its access controls already check every request. A shared caching gateway sits in front of the server. What is the risk?
Select an answer to reveal the explanation.
Short Explanation
"Public" tells every cache along the way, 'go ahead, hand this to anyone.' Once the gateway answers from its cache, the request never reaches your access checks at all. Per-user data belongs under "private", and cacheScope was never an access-control setting.
Full Explanation
The caching utility defines cacheScope public as a response that contains no user-specific data, which any client, shared gateway or caching proxy MAY store and serve to any user. private means the response must not be shared across authorization contexts, and the specification says private is appropriate for resources/read results that depend on the authenticated user. Its security considerations warn that public results may be shared between callers even when they came from an authenticated endpoint, and that servers MUST NOT rely on cacheScope alone to prevent unauthorized access. Here the server's per-request access checks are bypassed whenever the gateway answers from cache, so a second user can receive the first user's statement. Saying public does not apply to resources/read is wrong, since resources/read is one of the listed cacheable operations. ttlMs is a freshness hint and clients SHOULD NOT treat it as a polling interval, so automatic polling is not the consequence. Nothing forbids a public response from carrying ttlMs; servers must include caching hints on every complete cacheable result. Exam caveat: all pages of a paginated list must share the same cacheScope. Operational check: request the statement under two different tokens through the gateway and confirm the second user never receives the first user's content.