1389635 - Caching HTTP GET response even though Cache-Control settings include no-store

Status: RESOLVED DUPLICATE of bug 1318234

(Core :: Networking: Cache, defect)

Description

[andrewlandry]

Attachment: cache.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce:

1. Visit a page that contains no-store Cache-Control headers. My example is https://www.behance.net - login and click "Create a Project", which brings you to https://www.behance.net/portfolio/editor
2. View cache at about:cache-entry?storage=memory&context=&eid=&uri=https://www.behance.net/portfolio/editor



Actual results:

The entire response is cached in-memory - even though the Cache-Control headers are set to: no-store, no-cache, must-revalidate, post-check=0, pre-check=0


Expected results:

The response should not have been cached.

Comment 1

[Daniel Veditz [:dveditz]]

It's possible we've interpreted "no-store" to mean not to write anything to disk, but keep it in memory for perf reasons. What do other browsers do?

Comment 2

[andrewlandry]

Other browsers I tested don't store it in in-memory cache.

The vulnerability is that if PII could be viewed with the cache viewer by the next user of a public computer if the user did not close Firefox at the end of their session.

Comment 3

[Honza Bambas (:mayhemer)]

This is known.  And our no-store treatment will be discussed soon (I have it on the list) so that we may stop keeping it even in the memory cache.

Comment 4

[andrewlandry]

Excellent, thanks for the update!

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to Honza Bambas (:mayhemer) from comment #3)
> This is known.  And our no-store treatment will be discussed soon

Can this be duped to or depend-on some other bug? or is it just a literal "list" somewhere?

Comment 6

[Honza Bambas (:mayhemer)]

I think the duplicate is bug 1318234