I m trying to find the difference between a server configured with “cache-control max-age=0, must revalidate” and server with “cache-control: no-cache, no-store”. So for the first, to my understanding, is not caching sensitive info at all since max age is 0 and client needs to revalidate each time for change. However some of my seniors mentioned that is still vulnerable!! I don’t see my scanner getting that flag though. So,

  1. How do I confirm the vulnerability with any tests, if any?
  2. What’s the difference between max-age 0 and no-cache? Seemingly they are same. Is the later more secured along with no-store?
  • Sensitive information exposure with caching. – Pamelaxyz Jun 14 at 23:30
  • To the user via cache. I am going through this tools.ietf.org/id/draft-ietf-httpbis-cache-01.html. What i am not able to grasp is difference between max-age=0 (which I have now) and no-cache/ no-store, which is apparently more secured to what I have now! – Pamelaxyz Jun 14 at 23:36
  • Thanks. I had thought about it about user experience but these seemingly same terms are confusing to me. With max age 0 currently too, cache is not being maintained! Does the performance worsens (for users sharing common machine) with no cache/ no store? Any ideas? – Pamelaxyz Jun 15 at 0:25

HTTP(S) caching is defined in RFC 7234; there is not currently any superseding document, so this is what you should refer to.

The no-cache response directive is a bit of a misnomer. It doesn't prohibit caching a document. It allows caching a document, but it is immediately considered stale and must be revalidated with the origin server before being used. You'll note that this is exactly the same semantics as max-age=0, must-revalidate. In both cases, the content is cached, and if the server sends a 304 response to a validation request, the cached document can be used.

To actually request a cache to not cache a document, you would use no-store. In this case it is not even strictly necessary to specify no-cache as the document would not be cached anyway! But this can be much slower than no-cache alone, as the document must be re-downloaded in its entirety every time the user accesses it.

Perhaps the fact that one of the Cache-Control directives you used as examples did not contain no-store is what your seniors were referring to, though calling this a "vulnerability" is severely overstating the matter, and whether it's a security (though again this is usually privacy) issue depends on the content you're serving.

In most contexts where you are sending user-specific information it is sufficient to set Cache-Control: private and allow the user's browser to cache the data, while shared caches will not cache it. I can't think of much that really needs to be no-stored, except perhaps private keys, nuclear launch codes, data that changes every 15 seconds, etc...

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.