La REST API è il motore discreto del WordPress moderno: l'editor a blocchi, le app mobili e molti plugin dipendono da essa. Ma una parte di questa API risponde a chiunque, senza autenticazione, e può consegnare l'elenco dei tuoi account. Questo articolo spiega cosa è pubblico per impostazione predefinita, cosa crea problemi e come limitare l'API senza rompere l'editor.
A cosa serve la REST API
Integrata nel core da WordPress 4.7, la REST API espone il contenuto del sito sotto forma di dati strutturati, accessibili a indirizzi che iniziano con /wp-json/. Permette a un programma di leggere o scrivere articoli, pagine, categorie o commenti senza passare dall'interfaccia classica. L'editor a blocchi la usa di continuo: ogni salvataggio di una bozza è una richiesta all'API.
Questa architettura è un punto di forza. Il problema non è l'API in sé, ma il fatto che alcune delle sue route rispondono ai visitatori anonimi, per scelta progettuale, perché il contenuto pubblico resti consultabile.
Cosa è pubblico per impostazione predefinita
Diverse route restituiscono dati senza autenticazione. La maggior parte è innocua: espone ciò che è già visibile sul sito.
| Route | Contenuto restituito | Sensibilità |
|---|---|---|
| /wp-json/wp/v2/posts | Articoli pubblicati | Bassa (già pubblico) |
| /wp-json/wp/v2/pages | Pagine pubblicate | Bassa |
| /wp-json/wp/v2/categories | Categorie e tag | Bassa |
| /wp-json/wp/v2/comments | Commenti approvati | Da bassa a media |
| /wp-json/wp/v2/users | Autori che hanno pubblicato almeno un articolo | Alta (enumerazione) |
La route sensibile è l'ultima. Per impostazione predefinita, /wp-json/wp/v2/users restituisce, senza alcuna autenticazione, l'elenco degli utenti che hanno pubblicato almeno un articolo su un tipo di contenuto pubblico. Per ciascuno, la risposta contiene l'ID numerico, il nome visualizzato e soprattutto lo slug, che deriva dal nome utente.
Perché l'enumerazione degli account conta
Conoscere i nomi utente non dà l'accesso, ma è la prima metà del lavoro di un attaccante. Con l'elenco dei nomi utente reali, un attacco di forza bruta o di credential stuffing diventa molto più efficace: resta solo da trovare la password. Fornire gratis i nomi degli account equivale a indicare su quale serratura insistere.
L'enumerazione non passa solo dalla REST API. Anche i vecchi percorsi /?author=1, la sitemap degli autori e l'incorporamento oEmbed possono rivelare questi nomi. Una protezione coerente li tratta insieme, altrimenti chiudere una porta lasciando aperte le altre non serve a nulla.
Limitare senza rompere l'editor
L'errore classico consiste nel disattivare completamente la REST API con un plugin drastico. Risultato: l'editor a blocchi non riesce più a salvare, alcune funzioni di amministrazione smettono di funzionare e plugin legittimi si bloccano. L'obiettivo non è chiudere tutto, ma chiudere ciò che va chiuso.
- Mantieni l'API attiva per gli utenti autenticati. L'editor funziona con un token di sicurezza (nonce) che prova che la richiesta arriva da una sessione connessa. Non toccare questo meccanismo.
- Limita la route degli utenti per i visitatori anonimi. Tecnicamente, significa richiedere la capacità
list_userssu/wp/v2/users, così che un visitatore non connesso riceva una risposta vuota o un errore, mentre un amministratore mantiene l'accesso. - Chiudi anche le altre vie di enumerazione: gli archivi degli autori
/?author=, la sitemap degli autori e l'annuncio oEmbed. - Testa dopo ogni modifica: salvataggio di una bozza, inserimento di un media, anteprima, poi i plugin effettivamente usati.
Attenzione a un dettaglio: rimuovere l'annuncio di scoperta dell'API (il link <link rel="https://api.w.org/"> nell'intestazione delle pagine) non disattiva l'API. Riduce solo gli indizi forniti agli strumenti automatici. Per bloccare davvero una route bisogna agire sul suo permesso, non sul suo annuncio.
Verificare lo stato del tuo sito
Il test è semplice e non richiede strumenti. Da una finestra di navigazione privata, cioè senza essere connesso, apri l'indirizzo /wp-json/wp/v2/users del tuo sito. Se vedi un elenco di utenti con i loro slug, la route è esposta. Se ottieni una risposta vuota o un errore di autorizzazione, è chiusa agli anonimi. Fai lo stesso con /?author=1 per verificare che non reindirizzi verso un archivio con il nome utente.
Come WP Masquerade gestisce queste route
WP Masquerade Pro affronta l'enumerazione come un insieme coerente. Il suo modulo di hardening blocca, per i visitatori anonimi, gli archivi degli autori e le richieste pubbliche a /wp/v2/users, lasciando disponibili le altre route REST e gli utenti autenticati. L'editor a blocchi continua quindi a funzionare. In parallelo, il modulo dei link tecnici rimuove gli annunci di scoperta della REST API e di oEmbed, che fanno da indizi per gli scanner.
La guida del plugin è onesta sulla portata della misura: bloccare la route degli utenti riduce alcuni mezzi di enumerazione, ma non nasconde un nome già pubblicato altrove, per esempio nella firma di un articolo. È una riduzione della superficie, non una sparizione. Combinata con password robuste e con la limitazione degli accessi, rende semplicemente il lavoro dell'attaccante più lungo e più rumoroso.
Gli usi legittimi da non rompere
Prima di limitare, bisogna sapere chi si appoggia alla REST API sul tuo sito, altrimenti si rischia di disattivare una funzione utile. Diversi usi perfettamente legittimi passano da essa.
- L'editor a blocchi, che salva, recupera e impagina il contenuto di continuo.
- Le app mobili ufficiali o di terze parti che pubblicano sul sito.
- Le integrazioni headless, in cui un'interfaccia separata consuma il contenuto tramite l'API.
- Alcuni plugin (moduli, negozi, prenotazioni) che espongono le proprie route.
La regola d'oro è quindi limitare in modo mirato, route per route, invece di bloccare tutto. Un plugin che promette di «disattivare la REST API» senza distinzioni è una cattiva scelta: risolve un problema di enumerazione creandone molti altri, a volte invisibili finché un cliente non si lamenta che un modulo non funziona più.
Le password per le applicazioni, la porta giusta per l'automazione
Se un servizio esterno deve scrivere sul tuo sito tramite l'API, non affidargli la password di un amministratore. Dalla versione 5.6 WordPress offre le password per le applicazioni: credenziali dedicate, revocabili una per una, che si usano per autenticare le richieste API senza esporre la password principale. Ogni integrazione riceve la sua, e il giorno in cui un servizio non viene più usato se ne revoca l'accesso senza toccare il resto.
Questo approccio limita i danni in caso di fuga: una password per le applicazioni compromessa si revoca con un clic, e il suo perimetro resta quello di un solo servizio. È anche il meccanismo che usa un account protetto dall'autenticazione a due fattori per continuare a dialogare con l'API e con XML-RPC, poiché questi canali non accettano più la password classica una volta attivato il secondo fattore.
Leggi anche: MCP in WordPress: cosa cambia con il Model Context Protocol e come sfruttarlo.
Da ricordare
- La REST API è pubblica per scelta progettuale per i contenuti già visibili; il punto sensibile è la route /wp/v2/users.
- Questa route consegna i nomi utente degli autori a visitatori anonimi.
- Non disattivare l'API per intero: l'editor a blocchi ne ha bisogno. Limita solo le route sensibili.
- Chiudi anche /?author=, la sitemap degli autori e oEmbed per una protezione coerente.
Fonti
- WordPress Developer, REST API Handbook (si apre in una nuova scheda)
- WordPress Developer, Users endpoint reference (si apre in una nuova scheda)
Altre fonti consultate: documentazione ufficiale.
