Le API REST di WordPress rendono disponibili alcuni contenuti pubblici tramite indirizzi come /wp-json/wp/v2/posts. Questo comportamento è normale e permette a editor, app, temi e servizi esterni di comunicare con il sito. Disattivare API REST WordPress in modo indiscriminato può però compromettere Gutenberg, plugin e integrazioni headless. La soluzione più sicura consiste nel bloccare soltanto gli endpoint sensibili, richiedere autenticazione dove serve e ridurre i campi restituiti. Gli utenti, gli articoli privati e i dati amministrativi non devono essere protetti soltanto nascondendo l’URL dell’API. Le regole vanno applicate nel codice di WordPress o nel server, verificando prima quali funzionalità dipendono dall’API.

Quali dati espone davvero l’API REST di WordPress

L’API REST di WordPress espone principalmente contenuti già pubblici, non automaticamente l’intero database. L’indirizzo /wp-json/ mostra le informazioni di base sull’API e le rotte disponibili, mentre /wp-json/wp/v2/posts restituisce gli articoli pubblicati accessibili al pubblico.

In base al tema e ai plugin installati, una risposta JSON può includere:

Titolo, estratto, contenuto e data di pubblicazione degli articoli.
URL canonico, autore, categorie, tag e immagini in evidenza.
Informazioni sulle pagine pubbliche e sui tipi di contenuto personalizzati.
Nomi degli utenti associati agli articoli, se l’endpoint degli utenti è disponibile.
Dati aggiunti da plugin, temi o campi personalizzati registrati nell’API.

La presenza di un articolo pubblico nell’API non rappresenta, da sola, una vulnerabilità. Un visitatore può già leggere quel contenuto dal sito; il rischio aumenta quando plugin configurati male pubblicano dati interni, campi personalizzati, utenti o endpoint non necessari.

Per verificare le rotte esposte si può aprire /wp-json/ in Google Chrome o in un altro browser. La richiesta OPTIONS o gli strumenti per sviluppatori mostrano inoltre i metodi HTTP supportati, ma un controllo più affidabile richiede l’analisi dei plugin e del codice del tema.

Come limitare le API REST senza rompere WordPress

Bloccare tutte le richieste non autenticate è efficace solo per siti che non usano funzionalità pubbliche basate sull’API. Gutenberg, alcuni page builder, applicazioni mobili e installazioni headless possono richiedere le API REST anche quando l’utente non utilizza direttamente /wp-json/.

Per impedire l’accesso anonimo all’API si può aggiungere un filtro in un plugin personalizzato o in un mu-plugin. Il codice seguente restituisce un errore HTTP 401 agli utenti non autenticati:

add_filter( 'rest_authentication_errors', function ( $result ) {
if ( ! empty( $result ) ) {
return $result;
}

if ( ! is_user_logged_in() ) {
return new WP_Error(
'rest_not_logged_in',
'L’accesso alle API REST richiede autenticazione.',
array( 'status' => 401 )
);
}

return $result;
} );

Questo approccio non equivale a una protezione universale. L’autenticazione tramite cookie e nonce funziona per le sessioni WordPress, mentre le applicazioni esterne possono usare le Password per applicazioni disponibili in WordPress 5.6 e versioni successive. Le integrazioni devono comunicare tramite HTTPS e utilizzare un account con i privilegi minimi necessari.

Il filtro rest_authentication_errors non dovrebbe essere inserito alla cieca nel file functions.php di un tema. Un cambio di tema può rimuoverlo e un errore PHP può rendere inutilizzabile il sito; un plugin dedicato o un mu-plugin offre un controllo più stabile.

Come bloccare soltanto gli endpoint sensibili

La limitazione selettiva è spesso preferibile a disattivare API REST WordPress completamente. L’endpoint degli utenti, per esempio, può rivelare gli account associati ai contenuti pubblici e fornire informazioni utili per tentativi di enumerazione dei nomi utente.

Per rimuovere le rotte /wp/v2/users e le relative varianti si può usare il filtro rest_endpoints:

add_filter( 'rest_endpoints', function ( $endpoints ) {
foreach ( array_keys( $endpoints ) as $route ) {
if ( preg_match( '#^/wp/v2/users(?:/|$)#', $route ) ) {
unset( $endpoints[ $route ] );
}
}

return $endpoints;
} );

Il codice elimina la rotta dall’elenco dell’API, ma non sostituisce la protezione degli account WordPress. È comunque necessario usare password robuste, autenticazione a più fattori tramite plugin affidabili, aggiornamenti regolari e ruoli con permessi ridotti.

Per limitare un tipo di contenuto personalizzato, bisogna intervenire nella registrazione del post type. L’opzione show_in_rest => false impedisce di pubblicarlo tramite l’API REST:

register_post_type(
'documenti_interni',
array(
'public'       => false,
'show_ui'      => true,
'show_in_rest' => false,
)
);

Questa impostazione è adatta a contenuti interni gestiti dal pannello di WordPress. Se un’applicazione deve leggere quei dati, la rotta dovrebbe usare una funzione permission_callback con una capacità specifica, invece di essere pubblica.

register_rest_route(
'miosito/v1',
'/documenti',
array(
'methods'             => WP_REST_Server::READABLE,
'callback'            => 'miosito_elenca_documenti',
'permission_callback' => function () {
return current_user_can( 'manage_options' );
},
)
);

La proprietà permission_callback è obbligatoria per le rotte REST personalizzate nelle versioni moderne di WordPress. Restituire true senza controlli rende pubblica la rotta e può esporre dati che non dovrebbero essere accessibili ai visitatori.

Come ridurre i dati restituiti dalle risposte JSON

Il parametro _fields permette di richiedere soltanto alcuni campi, per esempio /wp-json/wp/v2/posts?_fields=id,title,link. Questa tecnica riduce la quantità di dati trasferiti e può migliorare le prestazioni, ma non è un controllo di sicurezza, perché il client può modificare la richiesta e domandare altri campi autorizzati.

Per rimuovere realmente informazioni aggiuntive bisogna intervenire sui filtri rest_prepare_{post_type}. Un plugin può modificare la risposta di un tipo di contenuto prima che venga inviata, eliminando campi personalizzati non destinati al pubblico:

add_filter( 'rest_prepare_post', function ( $response ) {
if ( isset( $response->data['meta'] ) ) {
unset( $response->data['meta'] );
}

return $response;
} );

Questo esempio agisce sugli articoli standard e rimuove il blocco meta dalla risposta. Il filtro deve essere testato con i plugin attivi, perché alcuni temi o servizi possono dipendere da quei dati per mostrare correttamente contenuti e metadati.

La soluzione più affidabile è non registrare nell’API i campi riservati. Quando un plugin usa register_post_meta(), il parametro show_in_rest dovrebbe essere impostato su false per i metadati interni. Per i dati pubblici, invece, è opportuno definire una auth_callback che controlli la capacità dell’utente.

Controlli da eseguire dopo la modifica

Dopo aver limitato l’API REST, è necessario verificare sia gli accessi pubblici sia le funzioni amministrative. Un blocco eccessivo può impedire la modifica degli articoli dall’editor a blocchi o causare errori JavaScript nel pannello di WordPress.

Il controllo dovrebbe includere:

Apertura di /wp-json/ senza autenticazione.
Verifica di /wp-json/wp/v2/posts e degli endpoint dei tipi personalizzati.
Prova dell’editor Gutenberg con un account autorizzato.
Controllo dei plugin che usano webhook, app mobili o collegamenti esterni.
Analisi dei log del server per individuare richieste anomale o ripetitive.

Le regole Nginx, Apache o di un firewall applicativo possono bloccare richieste provenienti da determinati indirizzi o limitare la frequenza delle chiamate. Un blocco server-side applicato a /wp-json/ è però troppo generico per molti siti WordPress e può interferire con plugin legittimi.

La protezione dell’API deve quindi essere coordinata con aggiornamenti di WordPress, plugin e tema, oltre che con backup verificati. Nascondere i link all’API nell’HTML o rimuovere la rotta dall’indice non impedisce a un client di chiamare direttamente un endpoint ancora attivo.

Disattivare API REST WordPress è sicuro solo quando la limitazione corrisponde alle reali esigenze del sito e viene verificata dopo ogni modifica.

Potrebbe interessarti anche:

FAQ

No, le password non vengono restituite dalle risposte standard dell’API. L’endpoint degli utenti può però rivelare nomi, identificativi e informazioni pubbliche associate agli account.

Sì, ma il blocco globale può compromettere Gutenberg, plugin, applicazioni mobili e siti headless. Nella maggior parte dei casi è preferibile limitare autenticazione, endpoint o tipi di contenuto.

No. _fields riduce i campi richiesti e il traffico trasferito, ma non impedisce a un client di formulare altre richieste autorizzate.

La rotta deve usare permission_callback e verificare una capacità WordPress, come edit_posts o manage_options, in base al tipo di informazione pubblicata.

Sì, ma il blocco dell’intero percorso può rompere funzioni legittime di WordPress. È più prudente applicare regole mirate a endpoint, utenti, indirizzi IP o frequenza delle richieste.

Altri articoli di questa serie: