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.

3

1 Answer 1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .