## Summary A page reachable only by solving a challenge is served with `Cache-Control: max-age=300, public` — explicitly storable by any shared cache. On a site with a reverse proxy or CDN in front (Pantheon's Global CDN, Varnish, Fastly, Cloudflare), the first visitor who solves the challenge warms the edge cache, and every visitor after that is served the protected page from the edge without the request ever reaching PHP — so the firewall never runs and the challenge never fires. The interstitial itself is fine. The library sends it with `Cache-Control: no-store`. It is the *protected response*, served after the challenge is passed, that carries no such protection, and nothing in this module adds any. ## Reproduced Drupal 11.4.4 / PHP 8.4.20, `basic_firewall` 2.x, `kanopi/firewall` v2.15.0, `system.performance:cache.page.max_age = 300`, a URL rule with `response: challenge` on `path == /`, provider `math`, mode `block`. **Internal page cache behaves correctly.** Two anonymous requests in a row both get the interstitial — the middleware at priority 280 sits outside `http_middleware.page_cache` (200), exactly as its docblock claims: ``` request 1: HTTP 200, cache-control: no-store → interstitial request 2: HTTP 200, cache-control: no-store → interstitial ``` **The protected response is the problem.** Solving the math challenge mints `fw_challenge_pass`, and the page it unlocks comes back: ``` HTTP/2 200 cache-control: max-age=300, public vary: Accept-Encoding vary: Cookie x-drupal-cache: MISS ``` `public` is an explicit instruction that a shared cache may store this and hand it to a different client. The only thing standing between that and a bypass is `Vary: Cookie`, which is the header edge caches are most likely to strip or normalise, because honouring it makes anonymous caching almost useless. ## Why this is the module's problem to solve The firewall runs in PHP. Anything served from a cache in front of PHP is unprotected by definition — that is not fixable here and belongs in the documentation. What *is* fixable is that this module knows a challenge rule was involved in producing the response and says nothing about it downstream. At the point `hasValidPassToken()` lets a request through, the module has everything it needs to mark the response as not shared-cacheable. It currently does nothing: there is no `Cache-Control` handling, no `page_cache_kill_switch` call, and no cacheability metadata anywhere in `src/`. ## Suggested resolution 1. **Mark challenge-gated responses private.** When evaluation let a request through on a pass token — or more broadly when any challenge rule matched the request — mark the response so no shared cache stores it. `\Drupal::service('page_cache_kill_switch')->trigger()` is the blunt version and sets `Cache-Control: no-cache, must-revalidate`, which stops the internal page cache and the edge together. `Cache-Control: private` is the narrower one if the internal cache is worth keeping. `basic_firewall_evaluate()` currently returns only a bool, so the middleware cannot tell "nothing matched" from "a challenge rule matched and the token was accepted". Getting that signal out is the first piece of work. 2. **Warn when the combination is unsafe.** The status report already reports on the compiled configuration and the effective mode. It could also say: challenge rules are configured, `system.performance:cache.page.max_age` is greater than zero, and therefore any challenge-gated path may be served from a shared cache. That is a five-minute check that would have caught this. 3. **Document the boundary.** `hook_help()` already explains that evaluation happens before routing, sessions and the page cache. It should also say plainly that it happens *after* any external cache, so paths under challenge or rate-limit rules need excluding at the CDN, and that a reverse proxy serving a cached copy bypasses every rule in the module. ## Related The same reasoning applies to rate-limit rules, and to block rules on paths that were cacheable before the rule was added — a cached copy at the edge outlives the rule. Challenge is the sharpest case because the whole point of the response is that it must be earned per client.