Incorrect Cache-Control headers for authenticated users

Updated the patch to fix more test failures.

The last submitted patch, 22: better-cache-headers-3130912-22.patch, failed testing. View results →

Fixing test failures... again.

It is better to use the following header:

Cache-Control: no-store

I disagree for the reasons already stated in #2. The approach taken here is very probably overzealous and has the potential to badly affect UX.

I propose to postpone this and then reevaluate after the Vary header has been fixed in 🐛 Using the back button after logging out shows you pages from the authenticated user's session Needs work .

As I understand, the page_cache module is only intended for anonymous users, so moving to other component.

On Slack @catch suggested moving this to "request processing system" since this is not cache subsystem issue. Cleaned the tags based on that.

The scope of this issue should be making sure the private information is not stored in browser disk. This will resolve the security scanner reports mention on #5 🐛 Incorrect Cache-Control headers for authenticated users Postponed . Changing the Cache-Control header from must-revalidate, no-cache into no-store fixes the 🐛 Using the back button after logging out shows you pages from the authenticated user's session Needs work on Firefox, Chrome, Edge, but not on Safari, see https://discussions.apple.com/thread/251817133. I'd suggest leaving that issue to solve issue with Safari.

sokru → changed the visibility of the branch 10.0.x to hidden.

sokru → changed the visibility of the branch 7.x to hidden.

but not on Safari, see https://discussions.apple.com/thread/251817133.

hm, does Safari also ignores must-understand Cache control value? :O

Serving responses with Cache-Control: no-store has been the source of wicked UX issues in the past. This needs careful manual evaluation of multiple scenarios across popular browsers. Some scenarios are described in this rather old atlassion blog post.

One scenario based on Drupal core alone could use the contact form together with a misconfigured e-mail transport. This accurately simulates a situation on a production site where a mail server isn't reachable for a short time. In this case an error message is displayed after the submit button has been pressed. My reaction as a user of this site would be to press the back button in order to get back to the text I've just written, either to save it to a file or to retry the form submission. On a site with Cache-Control: no-store, I fear that the browser will render an empty contact form and that all text is gone.

My hunch is that the Cache-Control: no-store response header should be used on specific routes, i.e., on pages which display sensitive / confidential data. Examples of this type of information would be social security number, personal health information or credit-card data. Forms which accept and pages which display this kind of data probably should supply their own Cache-Control: no-store header. And security audits will rightfully flag such pages if that isn't the case.

Also please note that results of any automated reporting tools (including security scanners) need to be interpreted by people with knowledge in that particular field. Comment #5 gives no details about the type of application, the scope of the audit and the reason for the suggested change.

hm, does Safari also ignores must-understand Cache control value? :O

Yes, Safari does ignore must-understand with back-button, Safari behavior is similar to other browser if the "disable cache" is selected on developer toolbar.

Serving responses with Cache-Control: no-store has been the source of wicked UX issues in the past. This needs careful manual evaluation of multiple scenarios across popular browsers. Some scenarios are described in this rather old atlassion blog post.

It would be very beneficial to get these weird UX issues documented with repro steps. On core's /contact/feedback contact form I was not able to find any difference between no-store and must-revalidate, no-cache, using browsers back & forward buttons.

My hunch is that the Cache-Control: no-store response header should be used on specific routes, i.e., on pages which display sensitive / confidential data

Or we could make Drupal more secure by default using no-store and if people need better caching, they could change the response header. Many times even the unpublished node title could contain confidential data.

But I acknowledge there are risks of making this change, so it might be best just to close this issue and introduce a contrib module with eventSubscriber using Symfony's HeaderBag to get a desired Cache-Control header.

I think we need to manually test and document browser behaviour in the issue summary, marking needs work for that.