Security: enforce object-level authorization across the ability services (1.4.0)

[trueqap]

Fixes all 10 findings from the full-plugin security audit (9 HIGH, 1 MEDIUM).

Root cause

Authorization was expressed entirely as a registration-time primitive capability check, and src/Services/ contained zero current_user_can() calls. A primitive capability means "may edit posts in general" — never "may edit THIS post". So any ability whose permission_callback sat one notch too low granted unrestricted access to every object of that type, and WordPress's and WooCommerce's own protections — which live in the meta-capability layer (map_meta_cap, wc_modify_map_meta_cap, get_editable_roles()) — never ran at all.

Verified against WP and WooCommerce source: wp_update_post(), wp_delete_post(), wp_delete_attachment(), update_post_meta(), wp_set_password() and WP_User::set_role() perform no capability check of their own. They are data-layer functions; authorization is the caller's job, and this plugin was not doing it.

What an attacker could do (before this PR)

Role	Could do
Contributor	Permanently delete any post site-wide (bulk-posts); rewrite/publish/reassign any post, page or product; read every author's drafts and private posts with full private meta; on WooCommerce: list every customer's name/email/phone, read protected order meta (_order_key, _transaction_id, _customer_ip_address), delete orders, create refunds, read internal staff notes
Author	Permanently delete any attachment, including the files on disk (force defaulted to true)
shop_manager	Reset the administrator's password silently and get the plaintext back; promote itself to administrator via role or by writing {prefix}capabilities user meta

shop_manager matters because WooCommerce grants edit_users to it unconditionally via a user_has_cap filter (wc-user-functions.php:684); its intended restriction (wc_modify_map_meta_cap) only runs for the meta caps this plugin never called.

The fix

Object-level checks now run in the service layer, where the target ID is finally known. Three new focused helpers hold the policy so it cannot drift:

• Helpers/Capability (112 lines) — object-level meta capability checks
• Helpers/ProtectedMeta (114 lines) — protected-key and privilege-key policy
• Services/Meta/MetaGuard (144 lines) — single entry point for the 12 meta methods

Per finding: per-object checks on posts/meta/media/users; the 14 WooCommerce order abilities moved to the existing can_manage_orders; promote_user + get_editable_roles() on role changes (validated before any write, so a rejected role can't half-update an account); role/level/session-token meta keys refused for everyone; protected-key filter applied to single-key reads; post_status no longer 'any' plus perm => 'editable'.

Tests

4 new suites, 52 cases, covering every finding — RED before, GREEN after. The current_user_can and wp_register_ability stubs became controllable so both the allowed and denied branch are exercised (previously current_user_can always returned false, so neither was); added WP_Post, WP_User, WP_Query and several function stubs.

Gate: composer phpcs clean · composer analyse (PHPStan L5) no errors · composer test 423/423.

⚠️ Behaviour change — please read before merging

Lower-privileged roles lose access they previously (incorrectly) had. Any integration running as Contributor, Author or WooCommerce shop_manager may now get 403 forbidden where it previously succeeded — that is the fix working, but it is a breaking change for such setups. Administrators are unaffected. Hence the minor bump to 1.4.0.

Two smaller behaviour changes worth calling out:

• delete-media now defaults to the trash instead of permanent deletion (pass force: true for the old behaviour).
• list-posts no longer returns every status by default.

Also included (separate commit)

delete-theme passed the caller's slug straight to core with no validate_file() and no allowlist, so ../plugins recursively deleted wp-content/plugins. This is administrator-gated and therefore not a privilege boundary crossing — it was excluded from the audit findings — but the ability is AI-agent-facing and annotated idempotent, so a hallucinated slug could destroy an unrelated directory. Now allowlisted against wp_get_themes(), mirroring what delete_plugin() already does.

Known follow-up (deliberately not in this PR)

UserManager.php (405) and MediaManager.php (404) crossed the project's 400-line hard limit, and MetaManager.php (529) / PostManager.php (821) were already above it and grew. The new logic went into new classes — the legacy files only received delegating guard calls — but the call sites still add lines. Splitting them is a separate refactor task requiring characterization tests first, and the project rules forbid mixing a security fix with a refactor.

Audit areas confirmed clean, for the record: no SQL injection (all 5 $wpdb files verified), no XSS (the remote plugin registry is correctly escaped), no CSRF gap, no arbitrary option write, no object injection, no code-execution sink, and the MCP transport/discovery surface is correctly manage_options-gated.

[trueqap]

✅ Verified end-to-end on the live WooCommerce store

Tested on croco2 (WP 7.0.3, WooCommerce 11.0.0, HPOS on) with real Contributor, Author and shop_manager accounts + application passwords, over the actual REST surface.

The premise confirmed live — WooCommerce 11.0.0 still grants shop_manager the primitive capability the old code checked, while denying the meta capability the new code checks:

shop_manager  edit_users (primitive, old check) : YES
shop_manager  edit_user(1) (meta cap, new check): no
shop_manager  promote_user(1)                   : no
contributor   edit_posts : YES    edit_shop_orders : no

Attacks — all closed

Attack	Result
contributor → wc-list-orders (customer PII)	403
contributor → wc-get-order / wc-get-order-meta (_billing_email)	403
contributor → wc-list-order-notes (internal notes)	403
contributor → get-post-meta (private key)	403
contributor → get-post on admin draft	403
contributor → update-post / set-post-meta on another's post	403
contributor → bulk-posts delete of 2 admin-owned posts	processed=0, failed=2 — posts verified still present
author → delete-media (another's attachment)	403
shop_manager → reset-password on admin	403
shop_manager → update-user role=administrator	403
shop_manager → set-user-meta wp_capabilities	403
contributor → list-posts?status=any	200, admin draft not in response

Admin regression — 8/8 unchanged

wc-list-orders, wc-get-order-meta (include_protected), get-post, get-post-meta (private key, value returned), list-posts, list-users, wc-list-order-notes, update-user — all 200, all still returning the data they should.

Two defects the live run caught that the unit suite did not

Both now fixed with regression tests (commit 51d4b5f):

1. get-post still leaked private meta on published posts. The capability check is correct — read_post is legitimately satisfied for a published post — but collect_post_meta() stripped only three keys, so the whole protected meta map went to any Contributor. Confirmed: _lwsec_secret was returned before, empty meta map after, admin still sees the value.
2. bulk-posts returned HTTP 500 (ability_invalid_output) once any item failed — failed_ids is declared as integers but the loop pushed objects. Pre-existing and previously rare; the new per-item authorization made it the routine path. bulk-comments had the same latent bug.

Scratch users and posts removed from the test site afterwards. Local gate re-run: phpcs clean, PHPStan L5 no errors, 425/425 tests.