Best practice for caching sensitive data

Question

My server returns private data in the body of an HTTPS response. It's not passwords or credit cards, but it is user-generated text and images, which should not be accessed by others.

The data for a particular URL never changes, and could be cached for as long as I wanted. The performance benefit of caching is significant.

There are a lot of Cache-Control directives: max-age, private, no-store, etc., but I'm not sure which I should use.

I do set session cookies (lifetime is limited to a single browser session). Is there a way to have a "session cache" that behaves similarly?

What is best practice?

Are you using HTTPS? If you're not using HTTPS the authentication traffic won't be encrypted and none of it matters anyways. — essefbx, Apr 29 '15 at 15:28

score 6 · Answer 1 · answered Apr 29 '15 at 15:42

6

If the majority of your traffic is personalized data then you should use HTTPS and rely primarily on browser caches. Make use of this cache by setting Expire header and ETag.

Additionally, the Cache-Control: no-store advises browsers to not cache the data on a persistent storage, the data can only be cached on RAM. In effect, this is like session cache.

answered Apr 29 '15 at 15:42

Lie Ryan

31,089
6
68
93

what does "rely primarily on browser cache" look like in terms of the headers that are sent, like cache-control , vary, expires, etag, etc. Are there some pointers to read more about this kind of setup ? – gaurav5430 Jun 22 '19 at 18:20

score 5 · Answer 2 · edited May 23 '17 at 12:40

You should use the private directive. Note that content will remain available within the user's browser, even if the Expires header is set as this header does not necessarily force the browser to purge it after the date and time set so it does not meet your session time-out requirement. However, if this risk is acceptable then it may be suitable.

You could make sure the Last-Modified header is set so the browser knows whether to update content.

Cache-Control: private

Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache, such as a proxy server.

From RFC2616 section 14.9.1

_{Taken from this post.}

Note that no-store is not suitable if you definitely want caching in the browser (em me), also from RFC:

The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and MAY be sent either in a response or in a request. If sent in a request, a cache MUST NOT store any part of either this request or any response to it. If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non- shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.

However, it does also say

History buffers MAY store such responses as part of their normal operation

so navigating backwards to content will still be possible from the cache, assuming it has not yet been removed for memory management purposes.

Also some browsers may still ask for the whole file again, which is another reason that this may not be suitable:

we also do not send an if-modified-since request when validating 'no-store' content in the cache because we are not supposed to have a copy of it from a HTTP point-of-view.

Best practice for caching sensitive data

2 Answers2

Linked