14

We're currently reviewing our set of "no-cache" security headers:

  • Cache-Control "no-cache, no-store, must-revalidate
  • Pragma "no-cache"
  • Expires 0

Besides the "standard" set above, I found this article, recommending to combine "no-cache" and "no-store" with "private". As far as I understand the specification it should be sufficient to set "no-cache" and "no-store" if you want to forbid caching at all.

So my question: Are there any reasons to add the "private" header to our set? And if so, will there be a conflict between the headers?

P.S.: I also checked the following two discussions, which did not provide a definite answer.

Community
  • 1
Th0mas
  • 171
  • 1
  • 5
  • 1
    This article (in particular the flow chart) might be of interest to you: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en – rink.attendant.6 Aug 05 '15 at 19:08
  • @NeilMcGuigan: [`private` applies to HTTP 1.1](https://tools.ietf.org/html/rfc7234). Private is used if you don't mind the content being stored in the browser cache, but do not want it being stored in shared caches (e.g. proxy servers). HTTP 1.0 had `pragma` in the request and `expires` in the response. – SilverlightFox Aug 06 '15 at 09:26
  • This [post](https://stackoverflow.com/a/3492459/6381711) is quite elaborate and answers it all. – nyedidikeke Sep 24 '20 at 02:22

1 Answers1

1

I understand the contradiction (if we may call it so) you highlighted. So I read both (some parts of the specification related to the private option) and the article.

I rather searched about the original article where the bug was first mentioned. In that article, it is stated:

It was reported that multiple meta.wikimedia.org users received the same session ID. These users could act as the user who happened to be logged in according to the session value.

So you can conclude there is nothing wrong with the specification, and you need to add the private option in Cache-control only when there is a session.