Statamic Cache Evader Laravel Package

Technical Evaluation

Architecture fit. alpshq/statamic-cache-evader implements a "hole-punching"/cache-evasion pattern for Statamic (the Laravel-based CMS): a page is served from a full-page cache, but designated dynamic partials are rendered by dedicated URLs that bypass that cache. Architecturally this is a signed-URL fragment endpoint layered on Laravel's routing and URL-signing facilities. It fits cleanly only where the stack is Laravel + Statamic + a full-page cache (Statamic Static Cache, Cloudflare, Varnish, Fastly). In a plain Laravel app with no Statamic or no page cache, there is no problem for it to solve.

Integration feasibility. Low-friction install: Composer package with a service provider, published config, and a rendering helper/blade tag for declaring dynamic partials. Real integration work sits outside the package: (a) excluding the partial endpoint from every cache layer, (b) ensuring APP_KEY/signing material is stable and identical across all app instances and environments, and (c) correct middleware ordering so signature verification runs before the controller.

Technical risk. v1.4.1 is a security fix, not a feature release: rendering URLs for dynamic partials are now properly signature-checked. Read plainly, prior versions accepted partial-render requests whose signature was not (or not correctly) validated. That is an access-control defect with a plausible data-exposure path — if a partial renders session-, user-, or cart-scoped content and the endpoint can be invoked without a valid signature, an attacker can request arbitrary partial/parameter combinations and potentially observe or induce per-user content into a shared cached page (cache poisoning / cross-user leakage class). Treat pre-1.4.1 as urgently patch-required, and treat 1.4.1 itself as requiring verification rather than blind trust, since the fix is a single commit with no advisory referenced in the notes.

Key questions.

• Is there a published advisory/CVE and an explicit affected-version range? The release notes cite only commit a216e5a.
• Does the fix alter the generated URL format? If so, in-flight HTML and pre-warmed caches will carry now-invalid signatures.
• Are signatures expiring/time-boxed, or static per (partial, params)? This determines replay exposure.
• Does the fix cover only the HTTP route, or also the internal rendering helper used at template compile time?
• Was a regression test added that asserts tampered signatures are rejected?
• What are the supported Laravel/Statamic version constraints, and is 1.4.1 a patch-only bump (semver-compatible) or does it require a constraint change?

Integration Approach

Stack fit. Laravel (verify exact major constraints in composer.json) + Statamic 3/4/5. Package auto-discovery means no manual provider registration. Confirm the cache driver and edge configuration in each environment, since the package is inert without a page cache in front of it.

Migration path. Bump to 1.4.1 via Composer as a patch-level upgrade; no API or template changes should be required. Because the change is on the security boundary, the migration is not complete at composer update — it requires a cache purge and a negative test (see sequencing). Keep APP_KEY and any ancillary signing secret unchanged across the deploy; rotating them mid-upgrade converts the security fix into a 403 storm.

Compatibility. Two compatibility axes matter more than usual here:

1. URL/host consistency. Signed URLs are computed against an absolute URL. Behind TLS-terminating load balancers or proxies, the signed host/scheme can differ from the request host/scheme unless trusted proxies are configured — a classic source of spurious signature failures that will look like the patch "broke" partials.
2. Statamic version alignment. Static Cache behavior and the partial-rendering hooks differ across Statamic majors; validate on the exact minor you run in production.

Sequencing.

1. Read the diff for a216e5a and confirm the affected range; inventory every environment running <1.4.1.
2. Upgrade in staging against a production-like cache topology (same CDN/Varnish rules, same proxy headers).
3. Negative test: request a partial URL with a mutated signature, a stripped signature, and a signature for a different partial — all must be rejected.
4. Positive test: confirm legitimate partials render and are not cached by the edge.
5. Purge full-page caches (and any pre-warmed HTML) as part of the deploy, not after it.
6. Roll to production in a low-traffic window; watch 403 rate on the partial endpoint and origin request rate for the first hours.

Operational Impact

Maintenance. Small, single-maintainer-community package sitting directly on a security boundary — this raises the maintenance bar above its size. Pin the version, enable automated dependency alerts, and subscribe to the repository's releases/advisories. Budget a review of each release rather than auto-merging, given that the last one was an auth bypass.

Support. No commercial SLA. Establish an internal owner and a documented escape hatch: the ability to disable the evader and fall back to uncached rendering (or a coarser fragment strategy) within one deploy. Confirm the fallback is exercised before you need it.

Scaling. The pattern's cost is structural: every dynamic partial is an uncached PHP request that bypasses the page cache. Pages with many partials erode the cache hit ratio and shift load to PHP-FPM and the database. Model this before broad adoption — measure origin requests per page view and per-partial query cost; consider shorter TTL fragment caching inside the partial rather than caching the endpoint itself. The endpoint must never be edge-cached; a single misconfigured cache rule turns per-user fragments into shared content and is a data-leak incident, not a performance regression.

Failure modes.

• Signature mismatch → 403 or empty fragment; degrades silently in the UI (blank cart badge, missing personalization) rather than erroring visibly. Needs alerting on 403 rate.
• APP_KEY rotation → every outstanding signed partial URL invalidates simultaneously; coordinate key rotation with a cache purge.
• Cache rule regression (CDN/Varnish/WAF change) → endpoint cached, cross-user content leakage.
• Middleware reordering or route-cache regeneration dropping the signature middleware → verification silently skipped, reintroducing exactly the pre-1.4.1 vulnerability. Add the negative test to CI.
• Clock skew or expiring signatures → intermittent failures that correlate with host time drift.

Ramp-up. Low for a Laravel/Statamic developer — hours to first working partial. The real learning curve is the cache topology: which layer caches which response, how to prove the partial endpoint is excluded everywhere, and how to test signature rejection. Assign that topology review to whoever owns the CDN/edge config, not only the application developer.

Recommendation. Treat 1.4.1 as a required upgrade on any environment running an earlier version; do not adopt the package on pre-1.4.1 pins. Before production rollout, obtain the affected-version range and confirm whether the URL format changed, then gate the deploy on the signature-rejection test and an edge-cache purge.