[wp-trac] [WordPress Trac] #64789: Security audit for API key storage on the Connectors screen

[WordPress Trac]

#64789: Security audit for API key storage on the Connectors screen
-------------------------------------+-------------------------------------
 Reporter:  gziolo                   |       Owner:  (none)
     Type:  task (blessed)           |      Status:  new
 Priority:  normal                   |   Milestone:  7.0
Component:  Security                 |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  2nd-opinion dev-         |     Focuses:  ui, administration,
  feedback                           |  rest-api, privacy
-------------------------------------+-------------------------------------
Changes (by dpknauss):

 * keywords:   => 2nd-opinion dev-feedback
 * focuses:   => ui, administration, rest-api, privacy


Comment:

 I’ve been following this discussion while researching and testing security
 issues around Connectors, and I wanted to add one observation that seems
 worth separating from the read-side masking discussion, which has already
 been covered well. I’ve collected some of my notes and test results here
 in case they are useful as supporting context: [https://github.com/dknauss
 /wp-sudo/blob/main/docs/connectors-api-reference.md Connectors API
 reference and security notes].

 **What stands out to me is the write side.** In WordPress 7.0 RC2,
 connector credentials are ordinary REST-writable settings behind the broad
 {{{manage_options}}} gate. Database-backed keys can be replaced through
 {{{POST /wp/v2/settings}}}, and invalid AI-provider keys are cleared
 server-side while the raw REST write still returns {{{200 OK}}}. The stock
 Connectors UI does mitigate some of the UX risk: it surfaces invalid-save
 errors and marks env/constant-backed connectors as externally configured
 and read-only, but the underlying model still seems to treat billing-
 capable, prompt-routing credentials more like generic settings than like
 other high-consequence secrets.

 That feels like a write-side integrity / governance gap rather than a
 read-side disclosure issue. There is no connector-specific capability
 boundary, no connector-specific change signal or audit hook, and no built-
 in notification when a key is replaced. For same-provider swaps, the
 provider hostname does not even change; what changes is whose account
 receives the requests, who gets billed, and who can inspect the prompts.

 Core already distinguishes some credential or access-granting changes from
 ordinary settings writes. Connector credentials seem closer to that
 category than to routine site settings, especially given that AI keys can
 carry both billing consequences and prompt-visibility consequences.

 If this is considered in scope for the current ticket, a few small
 additive mitigations seem like they could help a lot:

 * Store/display a fingerprint alongside each key.
 * Fire a connector-specific change hook carrying old/new fingerprint,
 actor, and timestamp
 * Optionally notify administrators when a key is changed.
 * Introduce a narrower capability such as {{{manage_connectors}}}.
 * Preserve the existing env/constant source indicator and make database-
 backed provenance equally explicit.

 If that is out of scope here, I’d be happy to open a separate ticket
 focused specifically on credential rotation visibility, auditability, and
 capability scoping.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64789#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform