WordPress 7.1 Connectors can use username and application-password login, and Beta 1 notes a fix for browsers suggesting saved credentials in an API-key field. Security testing should cover field purpose, autofill suggestions, shared browsers, capability scope, connection logs, revocation, and what happens after a secret is removed.
Use this for sites connecting plugins, AI tools, automation services, publishing clients, mobile apps, or agency systems through the new Connectors screen.
Quick answer
WordPress 7.1 Connectors Application Password Autofill Security Test should be handled with a narrow evidence-first workflow: create scoped credentials, test autofill states, test shared profiles, then verify the result before making broader changes.
What to check first
- Create a least-privilege synthetic user and a named application password for one test connector.
- Test saved username, main password, application password, API key, and empty fields in browsers with autofill on, off, and a password-manager extension active.
- Repeat on a shared-device profile, private window, different WordPress user, and after logout so suggestions never cross accounts or secret types.
- Connect successfully, capture the REST route and user capability used, then revoke the application password and retry the same request.
- Review WordPress, security-plugin, reverse-proxy, and connector logs to ensure secrets are redacted while the credential owner and result remain auditable.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create scoped credentials | Create a least-privilege synthetic user and a named application password for one test connector. | API-key fields do not suggest or submit saved WordPress account credentials. |
| Test autofill states | Test saved username, main password, application password, API key, and empty fields in browsers with autofill on, off, and a password-manager extension active. | Application-password login works only for the named scoped user and connector. |
| Test shared profiles | Repeat on a shared-device profile, private window, different WordPress user, and after logout so suggestions never cross accounts or secret types. | Revocation stops new authenticated requests and any cached token has a documented expiry. |
| Revoke and retry | Connect successfully, capture the REST route and user capability used, then revoke the application password and retry the same request. | Logs identify owner, route, time, and result without recording raw credentials. |
Why this usually happens
- Browsers infer field purpose from names, labels, autocomplete attributes, and nearby form structure.
- An API key, application password, and main password may all look like generic password inputs.
- Shared browser profiles can suggest credentials saved under the same site origin.
- A connector may continue working through a cached token even after the original application password is revoked.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp user application-password list 42
wp user application-password create 42 'connector-staging-test' --porcelain
wp user application-password revoke 42 APPLICATION_PASSWORD_UUID
# Confirm the connector fails cleanly after revocation and logs no secret value.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Create scoped credentials
- Test autofill states
- Test shared profiles
- Revoke and retry
- Audit redacted logs
Decision rule
Approve the connector only when each field receives only its intended credential type, the integration uses the least-privilege user, revocation stops access, and no browser, plugin, proxy, or application log stores the secret.
What to tell the client or owner
Share the browser and password manager, field type, suggested credential, connector, WordPress user and role, application-password name, route, revocation time, post-revocation result, and redacted logs.
Production verification checklist
- API-key fields do not suggest or submit saved WordPress account credentials.
- Application-password login works only for the named scoped user and connector.
- Revocation stops new authenticated requests and any cached token has a documented expiry.
- Logs identify owner, route, time, and result without recording raw credentials.
Mistakes to avoid
- Do not test with an administrator's main password.
- Do not ignore password-manager extensions while checking browser behavior.
- Do not revoke only in the connector UI and leave the WordPress credential active.
- Do not paste production API keys into a Beta test site.
Questions teams ask during testing
Is an application password the same as the user's login password?
No. It is a separate revocable credential intended for programmatic access. It should be named for the integration and removed when that integration no longer needs it.
Why test after revocation?
Some connectors exchange the password for another token or keep a session. The team needs to know whether revocation stops access immediately or after a documented cache or token lifetime.
When HandL WP should help
HandL WP should help when a connector requests broad administrator access, browser autofill exposes the wrong credential, or revocation does not stop requests. We can test the full authentication chain without using production secrets.
If this is active on a production site, audit WordPress connector credentials.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references