Cos'è la REST API di WordPress? Una guida pratica

La REST API di WordPress è un'interfaccia HTTP integrata che permette al software esterno di interagire con un sito WordPress tramite JSON. È stata integrata nel core di WordPress nella versione 4.7 (dicembre 2016) e alimenta l'editor a blocchi Gutenberg, le app mobile ufficiali di WordPress, ogni frontend headless di WordPress e un numero enorme di integrazioni di plugin. L'endpoint base è /wp-json/ su ogni sito WordPress. Molti di questi endpoint sono pubblici di default, il che di solito va bene, ma alcuni di essi (in particolare la lista utenti) espongono informazioni che la maggior parte dei proprietari di siti preferirebbe tenere private.

Cos'è la REST API di WordPress, in termini concreti?

La REST API è l'interfaccia programmatica del sito WordPress. Dove un browser visita un URL come example.com/sample-post/ e riceve HTML, un client API richiede example.com/wp-json/wp/v2/posts e riceve JSON: un array di oggetti post con i loro titoli, contenuto, date, ID autore e così via. Ogni operazione CRUD (create, read, update, delete) che WordPress può eseguire tramite la sua UI admin ha un endpoint REST corrispondente. L'editor a blocchi chiama questi endpoint quando salvi un post; le app mobile li chiamano quando pubblichi dal telefono; le configurazioni headless li chiamano per recuperare contenuti per un frontend Next.js o Gatsby.

Alcuni endpoint canonici da conoscere:

• /wp-json/ — l'endpoint di discovery. Restituisce un documento JSON che descrive tutte le rotte disponibili sul sito.
• /wp-json/wp/v2/posts — lista dei post del blog. Pubblica per default.
• /wp-json/wp/v2/pages — lista delle pagine.
• /wp-json/wp/v2/users — lista degli autori e dei loro profili pubblici. L'endpoint che causa più preoccupazione.
• /wp-json/wp/v2/media — lista degli elementi della libreria media.
• /wp-json/wp/v2/categories, /tags, /comments — esattamente quello che suonano.

Plugin e temi possono registrare endpoint aggiuntivi. WooCommerce aggiunge /wp-json/wc/v3/products, /orders, /customers. ACF aggiunge endpoint per campi custom. Contact Form 7, Yoast SEO, ogni plugin importante ha il suo sottoinsieme della REST API.

Cosa fa la REST API di WordPress di cui dovrei preoccuparmi?

Tre casi d'uso ad alto impatto, anche se non scrivi mai una riga di codice tu stesso:

• L'editor Gutenberg ne dipende. Ogni volta che salvi un post nell'editor a blocchi, l'editor chiama POST /wp-json/wp/v2/posts/{id}. Se la REST API è rotta o bloccata, Gutenberg smette di funzionare. Sintomi: errori "Aggiornamento fallito" o "La risposta non è una risposta JSON valida" al salvataggio. La causa più comune è un plugin di sicurezza o una regola .htaccess troppo aggressiva che blocca /wp-json.
• È il target di ricognizione di attacco più comune. Gli attaccanti che interrogano /wp-json/wp/v2/users possono enumerare ogni account autore: nomi utente, nomi visualizzati e il percorso URL del loro archivio autore. Da lì, segue indovinare password o phishing mirato. Questo singolo endpoint è responsabile della maggioranza dei riscontri "nomi utente trapelati" negli audit di sicurezza WordPress.
• Abilita ogni integrazione esterna. Zapier, Make, IFTTT, notifiche Slack personalizzate, sincronizzazione con un CRM, sincronizzazione con un generatore di siti statici, sincronizzazione con MailChimp, servizi di traduzione di terze parti, ogni integrazione usa la REST API. Disabilitarla del tutto (cosa che alcuni tutorial di sicurezza raccomandano) rompe tutte queste.

Quali informazioni espone la REST API per default?

Pronta all'uso, una richiesta non autenticata a un tipico sito WordPress può recuperare:

• Tutti i post e le pagine pubblicate. Compreso il loro contenuto completo. Gli stessi dati che un browser che visita il sito può vedere; solo in forma JSON per uno scraping più facile.
• La lista di ogni utente che ha pubblicato un post. /wp-json/wp/v2/users restituisce il nome utente WordPress (il nome di login), il nome visualizzato, l'URL dell'archivio autore e l'ID utente per ogni autore. Questo è stato cambiato in WordPress 5.0 per restituire solo utenti che hanno scritto un post pubblicato (in precedenza restituiva ogni utente), ma per la maggior parte dei blog questo significa ancora ogni amministratore ed editor.
• Tutti gli elementi della libreria media. Comprese le URL in dimensione originale per ogni immagine e file. Utile per lo scraping, dannoso se hai caricato documenti privati nella libreria media pensando che non sarebbero stati scopribili.
• La tassonomia completa. Categorie, tag, tassonomie custom e le loro relazioni.
• Metadati del sito. Nome, descrizione, URL, fuso orario, lingua, formato orario, tipi di post disponibili e tassonomie.

Niente di tutto questo è tecnicamente una vulnerabilità; è l'API che si comporta come progettata. Ma per la maggior parte dei siti il trade-off tra "comodità per le integrazioni" e "fuga di informazioni verso attaccanti" inclina verso la restrizione almeno dell'endpoint utenti.

Dovrei disabilitare la REST API di WordPress?

Risposta breve: no, non disabilitarla del tutto. Restringila.

Disabilitare la REST API del tutto rompe l'editor a blocchi per qualsiasi admin loggato che cerca di salvare un post, rompe l'app mobile WordPress, rompe ogni automazione Zapier o Make che punta al sito, rompe il checkout WooCommerce in alcune configurazioni, e rompe ogni plugin che usa la REST API internamente (che è la maggior parte dei plugin ora). Il consiglio "disabilita la REST API" da vecchi articoli di sicurezza risale a WordPress 4.7-4.9 quando l'API era più nuova e la storia di integrazione era meno sviluppata. Nel 2026 è sbagliato.

L'approccio corretto è restringere endpoint specifici (specialmente /users) lasciando il resto dell'API funzionante. Tre pattern che colpiscono il giusto equilibrio:

Pattern 1: richiedi autenticazione per l'endpoint utenti

La restrizione più comune e utile. Aggiungi al functions.php di un child theme o a un mu-plugin:

add_filter('rest_authentication_errors', function ($result) {
    if (!empty($result)) {
        return $result;
    }
    $route = isset($GLOBALS['wp']->query_vars['rest_route']) ? $GLOBALS['wp']->query_vars['rest_route'] : ';
    if (strpos($route, '/wp/v2/users') === 0 && !is_user_logged_in()) {
        return new WP_Error(
            'rest_not_logged_in',
            'You are not currently logged in.',
            ['status' => 401]
        );
    }
    return $result;
});

Questo restituisce un 401 alle richieste non autenticate a /wp-json/wp/v2/users mentre lascia ogni altro endpoint accessibile. App mobile e integrazioni che si autenticano (Application Passwords, OAuth) continuano a funzionare normalmente. Gutenberg continua a funzionare perché la richiesta dell'editor è autenticata.

Pattern 2: rate-limit dell'API

Uno scraper ad alto volume che colpisce /wp-json/wp/v2/posts?per_page=100&page=N può estrarre l'intero database dei contenuti in secondi. Rate-limiting a livello di server web (nginx limit_req) o tramite un plugin di sicurezza (Wordfence, iThemes Security) attenua questo. Protezione utile contro scraper di contenuti ed enumerazione brute-force anche quando i singoli endpoint non sono sensibili.

Pattern 3: usa un WAF o CDN che filtra le richieste API

Cloudflare e Sucuri entrambi ti permettono di scrivere regole come "blocca ogni richiesta a /wp-json/wp/v2/users dall'esterno del range IP della nostra azienda". Utile per siti dove la REST API è puramente a uso interno (un backend headless di un team editoriale, per esempio).

Come è autenticata la REST API di WordPress?

Per operazioni di scrittura o per accedere a dati non pubblici, la REST API richiede autenticazione. Cinque metodi, in ordine di quanto sono comuni nel 2026:

• Autenticazione tramite cookie. Il default per richieste provenienti dallo stesso sito dell'installazione WordPress. L'editor a blocchi e ogni richiesta UI admin loggata usano cookie. Richiede un nonce per la protezione CSRF.
• Application Passwords. Introdotte in WordPress 5.6 (2020). Ogni utente può generare password specifiche per scopo dalla sua pagina profilo, che sono poi inviate via HTTP Basic Auth. Questo è il metodo raccomandato per app mobile e integrazioni esterne nel 2026. La maggior parte dei plugin che in precedenza richiedevano JWT ora supportano anche Application Passwords.
• OAuth 2.0. Tramite il plugin ufficiale "WordPress.com" o plugin OAuth di terze parti. Usato quando hai bisogno di scope a grana fine o integrazione di app di terze parti. Meno comune di Application Passwords per la maggior parte dei casi d'uso.
• JWT (JSON Web Tokens). Tramite il popolare plugin "JWT Authentication for WP REST API". Era lo standard de facto per WordPress headless tra il 2017 e il 2022, ora per lo più sostituito da Application Passwords.
• Autenticazione specifica del plugin. WooCommerce usa chiavi consumatore firmate HMAC per la sua API. Ogni plugin importante tende ad avere il proprio approccio.

Se stai scrivendo codice custom o chiedendo a uno sviluppatore di integrarsi con il tuo sito, la risposta di default nel 2026 è "Application Passwords" a meno che tu non abbia una ragione specifica per usare OAuth o JWT.

Come verifico cosa espone la REST API del mio sito?

Tre controlli rapidi:

1. Visita l'endpoint di discovery. Apri https://tuosito.com/wp-json/ in un browser. Otterrai un documento JSON che elenca ogni rotta registrata. Leggi attraverso l'oggetto routes per vedere cosa è disponibile.
2. Controlla specificamente l'endpoint utenti. Visita https://tuosito.com/wp-json/wp/v2/users. Se vedi un array di utenti con nomi, slug e link, i nomi dei tuoi autori sono pubblicamente enumerabili. Se vedi {"code": "rest_not_logged_in", "message": "..."}, è ristretto. Se ottieni un 404, l'intera REST API è disabilitata (che probabilmente significa che anche Gutenberg non funziona).
3. Usa InspectWP. La sezione Sicurezza di un report InspectWP testa esplicitamente se l'endpoint utenti è accessibile pubblicamente e lo segnala in tal caso. Più veloce che digitare gli URL manualmente.

Qual è la differenza tra REST API e XML-RPC?

WordPress ha due API remote che si sovrappongono nello scopo: XML-RPC (legacy, da WordPress 2.6 nel 2008) e la REST API (moderna, da 4.7 nel 2016). Per la maggior parte delle operazioni espongono funzionalità comparabili. Le differenze:

• Protocollo. XML-RPC usa XML su POST verso un singolo endpoint (/xmlrpc.php). La REST API usa JSON su verbi HTTP standard su URL multipli. JSON è significativamente più facile da gestire nei linguaggi moderni.
• Superficie di attacco. XML-RPC è stato un mal di testa di sicurezza perenne. Il metodo system.multicall permette di raggruppare migliaia di tentativi di indovinare password in una singola richiesta, sconfiggendo la maggior parte del rate-limiting di base. La funzionalità Pingback è stata usata in attacchi di amplificazione DDoS. La maggior parte delle guide di sicurezza ora raccomanda di disabilitare XML-RPC del tutto, che è una conversazione diversa dalla REST API.
• Futuro. Lo sviluppo del core di WordPress si è spostato interamente sulla REST API. XML-RPC è ancora supportato ma nessuna nuova funzionalità viene aggiunta. Diversi strumenti di terze parti (notabilmente Jetpack, fino a poco fa) dipendono ancora da XML-RPC, che è la ragione principale per cui rimane abilitato di default.

"Disabilita XML-RPC" e "blocca l'endpoint utenti della REST API" sono entrambe misure di sicurezza ragionevoli e mirano a cose diverse. Fare uno non influisce sull'altro.

Quali sono i problemi comuni della REST API sui siti WordPress?

• "La risposta non è una risposta JSON valida" al salvataggio in Gutenberg. Quasi sempre significa che un plugin di sicurezza o una regola .htaccess sta bloccando le richieste /wp-json/, o una configurazione di permalink le sta riscrivendo erroneamente. Soluzione: rigenera i permalink (Impostazioni, Permalink, Salva) e controlla Wordfence/iThemes per i toggle "Blocca REST API".
• Errori CORS quando si chiama da un frontend headless. Per default WordPress accetta solo richieste REST API dal proprio dominio. Per una configurazione headless su un dominio diverso, aggiungi gli header Access-Control-Allow-Origin tramite il filtro rest_pre_serve_request, o usa un plugin come "WP CORS".
• Application Passwords non funzionano. Alcuni ambienti di hosting strippano l'header Authorization dalle richieste in entrata prima che WordPress lo veda. Questa è la causa più comune di "L'autenticazione Application Password fallisce silenziosamente". Soluzione: chiedi all'host di mettere in whitelist l'header Authorization per HTTP Basic Auth, o usa il workaround HTTP_AUTHORIZATION in .htaccess.
• Risposte REST API lente. Default per_page=10, ma un'integrazione pigra richiede per_page=100 su un sito con 50.000 post. Ogni chiamata REST carica l'oggetto post completo, idrata i campi ACF, esegue i filtri. Risultato: una risposta di 30 secondi. La soluzione è di solito aggiungere una cache oggetti (Redis) e interrogare solo i campi di cui l'integrazione ha effettivamente bisogno tramite il parametro _fields.
• 404 su /wp-json/ ovunque. I permalink belli non sono abilitati. Vai su Impostazioni, Permalink, seleziona qualcosa di diverso da "Semplice", salva. La REST API richiede permalink belli per funzionare.

Cosa controlla InspectWP

La sezione Sicurezza di ogni report InspectWP testa la REST API di WordPress in due modi specifici. Primo, controlla se /wp-json/wp/v2/users è accessibile pubblicamente senza autenticazione. Se sì, il report elenca i nomi utente enumerabili e segnala questo come un rilievo di sicurezza, perché i nomi utente esposti rendono il brute-force e il phishing mirato significativamente più facili. Secondo, il report controlla se l'endpoint di discovery della REST API è raggiungibile, cosa necessaria perché Gutenberg e la maggior parte dei plugin funzionino; una REST API completamente disabilitata è segnalata come causa probabile di problemi dell'editor. Lo stato raccomandato è "REST API raggiungibile, endpoint utenti protetto". L'obiettivo è far funzionare le integrazioni mentre blocca il pattern di ricognizione dell'attaccante più comune, che può essere ottenuto con il piccolo snippet di codice mostrato sopra.