Headless and hybrid WooCommerce clients can send cart identity through a Cart-Token header, browser cookie, custom proxy header, or stored application state. If more than one source is accepted or session data loads before token validation, a stale or tampered value can select the wrong cart, hide a client bug, or create an isolation risk. WooCommerce 11.0.1 hardening makes the request-source order worth testing directly.
Use this for Store API carts, headless frontends, mobile apps, reverse proxies, custom checkout clients, and sites that mix cookie sessions with Cart-Token headers.
Quick answer
Document the one approved token source for each client. Send controlled requests with a valid token, missing token, malformed token, expired token, conflicting header and cookie, and a token from another fixture customer. Capture which source was read, validation result, session ID hash, cart contents, response, and cache status. Invalid identity must fail before private customer state is loaded.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Valid header | Approved Cart-Token and no cookie | Correct guest cart loads |
| Conflicting sources | Header for cart A and cookie for cart B | Documented source wins and no merge occurs |
| Tampered token | One changed character | Validation fails before private session data loads |
| Cross-customer replay | Token from a separate fixture profile | Unauthorized client cannot access the other cart |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Choose and document one identity source per client type. | Map every browser, app, proxy, and server component that reads, writes, forwards, or stores a cart token or WooCommerce session cookie. | Valid tokens load only the intended cart and customer context. |
| Validate token structure and signature before loading customer session data. | Capture request headers and cookie names with values hashed, plus validation logs, session ID hash, cart hash, and response status. | Missing, malformed, expired, and tampered values fail safely. |
| Remove or ignore conflicting legacy sources at the trusted boundary. | Send conflicting header and cookie fixtures to prove which source wins and whether the unused source is ignored. | Conflicting header and cookie values follow the documented precedence without merging. |
| Keep private cart responses out of shared caches. | Alter, truncate, expire, omit, and replay controlled tokens while watching customer-session database reads. | Edge and proxy layers do not cache or forward private identity incorrectly. |
What to check first
- Map every browser, app, proxy, and server component that reads, writes, forwards, or stores a cart token or WooCommerce session cookie.
- Capture request headers and cookie names with values hashed, plus validation logs, session ID hash, cart hash, and response status.
- Send conflicting header and cookie fixtures to prove which source wins and whether the unused source is ignored.
- Alter, truncate, expire, omit, and replay controlled tokens while watching customer-session database reads.
- Repeat through edge cache, origin bypass, authenticated customer, guest customer, and cross-customer isolation fixtures.
Field notes
- Treat raw cart tokens and cookies as credentials and never place them in shared logs.
- Use two isolated fixture customers so a cross-cart result is immediately visible.
- Check cache keys and cache-control because correct application validation cannot repair shared private responses.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
case,cart_token_header,session_cookie,source_read,validation,cart_hash,result
valid,A,,header,pass,cart-A,pass
conflict,A,B,header,pass,cart-A,no_merge
tampered,A*, ,header,fail,,new_or_401
replay,B,,header,deny,,isolated
Why this usually happens
- Hybrid clients evolve from cookies to headers and leave both identity paths active.
- A reverse proxy may copy a custom token into a standard header without removing the original source.
- Session lookup code can run early in the request lifecycle before the active token is fully validated.
Decision rule
Approve when every client has one deterministic token source, invalid identity fails before private reads, conflicting sources cannot merge carts, and a token from one fixture cannot expose another customer's state.
Production verification checklist
- Valid tokens load only the intended cart and customer context.
- Missing, malformed, expired, and tampered values fail safely.
- Conflicting header and cookie values follow the documented precedence without merging.
- Edge and proxy layers do not cache or forward private identity incorrectly.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Choose and document one identity source per client type.
- Validate token structure and signature before loading customer session data.
- Remove or ignore conflicting legacy sources at the trusted boundary.
- Keep private cart responses out of shared caches.
- Run guest, authenticated, tampered, conflict, and cross-customer fixtures after deployment.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not use a successful status or screen message as the only proof. Verify the business outcome and the underlying record.
- Do not leave debug logging, broad credentials, test orders, or temporary exceptions active after the review.
- Do not close the incident without recording the fixture, timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, and integrations. Finish with one controlled production fixture when the result depends on real routing, provider, or edge behavior.
What evidence should be retained?
Keep the smallest useful set: stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, version inventory, and the final verification.
When should the change be rolled back?
Roll back when a revenue, privacy, security, or publishing path fails and the cause cannot be isolated inside the approved maintenance window.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit Store API cart identity.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Audit request contexts that skip block registration
Use the WooCommerce 11.1 block registration context audit to separate presentation bootstrap from REST, AJAX, cron, scheduler, webhook, and CLI business services.
Compare both WordPress REST route shapes
For plain permalinks and proxy paths, use the WooCommerce 11.1 rest_route detection regression test to compare permissions, caching, hooks, writes, headers, and response schemas.
Helpful references