Quali permessi ha una Application Password di WAP?

Una password applicativa con etichetta WAP non è un ruolo autonomo. Autentica la richiesta come l’utente WordPress che la possiede. L’autorità effettiva dipende quindi dai ruoli e dalle capacità dell’utente, dall’endpoint o Ability chiamato e da eventuali controlli di autorizzazione aggiuntivi applicati dal plugin.

L’etichetta, il trasporto o la corretta scoperta di uno strumento non ampliano tali capacità. Per ridurre l’impatto, usa un’identità WordPress separata con le sole capacità necessarie al flusso approvato.

Cause probabili

• La credenziale appartiene a un utente WordPress diverso da quello previsto dal client.
• L’assistente usa l’account amministratore umano invece di un’identità dedicata e limitata.
• L’utente autenticato non possiede la capability richiesta dall’endpoint o strumento.
• Il flusso richiede scrittura mentre l’identità è intenzionalmente limitata alla lettura.
• Più credenziali con nomi simili rendono ambigui proprietario e uso attivo.

Sequenza diagnostica

1. Verifica che il nome utente inviato corrisponda al proprietario della Application Password.
2. Usa un controllo minimo autenticato per confermare quale utente rappresenta la richiesta.
3. Confronta le capability dell’utente autenticato con l’azione richiesta.
4. Ripeti una lettura nota e limitata che dovrebbe essere consentita.
5. Tenta una scrittura volutamente vietata per confermare il rifiuto.
6. Esamina la sezione Application Password del profilo pertinente senza esporre segreti.

Applicare la correzione minima

1. Crea un’identità WordPress dedicata invece di riusare l’amministratore umano.
2. Scegli il livello di accesso più basso che completa l’azione approvata.
3. Crea una Application Password nominata per l’identità dedicata e un solo scopo.
4. Revoca credenziali confermate inutilizzate o non più necessarie.
5. Documenta chi crea, ruota, riusa e revoca la credenziale e ogni trigger.

Verificare il risultato

• La richiesta autenticata corrisponde all’utente dedicato previsto.
• La lettura limitata approvata riesce con risposta riproducibile.
• Una scrittura volutamente vietata resta rifiutata.
• Dopo la revoca, la stessa credenziale non autentica più.

Cosa non fare

• Non concedere accesso amministratore solo per superare un test di connessione.
• Non confondere autenticazione riuscita con permesso per tutte le azioni WordPress.
• Non trattare ogni 403 come connessione rotta; può essere il corretto rifiuto.
• Non inserire Application Password, Authorization, token o cookie in prompt, ticket, log o screenshot.
• Non passare da identità limitata a Full Power senza flusso separato, staging e rollback approvati.

Guide correlate

• Come trovare le Application Password di WAP in WordPress
• Come identificare quale utente WordPress usa un assistente IA
• Quale livello di accesso WordPress dovresti assegnare a un’IA?
• Perché un assistente IA non dovrebbe usare il tuo account amministratore WordPress
• Come revocare l’accesso di WAP AI Assistant