Disattivare API REST WordPress: accesso sicuro ai dati

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:

Altro per te

Wordpress

Come duplicare un articolo WordPress con WPCode

Se pubblichi spesso articoli con una struttura simile, ricreare ogni volta tutto da zero può essere scomodo. Con questo semplice snippet per WPCode puoi…