Make WordPress Core

Opened 5 months ago

Last modified 7 weeks ago

#61942 new defect (bug)

Add "no-store" to Cache-Control header to prevent unexpected cache behavior

Reported by: kkmuffme's profile kkmuffme Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Security Keywords: has-patch needs-testing reporter-feedback
Focuses: Cc:

Description

https://core.trac.wordpress.org/ticket/21938

Added no-store, private to Cache-Control in WP 6.1 for logged in users.
However, since this ticket was more than a decade old and created in an age before widespread reverse-proxying (CDNs), this is a problem: since those can and will store responses that have no-cache (but not no-store): https://developers.cloudflare.com/cache/concepts/cache-control/
Either by default or depending on the configuration.

Practically, not all actions are for logged in users - e.g. you have a cart/checkout/thankyou page, which will end up in a proxy-cache bc of this bug and could end up being served from cache incorrectly.

The no-store, private should be added for non-logged in users too/the user logged in condition removed

Change History (4)

This ticket was mentioned in PR #7257 on WordPress/wordpress-develop by @devansh2002.


5 months ago
#1

  • Keywords has-patch added

Remove logged-in check for no-store, private Cache-Control
Trac ticket: https://core.trac.wordpress.org/ticket/61942

#2 @ayeshrajans
5 months ago

  • Keywords has-patch removed

I agree with what the ticket proposes, but we are already doing this for logged in users.

PR 7257 seems wrong, it removes the is-logged-in check for some reason, but it's not what we should be doing because the existing code seems correct to me.

#3 @johnbillion
2 months ago

  • Keywords has-patch needs-testing reporter-feedback added

@kkmuffme What do you think about the comment above from @ayeshrajans ?

#4 @kkmuffme
7 weeks ago

Sorry, but @ayeshrajans makes no sense to me

it removes the is-logged-in check for some reason

The reason is exactly the issue described by me in the OP

the existing code seems correct to me

Again: did you read the original bug I reported above? Why does it seem correct to you?

Note: See TracTickets for help on using tickets.