Seeing another visitor’s cart is a privacy and transaction-integrity incident. The exposed data may range from product choices to names, addresses or account information. It normally means personalised output entered a shared cache, not that WooCommerce intentionally joined two sessions.
Contain the exposure before optimising cache hit rates. Preserve response evidence without retaining more customer data than necessary.
Contain the affected pages
Bypass full-page cache immediately for Cart, Checkout, My account, order confirmation and every route that renders customer-specific content. Purge those URLs at Cloudflare, the host and WordPress layers.
If addresses, names or order details are visible, restrict the affected page while the rule is corrected and follow the business’s privacy-incident procedure.
Do not post screenshots publicly. Store a redacted copy with time, URL and response headers.
Prove whether HTML or JavaScript leaked
Use two clean private browser profiles. Create a distinct low-risk cart in each and load the suspected page.
Inspect the raw HTML response before scripts run. If visitor A’s data appears in visitor B’s HTML, shared page cache is implicated. If raw HTML is generic but the wrong data arrives later, inspect fragment, Store API and custom AJAX responses.
Evidence to retain:
URL and timestamp
cache headers and cache key clues
anonymous browser A/B result
redacted response fragmentNever retain session cookies or personal checkout fields in the incident report.
Inspect every cache layer
WordPress plugins are only one layer. Hosts may apply FastCGI, Varnish or LiteSpeed cache, while Cloudflare can cache HTML through rules. A CDN hit can bypass the exclusions shown inside WordPress.
Read Age, Cache-Control, CF-Cache-Status and host-specific headers. Confirm dynamic responses send private/no-cache directives where appropriate.
Purge is containment, not a repair. The leak returns when an unsafe cache key fills again.
Fix cache keys and bypass conditions
The safest policy is not to full-page cache transactional and account routes. For other pages, ensure cache does not store content varied by WooCommerce session or login state unless the cache system explicitly supports it.
Cookie-based bypass rules must match current WooCommerce cookie names and operate before cache lookup. Query strings and language/currency variants also need deliberate handling.
Do not attempt to create a cache variant for every raw session ID; that risks cache explosion and still mishandles sensitive content.
Check cart fragments and custom endpoints
Mini-carts often load through fragment refresh or Store API requests. Those endpoints must return the current session and must not be cached publicly.
Review custom REST endpoints for missing authentication or cache headers. A response containing a cart or customer field should be private and permission-checked.
If an optimisation plugin delays fragment scripts, the symptom may be stale local markup rather than cross-user server leakage. The two-browser raw-response test distinguishes them.
Inspect logged-in and anonymous separation
Test guest A, guest B, customer A and customer B. Logged-in users should not receive public cached account pages, and anonymous carts must remain distinct.
Check reverse proxies preserve cookies to the origin and do not strip Set-Cookie. In a multi-node setup, verify session/database access is shared correctly; node-local state can cause inconsistency, although cross-user HTML still points strongly to cache.
Verify containment and repair
After applying exclusions, warm public cache deliberately and repeat the four-session matrix. Check cart, checkout, account, order-received and header mini-cart. Confirm no customer data exists in cache storage where it can be inspected safely.
Review logs to estimate the exposure window and affected URLs. A technical fix does not replace any legal or customer-notification decision required by the organisation.
Recurring care should scan transactional response headers after cache-rule releases and test two isolated sessions. Performance improvements are never acceptable when they weaken customer separation.