For context, the Security Team recently closed a report extrapolating from CVE-2026-35192.
The report suggested that MessageMiddleware should call patch_vary_headers(response, ("Cookie",)) to better account for the interaction between the message framework backend CookieStorage and caching. One consequence of an incorrectly cached response could be that a message intended for one user is displayed to another user.
However, this raised a broader question about the designed interaction between Django’s messages framework and caching.
The messages framework aims to solve the following common use-case:
you need to display a one-time notification message (also known as “flash message”) to the user after processing a form or some other types of user input.
One-time notifications plus caching does seem generally undesirable, hence a ticket was previously raised suggesting that caching should be disabled on pages that display messages. This was closed with the following conclusion: #13894 (Provide caching guidance for messages framework) – Django
I don’t think Django can handle this problem automatically and correctly.
It is a very common pattern to loop over messages in the base template of a website. If we disable caching simply because messages might be displayed on a given page, we’re just killing the cache for most websites. If we disable it only when messages are displayed, we’re only resolving half of the problem, as explained in comments 1 and 2.
To sum up:
- Caching dynamic pages is hard
- Use ETags to save bandwidth — Django provides a lot of flexibility at this level.
- Use fragment caching in templates to save CPU — but don’t cache dynamic parts, like messages!
Do we still agree with that conclusion?
Should Django continue to treat the interaction between messages and caching as an application-level concern, because it cannot be handled automatically and correctly?
Or is there something Django could/should reasonably do to make this safer or easier, beyond documentation, without unexpectedly disabling or significantly weakening caching for many sites?
Note that we have reopened the ticket as we feel Django should at least improve the documentation on this topic ![]()