WooCommerce 11.1 updates is_rest_api_request() to recognize a nonempty rest_route query parameter. WordPress and WooCommerce can now classify /?rest_route=/wc/v3/... correctly while a CDN, WAF, page cache, or optimization layer still strips, ignores, normalizes, challenges, or caches that query parameter as an ordinary page. That disagreement can create permission failures, stale data, or a serious authenticated-response cache leak.
Use this for WooCommerce sites with plain permalinks, CloudFront, Cloudflare, managed WAF rules, reverse proxies, page-cache plugins, application passwords, API clients, webhooks, or custom REST endpoints.
Quick answer
Send matched pretty and query-parameter REST requests with the same method, credentials, body, and synthetic resource. Record the origin route, WooCommerce helper result, response status, Cache-Control, Vary, Age, cache status, body hash, and database effect. Repeat anonymously after the authenticated request. The rest_route parameter must participate in routing and cache safety, sensitive responses must never be publicly cached, and query normalization must not turn two different routes into one edge key.
What to check first
- Export CDN, WAF, load-balancer, host, and plugin cache rules that include, ignore, sort, strip, or bypass query parameters.
- Send matched GET, POST, permission-denied, valid, invalid, and anonymous fixtures through /wp-json/ and ?rest_route= shapes.
- Record authorization headers, cookies, route, origin status, edge status, Age, Vary, Cache-Control, response hash, and request ID.
- Prime the edge with an authorized response, then repeat without credentials from a separate session and network.
- Test encoded slashes, repeated rest_route parameters, reordered queries, empty values, and route-specific rate limits without fuzzing production broadly.
Why this usually happens
- The origin detects rest_route while the proxy cache key ignores all query parameters.
- A WAF allowlist covers /wp-json/ but challenges the root path with a REST query.
- An optimization plugin caches the root URL before WordPress classifies the request.
- Authorization and Cookie are absent from a cache bypass rule or response Vary policy.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -D auth.headers -u ck_test:cs_test \
'https://store.example/?rest_route=/wc/v3/orders&per_page=1'
curl -sS -D anon.headers \
'https://store.example/?rest_route=/wc/v3/orders&per_page=1'
# Compare status, Age, Cache-Control, Vary, cache status, and body hash.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Map route detection and cache policy at every layer from client to PHP. | Export CDN, WAF, load-balancer, host, and plugin cache rules that include, ignore, sort, strip, or bypass query parameters. | Authorized and anonymous response bodies never cross at the edge. |
| Bypass shared caching for authenticated REST and all mutation methods. | Send matched GET, POST, permission-denied, valid, invalid, and anonymous fixtures through /wp-json/ and ?rest_route= shapes. | Pretty and query routes produce the intended status, schema, hooks, and writes. |
| Include the full normalized rest_route value in any explicitly cacheable public key. | Record authorization headers, cookies, route, origin status, edge status, Age, Vary, Cache-Control, response hash, and request ID. | Cache and WAF logs show the exact bypass or route key used. |
| Align WAF permissions and rate limits for pretty and query-parameter route shapes. | Prime the edge with an authorized response, then repeat without credentials from a separate session and network. | Rollback restores prior routing without leaving stale sensitive objects. |
Decision rule
Approve WooCommerce 11.1 when both URL shapes enforce the same permissions, no authenticated body reaches an anonymous session, route-specific keys remain distinct, and every mutation bypasses shared caching.
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 |
|---|
| Authenticated GET | ?rest_route=/wc/v3/orders | Private response, no shared cache |
| Anonymous repeat | Same URL after prime | 401 or 403, never prior body |
| Pretty route | /wp-json/wc/v3/orders | Same permission contract |
| Different route | Products versus orders | Distinct edge key and policy |
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.
- Map route detection and cache policy at every layer from client to PHP.
- Bypass shared caching for authenticated REST and all mutation methods.
- Include the full normalized rest_route value in any explicitly cacheable public key.
- Align WAF permissions and rate limits for pretty and query-parameter route shapes.
- Retest authorized-to-anonymous isolation, route separation, writes, and rollback.
Production verification checklist
- Authorized and anonymous response bodies never cross at the edge.
- Pretty and query routes produce the intended status, schema, hooks, and writes.
- Cache and WAF logs show the exact bypass or route key used.
- Rollback restores prior routing without leaving stale sensitive objects.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, settings, stable fixture IDs, and a reproducible baseline.
- Treating one successful screen as proof that keyboard access, APIs, caches, jobs, reports, analytics, and downstream records agree.
- Testing only an administrator session instead of the devices, roles, networks, locales, and failure branches customers use.
- Closing the work without a named owner, rollback point, observation window, and contextual incoming link from an established guide.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only checks and one narrow synthetic fixture that cannot charge a card, send customer email, expose personal data, or change inventory. Run upgrades, package changes, cache changes, and destructive repairs on staging first.
What evidence should the test report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, screenshots or response excerpts, the decision owner, rollback point, and final verification. Redact credentials, tokens, customer data, private addresses, and infrastructure details.
How long should the observation window stay open?
Keep it open long enough to include at least one cache cycle, scheduled job cycle, and representative traffic period. For release changes, include logged-in and logged-out use plus the first real operational handoff.
When is the task complete?
Complete it when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to this guide in context.
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 a WooCommerce REST deployment.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references