sessionCacheLimiter default breaks CSP nonces via 304 response nonce mismatch

[adrianbj]

Summary

The new $config->sessionCacheLimiter setting (3.0.258, commit processwire/processwire@ae20ea03) defaults to private_no_expire for guest users. This silently breaks sites using $config->cspNonce with strict-dynamic because it enables HTTP 304 responses that cause a nonce mismatch between the CSP header and the cached HTML body.

The Problem

When a browser caches an HTML page and later revalidates it (via If-None-Match or If-Modified-Since), the server responds with 304 Not Modified — sending new response headers while the browser reuses the cached response body.

For sites using CSP nonces, this means:

• The CSP header contains a new nonce (generated fresh by $config->cspNonce)
• The HTML body contains <script nonce="..."> tags with the old nonce (from the cached response)
• The nonces don't match → every nonced inline script is blocked
• With strict-dynamic, every external script loaded via nonced <script> tags is also blocked

The result is a completely broken page — no JavaScript executes at all.

Reproduction

1. Use $config->cspNonce in a CSP header with strict-dynamic
2. Add nonce attributes to <script> tags: <script nonce="<?=$config->cspNonce?>">
3. Leave sessionCacheLimiter at its default (private_no_expire for guests)
4. Visit a page, navigate away, then return — the browser revalidates and gets a 304
5. All scripts are blocked; the browser console shows CSP violations for every script on the page

None of the Built-in Options Are Safe for CSP Nonces

Option	bfcache	CSP nonces	Issue
nocache	Broken (no-store)	Safe	Disables bfcache
private_no_expire	Works	Broken	Allows 304s → nonce mismatch
private	Works	Broken	Sends Last-Modified → enables 304s
public	Works	Broken	Same 304 problem
Custom headers	Works	Safe	Requires user to know the workaround

Workaround

Use custom headers that force revalidation without enabling conditional requests:

$config->sessionCacheLimiter = [
    'guest' => [
        'Cache-Control' => 'private, max-age=0, must-revalidate',
    ],
    'loggedin' => 'nocache',
    'admin' => 'nocache',
];

Combined with stripping the response validators that enable 304s:

header_remove('ETag');
header_remove('Last-Modified');

This preserves bfcache (no-store is not used) while ensuring the browser always receives a full 200 response with a matching nonce in both the CSP header and the HTML body.

Suggestions

1. Document the incompatibility between private_no_expire/private/public and CSP nonces, so users of $config->cspNonce know to use custom headers.

2. Consider a nonce-aware cache option that automatically strips ETag and Last-Modified when $config->cspNonce is in use, preventing 304 responses while preserving bfcache. For example, an option like 'private_no_revalidate' that sends Cache-Control: private, max-age=0, must-revalidate and removes the conditional request validators.

3. Consider changing the guest default to something safe when CSP nonces are detected — or at minimum, log a warning when private_no_expire is used alongside $config->cspNonce.

[ryancramerdesign]

✋ What is $config->cspNonce ?

[adrianbj]

@ryancramerdesign - it's something I am using based on my suggestions here: https://processwire.com/talk/topic/31739-config-cspnonce

But it doesn't really matter how you define a nonce, I just think that PW should have one that module developers (and the core) can rely on being available without needing to extract it via my example getNonce() function.

[ryancramerdesign]

Thanks for the detailed writeup @adrianbj — this is well explained.

You're right that private_no_expire permits 304 responses, and I can see how that creates a nonce mismatch when per-request dynamic headers are involved. However, private_no_expire is the right default for most ProcessWire sites (no CSP nonces, bfcache works, no proxy caching), so we won't be changing it.

What we have done is add a note to the sessionCacheLimiter docs in wire/config.php explaining the 304/nonce incompatibility, with a working example using a callable to remove ETag and Last-Modified while returning a must-revalidate Cache-Control header — which preserves bfcache and prevents 304s. That covers your workaround and makes it discoverable for others in the same situation.

-Claude

[ryancramerdesign]

@adrianbj He seems pretty certain about keeping the private_no_expire default for guest. Doc update look good?

[ryancramerdesign]

Btw, if we end up adding the cspNonce feature you mentioned then we can probably auto detect the situation.

…

On Tue, Apr 7, 2026, 5:12 PM Adrian Jones ***@***.***> wrote: *adrianbj* left a comment (processwire/processwire-issues#2201) <#2201 (comment)> @ryancramerdesign <https://github.com/ryancramerdesign> - it's something I am using based on my suggestions here: https://processwire.com/talk/topic/31739-config-cspnonce But it doesn't really matter how you define a nonce, I just think that PW should have one that module developers (and the core) can rely on being available without needing to extract it via my example getNonce() function. — Reply to this email directly, view it on GitHub <#2201 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQEUDTNAMRUNLAUWPLK4T4UV4MVAVCNFSM6AAAAACXP5X3A2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMBSGUYDMNZUGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>