Understanding Browser Caching, Security Risks, and Recommended Configurations

Hello, I am ConardLi , and today I will explain browser caching strategies and their security implications.

While caching is often considered from a performance perspective, improper settings can expose websites to security and privacy threats.

Key Recommendations

To prevent intermediary caches, set Cache-Control: private .

If the response depends on the request Cookie , set Vary: Cookie as a secondary cache key.

Below is a quick review of HTTP caching.

Review of HTTP Cache

Browsers request resources from servers, which respond with data. Because many requests are identical, caching reduces server load by serving repeated requests from a cache store.

HTTP caching is divided into strong cache and negotiated cache.

Strong Cache

When cached data has not expired, the client can use it directly without contacting the server. Expiration is controlled by the Expires header or the Cache-Control header with a max-age directive.

Negotiated Cache

The client and server exchange validation tokens. On subsequent requests the client sends these tokens, and the server may respond with a 304 status to indicate the cached copy is still valid. Relevant headers include Last-Modified , If-Modified-Since , Etag , and If-None-Match .

Common Cache Misconceptions

Caches exist at multiple levels: browser cache (per‑user), local proxies (shared among users), and server/CDN caches (controlled by the origin). Even local proxies can cache HTTPS resources if trusted certificates are configured.

Spectre Vulnerability

The Spectre side‑channel attack can read memory across process boundaries, potentially exposing cached data. High‑risk APIs such as SharedArrayBuffer , performance.measureMemory() , and the JS Self‑Profiling API were temporarily disabled in browsers because of this.

How Cache Relates to Spectre

If a response is cached publicly (e.g., Cache-Control: public ), an attacker can use Spectre to infer the cached data even without direct access, by measuring timing differences when accessing the cached content.

For example, an attacker could infer a password character that was cached during a failed access attempt, because the cached character speeds up subsequent accesses.

Recommended Site Configuration

Disable Public Cache

Set Cache-Control: private to prevent shared caches (such as proxies) from storing sensitive responses.

Use Appropriate Secondary Cache Key

By adding Vary: Cookie , caches will differentiate responses based on the user's cookies, avoiding cross‑user data leakage for authenticated resources.

References

https://web.dev/http-cache-security/

https://zhuanlan.zhihu.com/p/32784852

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Vary

Conclusion

Have you configured caching for your applications? Share your settings and considerations in the comments.