WordPress 7.1 expands the Abilities API and its public visibility controls. An operation may be safe for public discovery while one input default, output property, error message, provider detail, cache entry, or permission shortcut exposes customer, credential, infrastructure, draft, or administrative data.
Use this for plugins, themes, automation tools, REST clients, MCP or AI integrations, and sites registering WordPress abilities.
Quick answer
Inventory every registered ability with provider, operation, public flag, permission callback, input schema, output schema, error schema, cache policy, and owner. Classify each field by sensitivity. Test anonymous, subscriber, customer, editor, administrator, application password, expired session, and forged request fixtures. Public discovery must reveal only approved metadata, while execution and response fields follow least privilege.
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 |
|---|
| Public discovery | Anonymous ability list | Approved metadata only |
| Denied execution | Subscriber calls admin operation | 403 without sensitive detail |
| Malformed input | Secret-like value and wrong type | Redacted stable error |
| Cached response | Admin then anonymous request | No role-crossing value |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze the ability registry and classify every exposed field. | Export registered abilities with provider, operation, public flag, permission callback, schemas, cache keys, logs, and owner. | Anonymous discovery exposes only approved ability metadata. |
| Separate public discovery from execution permission explicitly. | Classify every input, output, error, default, example, description, and provider field as public, internal, personal, credential, or secret. | Denied callers receive no sensitive values in responses or errors. |
| Reduce schemas and errors to the minimum approved public contract. | Test anonymous and each supported role across discovery, valid execution, denied execution, malformed input, and cached response paths. | Role-sensitive responses cannot leak through browser, CDN, or application caches. |
| Partition or disable caches that can cross roles or identities. | Inspect REST responses, browser caches, CDN caches, logs, traces, and AI tool transcripts for sensitive fields. | Logs, tool transcripts, revocation, and retention follow the field policy. |
What to check first
- Export registered abilities with provider, operation, public flag, permission callback, schemas, cache keys, logs, and owner.
- Classify every input, output, error, default, example, description, and provider field as public, internal, personal, credential, or secret.
- Test anonymous and each supported role across discovery, valid execution, denied execution, malformed input, and cached response paths.
- Inspect REST responses, browser caches, CDN caches, logs, traces, and AI tool transcripts for sensitive fields.
- Make permission, schema, redaction, cache, retention, and incident ownership explicit before enabling public discovery.
Field notes
- Use synthetic secrets and customer records.
- Test application passwords as a distinct caller class.
- Invalidate role-sensitive cache entries during permission changes.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
ability,public,caller,permission,input,output,cache,result
orders.read,false,anon,deny,none,none,miss,pass
site.health,true,anon,allow,none,public,public,pass
customer.export,true,subscriber,deny,id,error-detail,shared,fail
customer.export,false,admin,allow,id,redacted,private,pass
Why this usually happens
- Public discovery and public execution can be confused.
- Schema examples and error text may contain real operational values.
- A permission callback can protect execution but not a cached response.
- Logging and tool transcripts can preserve fields omitted from the final API response.
Decision rule
Mark an ability public only when its discovery metadata is intentionally public, execution has the required permission callback, every field is classified, and role-sensitive values cannot cross response, cache, log, or transcript boundaries.
Production verification checklist
- Anonymous discovery exposes only approved ability metadata.
- Denied callers receive no sensitive values in responses or errors.
- Role-sensitive responses cannot leak through browser, CDN, or application caches.
- Logs, tool transcripts, revocation, and retention follow the field 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.
- Freeze the ability registry and classify every exposed field.
- Separate public discovery from execution permission explicitly.
- Reduce schemas and errors to the minimum approved public contract.
- Partition or disable caches that can cross roles or identities.
- Retest callers, logs, transcripts, revocation, and retention.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful screen as proof that background jobs, APIs, caches, roles, reports, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, networks, data states, and failure paths real users have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache changes, and schema work on staging first.
What evidence should the report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, addresses, and private infrastructure details.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
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 WordPress API permission boundary.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references