Indice dei contenuti
Collegare WordPress a uno script, un gestionale o un agente AI può semplificare parecchio il lavoro. Ma c’è una domanda che vale la pena farsi prima ancora di configurare l’integrazione: quali credenziali sto consegnando a questo strumento? 🔑
Condividere la password principale dell’amministratore è una cattiva idea. Per fortuna WordPress offre una funzionalità nativa pensata proprio per le integrazioni: le Application Passwords, ovvero password specifiche per le applicazioni.
Che cosa sono le Application Passwords?
Sono credenziali generate da WordPress e associate a un utente esistente. Consentono a un programma esterno di autenticarsi, per esempio attraverso le REST API, senza conoscere la password usata per accedere alla bacheca. Ogni credenziale può essere identificata per nome e revocata singolarmente.
È una differenza importante: se smetto di usare un’integrazione, posso disattivare soltanto quella chiave, senza dover cambiare la password del mio account e riconfigurare tutti gli altri servizi.
Attenzione però a un dettaglio: una Application Password non crea automaticamente un utente con privilegi limitati. Le operazioni consentite dipendono dalle capacità dell’account WordPress a cui è collegata. Se la genero per un amministratore, l’integrazione potrebbe ottenere accesso a molte funzionalità amministrative disponibili via API.
Come crearne una dalla bacheca WordPress 🛠️
- Accedi a WordPress e apri Utenti → Profilo.
- Individua la sezione Password delle applicazioni.
- Inserisci un nome riconoscibile, per esempio “Automazione articoli” o “Integrazione gestionale”.
- Genera la password e salvala subito in un archivio sicuro: viene mostrata soltanto al momento della creazione.
- Configura l’applicazione esterna affinché utilizzi il nome utente WordPress e la nuova credenziale.
La funzione è normalmente disponibile sui siti che utilizzano HTTPS. Se non compare, conviene verificare eventuali restrizioni introdotte da plugin di sicurezza o configurazioni personalizzate.
Come funziona l’autenticazione REST API?
Una modalità comune è l’autenticazione HTTP Basic su connessione HTTPS. Il client invia le credenziali nell’header Authorization. Per esempio, una richiesta di test può essere eseguita con:
curl --user "NOME_UTENTE:PASSWORD_APPLICAZIONE" \
"https://esempio.it/wp-json/wp/v2/users/me"Il dominio e le credenziali sono segnaposto. Eviterei di digitare segreti reali direttamente in comandi che potrebbero finire nella cronologia della shell o nei log: meglio utilizzare un meccanismo sicuro per passarli al client.
Il collegamento deve avvenire tramite HTTPS: la codifica Base64 di Basic Authentication non equivale a cifratura. La protezione del trasporto è indispensabile.
Una password per ogni integrazione, non una per tutte 🧩
Quando collego più strumenti allo stesso sito, preferisco credenziali distinte. Una per il sistema di pubblicazione, una per un’app di monitoraggio e una per eventuali automazioni. In questo modo posso capire meglio quale collegamento è ancora utilizzato e revocare quello che non serve più.
È utile anche dare nomi descrittivi alle credenziali, evitando etichette come “Test” o “Nuova password”. Dopo qualche mese, ricordarsi a cosa serviva una chiave generica può diventare sorprendentemente difficile.
Il punto più importante: i permessi dell’utente 🛡️
Una credenziale revocabile è utile, ma non sostituisce il principio del privilegio minimo. Se un’integrazione deve soltanto creare bozze, valuterei un account dedicato con capacità coerenti con quella funzione, invece di riutilizzare sempre l’amministratore principale.
Non basta però scegliere un ruolo a caso: occorre verificare quali operazioni REST API siano realmente consentite a quell’utente e quali capacità richieda il plugin con cui si interagisce. Alcuni endpoint personalizzati possono introdurre autorizzazioni proprie.
Questa precauzione diventa ancora più rilevante quando si usano agenti AI con accesso agli strumenti di sviluppo: la comodità di automatizzare non dovrebbe trasformarsi in accesso indiscriminato alla produzione.
Dove conservare la credenziale?
Non nel codice sorgente pubblicato su Git, non in uno screenshot e nemmeno in un file accessibile dal browser. Le password applicative vanno gestite come gli altri segreti di progetto: configurazione protetta, accessi limitati e possibilità di rotazione. Ho approfondito questi aspetti nell’articolo dedicato a chiavi API, token e password nei progetti web.
Come revocare una Application Password compromessa 🚨
Se sospetto che una credenziale sia stata esposta, apro il profilo WordPress, individuo l’applicazione corrispondente e ne revoco l’accesso. Poi controllo le attività associate all’account e genero una nuova password soltanto se l’integrazione è ancora necessaria.
La revoca è particolarmente utile quando un collaboratore cambia ruolo, un’automazione viene dismessa o un servizio esterno non è più affidabile. Non serve lasciare attive credenziali inutilizzate “nel caso tornino comode”.
Gli errori da evitare ❌
- Condividere la password principale dell’amministratore.
- Usare lo stesso account con privilegi elevati per ogni integrazione.
- Inviare credenziali senza HTTPS.
- Conservare password applicative in repository o log.
- Dimenticare di revocare le chiavi dei servizi non più utilizzati.
- Supporre che una Application Password limiti automaticamente i permessi dell’utente.
Una piccola checklist prima di collegare un nuovo servizio ✅
Verifico che il sito utilizzi HTTPS, creo una credenziale dedicata, scelgo un utente con privilegi appropriati, testo soltanto gli endpoint necessari e documento come disattivare il collegamento. Infine, controllo periodicamente l’elenco delle applicazioni autorizzate.
Per approfondire, la documentazione ufficiale WordPress sulle Application Passwords descrive creazione, utilizzo e revoca. È uno di quegli strumenti poco appariscenti che, se usati correttamente, rendono le integrazioni molto più gestibili. 🔐