Snippet sicurezza: disabilitare XML‑RPC e REST non usata in WordPress

Nel panorama digitale del 2025, la sicurezza di un sito WordPress non è un optional, ma una necessità imprescindibile. Ogni giorno, siti web vengono presi di mira da attacchi automatizzati e mirati. Come sviluppatori e webmaster, il nostro compito è rendere la vita difficile agli attaccanti, e uno dei modi più efficaci per farlo è ridurre la superficie di attacco. Questo articolo tecnico, ma accessibile, si concentra su come disabilitare XML-RPC REST WordPress (o almeno le parti non essenziali della REST API) per blindare ulteriormente le nostre installazioni. Analizzeremo cosa sono questi endpoint, perché spesso non sono necessari, e forniremo snippet di codice pratici per gestirli correttamente.

Perché è importante ridurre le superfici di attacco su WordPress

Ogni componente di un sito WordPress – il core, i temi, i plugin, le API esposte – rappresenta un potenziale punto di ingresso per un malintenzionato. L’insieme di tutti questi punti di ingresso costituisce la “superficie di attacco”. Più ampia è questa superficie, maggiori sono le opportunità per gli hacker di trovare una vulnerabilità da sfruttare.

Disabilitare funzionalità non utilizzate è un principio fondamentale dell’hardening della sicurezza (noto come principle of least privilege applicato alle funzionalità). Se una porta non serve, perché lasciarla aperta? Riducendo le funzionalità attive, diminuiamo il numero di potenziali vulnerabilità e semplifichiamo la manutenzione e il monitoraggio della sicurezza. Questo approccio proattivo è essenziale per proteggere i dati degli utenti e la reputazione del sito. Per approfondire i concetti generali di sicurezza web, il sito OWASP (Open Web Application Security Project) è una risorsa fondamentale.

Cosa sono XML-RPC e REST API e perché potrebbero non essere necessari

WordPress offre due API principali per permettere a sistemi esterni di interagire con il sito:

1. XML-RPC (xmlrpc.php): Un protocollo più datato che consente la comunicazione remota. Originariamente serviva per cose come pubblicare articoli da app desktop o mobile, gestire pingback e trackback, e per la connessione con servizi come Jetpack (nelle sue prime versioni).
2. REST API (WP-JSON): L’interfaccia moderna, flessibile e standard per interagire con i dati di WordPress. È utilizzata intensivamente dal Block Editor (Gutenberg), da molte app mobile, da frontend headless (JAMstack) e da numerosi plugin per scambiare dati in formato JSON. Puoi leggere un’introduzione nell’articolo REST API WordPress: introduzione per frontend headless.

Quando potrebbero non servirti?

• XML-RPC: Se non usi vecchie app per pubblicare contenuti da remoto, non ti interessano pingback/trackback (spesso fonte di spam) e non hai plugin specifici che richiedono esplicitamente XML-RPC (molti, come le versioni recenti di Jetpack, ora usano la REST API), allora puoi tranquillamente disabilitarlo. È considerato largamente obsoleto per la maggior parte degli use case moderni.
• REST API: Disabilitare completamente la REST API è sconsigliato nella maggior parte dei casi, poiché romperebbe funzionalità core come il Block Editor. Tuttavia, spesso non è necessario esporre tutti gli endpoint della REST API pubblicamente, specialmente a utenti non autenticati. Se il tuo sito non è un headless CMS e non hai plugin che necessitano di accesso pubblico anonimo ai dati tramite API, puoi limitarne l’accesso ai soli utenti loggati.

Cos’è XML-RPC e perché disabilitarlo

Il file xmlrpc.php presente nella root di ogni installazione WordPress è il gateway per il protocollo XML-RPC. Sebbene abbia avuto la sua utilità in passato, oggi è più una fonte di problemi che di benefici per la maggior parte dei siti.

A cosa serviva e perché è obsoleto

Come accennato, XML-RPC permetteva:

• Pubblicazione remota da client desktop/mobile (prima dell’avvento della REST API).
• Pingback e trackback: meccanismi per notificare altri blog quando li linkavi (e viceversa).
• Comunicazione con l’app mobile di WordPress (ora usa la REST API).
• Connessione iniziale per alcuni servizi/plugin come Jetpack (che ora preferisce/richiede la REST API).

Con l’introduzione della REST API (dal core di WordPress 4.7), più potente, flessibile e standard, XML-RPC è diventato ridondante per quasi tutte le funzionalità moderne.

Vulnerabilità comuni associate a XML-RPC

Lasciare attivo XML-RPC espone il sito principalmente a due tipi di attacchi:

1. Attacchi Brute Force Amplificati: Normalmente, un tentativo di login richiede una richiesta HTTP. Tramite la funzione system.multicall di XML-RPC, un attaccante può tentare di validare centinaia di combinazioni username/password con una singola richiesta HTTP. Questo rende gli attacchi brute force molto più efficienti e difficili da bloccare per i sistemi di sicurezza basati sul numero di richieste fallite.
2. Attacchi DDoS tramite Pingback: Gli attaccanti possono inviare richieste di pingback fasulle a migliaia di siti WordPress (con XML-RPC attivo), indicando come “sorgente” del link il sito vittima che vogliono colpire. Tutti questi siti WordPress tenteranno quindi di contattare il sito vittima per verificare il pingback, generando un attacco Distributed Denial of Service (DDoS) che può sovraccaricare e rendere irraggiungibile il server della vittima.

Dato il basso utilizzo legittimo e gli alti rischi, disabilitare XML-RPC REST WordPress (specificamente la parte XML-RPC) è quasi sempre una buona pratica di sicurezza.

Snippet per disabilitare XML-RPC

Esistono diversi modi per disabilitare XML-RPC. Ecco i due più comuni ed efficaci:

1. Tramite functions.php (o un custom plugin): Questo metodo dice a WordPress di disabilitare internamente le funzionalità XML-RPC. Aggiungi questo codice al file functions.php del tuo tema child (scopri come in: Creare un Tema Child Moderno con Vite + Twig per WordPress) o, ancora meglio, in un plugin di funzionalità personalizzato:

<?php
/**
 * Disabilita completamente XML-RPC in WordPress.
 *
 * @link https://developer.wordpress.org/reference/hooks/xmlrpc_enabled/
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

/**
 * Rimuove l'header X-Pingback dal frontend.
 * Utile anche se xmlrpc è disabilitato a livello di server,
 * per non rivelare la possibilità (anche se bloccata).
 *
 * @param array $headers Gli header HTTP.
 * @return array Gli header modificati.
 */
add_filter( 'wp_headers', function( $headers ) {
    if ( isset( $headers['X-Pingback'] ) ) {
        unset( $headers['X-Pingback'] );
    }
    return $headers;
} );

/**
 * Disabilita i metodi XML-RPC che potrebbero essere usati per attacchi DDoS Pingback.
 * Ridondante se xmlrpc_enabled è false, ma è una sicurezza aggiuntiva.
 *
 * @param array $methods Metodi XML-RPC abilitati.
 * @return array Metodi modificati.
 */
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

// Opzionale: Rimuove l' RSD (Really Simple Discovery) link dal <head>
remove_action( 'wp_head', 'rsd_link' );
?>

Vantaggio: Metodo “pulito” che usa i filtri di WordPress. Svantaggio: La richiesta al file xmlrpc.php arriva comunque al server e a WordPress, anche se viene bloccata internamente. Consuma minime risorse.

2. Tramite .htaccess (per server Apache): Questo metodo blocca l’accesso al file xmlrpc.php a livello di server, prima che WordPress venga caricato. È più efficiente in termini di risorse per bloccare attacchi massivi. Aggiungi queste righe al tuo file .htaccess nella root di WordPress:

# Blocca completamente l'accesso a xmlrpc.php
<Files xmlrpc.php>
  Require all denied
</Files>

Vantaggio: Blocca le richieste molto presto, risparmiando risorse del server. Efficace contro attacchi DDoS e brute force mirati a quel file. Svantaggio: Funziona solo su server Apache (o compatibili come LiteSpeed). Per Nginx, la configurazione è diversa e va fatta nel file di configurazione del server/sito.

Quale metodo scegliere? Idealmente, entrambi. Il filtro in functions.php disabilita la funzionalità internamente, mentre la regola .htaccess (o equivalente Nginx) blocca le richieste dirette al file, offrendo una protezione a più livelli.

REST API: quando non è necessaria (o meglio, limitabile)

La REST API di WordPress è uno strumento potente e fondamentale per il funzionamento moderno della piattaforma, in particolare per l’editor a blocchi (Gutenberg) e per l’integrazione con servizi e applicazioni esterne. A differenza di XML-RPC, disabilitarla completamente è quasi sempre una cattiva idea.

Uso della REST API e quando può essere limitata

La REST API è usata per:

• Comunicare tra l’editor a blocchi e il backend di WordPress (salvataggio post, caricamento blocchi riutilizzabili, ecc.).
• Permettere a plugin (es. Contact Form 7, WooCommerce) di esporre endpoint per funzionalità specifiche.
• Fornire dati a frontend separati (headless/JAMstack).
• Interagire con l’app mobile ufficiale di WordPress.
• Applicazioni di terze parti che si integrano con WordPress.

Tuttavia, per impostazione predefinita, WordPress espone molti dati pubblicamente tramite la REST API a chiunque, senza autenticazione. Ad esempio, è possibile elencare tutti gli utenti registrati (/wp-json/wp/v2/users), ottenere dettagli su post, pagine, categorie, tag, ecc.

Se il tuo sito non serve un’applicazione esterna o un frontend headless, e non hai plugin che richiedono specificamente endpoint pubblici, puoi limitare l’accesso alla REST API ai soli utenti autenticati. Questo riduce significativamente la quantità di informazioni esposte a potenziali attaccanti o bot che cercano di enumerare utenti o contenuti.

Snippet per limitare la REST API agli utenti autenticati

Questo è il metodo raccomandato per disabilitare XML-RPC REST WordPress accessi non autenticati alla REST API, senza compromettere l’editor a blocchi o altre funzionalità per gli utenti loggati. Aggiungi questo codice al functions.php del tema child o al tuo plugin di funzionalità:

<?php
/**
 * Limita l'accesso alla REST API ai soli utenti autenticati.
 *
 * Controlla se l'utente è loggato quando viene fatta una richiesta alla REST API.
 * Se non è loggato, restituisce un errore, impedendo l'accesso ai dati.
 * Permette eccezioni per namespace specifici (es. Contact Form 7).
 *
 * @link https://developer.wordpress.org/reference/hooks/rest_authentication_errors/
 * @param WP_Error|null|true $result Risultato del controllo di autenticazione.
 * @return WP_Error|null|true Modificato $result.
 */
add_filter( 'rest_authentication_errors', function( $result ) {
    // Se è già presente un errore di autenticazione, restituiscilo
    if ( ! empty( $result ) ) {
        return $result;
    }

    // Elenco dei namespace della REST API che vogliamo lasciare pubblici (accessibili senza login)
    // Esempio: Contact Form 7 usa 'contact-form-7'
    // Esempio: WooCommerce può usare 'wc' o 'wc-analytics', ecc. Controlla la documentazione dei tuoi plugin.
    $public_namespaces = [
        'contact-form-7',
        // 'woocommerce', // Aggiungi altri namespace pubblici necessari qui
        // 'wc/v3',      // Esempio WooCommerce
    ];

    // Controlla il percorso della richiesta corrente
    // La variabile globale $GLOBALS['wp']->query_vars['rest_route'] contiene il percorso richiesto, es: '/wp/v2/posts'
    $current_route = isset($GLOBALS['wp']->query_vars['rest_route']) ? $GLOBALS['wp']->query_vars['rest_route'] : '';
    $current_route_parts = explode('/', trim($current_route, '/'));
    $current_namespace = isset($current_route_parts[0]) ? $current_route_parts[0] : ''; // es: 'wp', 'contact-form-7', 'wc'

    // Se l'utente non è loggato E la richiesta non è per un namespace pubblico consentito
    if ( ! is_user_logged_in() && ! in_array( $current_namespace, $public_namespaces, true ) ) {
        // Restituisci un errore WP_Error per bloccare l'accesso
        return new WP_Error(
            'rest_not_logged_in',
            __( 'You are not currently logged in.', 'text-domain' ), // Messaggio traducibile
            array( 'status' => 401 ) // Codice di stato HTTP 401 Unauthorized
        );
    }

    // Altrimenti, l'accesso è consentito (utente loggato o namespace pubblico)
    return $result;
} );
?>

Importante:

• Testa approfonditamente: Dopo aver aggiunto questo codice, verifica che l’editor a blocchi funzioni correttamente, che i plugin essenziali (form di contatto, e-commerce) operino come previsto e che eventuali app esterne che devono accedere ai dati possano ancora farlo (in tal caso, dovrai aggiungere i loro namespace all’array $public_namespaces).
• Personalizza $public_namespaces: Devi identificare quali namespace usano i tuoi plugin (se necessario) e aggiungerli all’array. Puoi scoprire i namespace attivi esplorando l’indice della tua REST API (solitamente https://tuosito.it/wp-json/).

Questo approccio bilancia sicurezza e funzionalità, bloccando l’esposizione non necessaria di dati tramite la REST API.

Alternative per migliorare la sicurezza senza rompere le funzionalità

Oltre a disabilitare o limitare le API, ci sono altre strategie:

• Limitare invece di disabilitare: Come visto per la REST API, un approccio chirurgico è spesso migliore. Identifica cosa esattamente non ti serve e disabilita solo quello.
• Utilizzare plugin di sicurezza: Plugin popolari come Wordfence Security, Sucuri Security, iThemes Security (ora Solid Security) offrono interfacce user-friendly per disabilitare XML-RPC, limitare la REST API, implementare firewall (WAF), monitorare tentativi di login, ecc. Sono ottimi strumenti, specialmente se preferisci non mettere mano al codice. Tuttavia, è sempre utile capire cosa fanno “sotto il cofano”. Per una panoramica sulla sicurezza, potresti trovare utile La Sicurezza Frontend nel 2025: Guida Pratica su XSS e CORS.
• Web Application Firewall (WAF): Servizi come Cloudflare, Sucuri WAF, o WAF a livello server (es. ModSecurity) possono filtrare il traffico malevolo prima che raggiunga WordPress, bloccando richieste sospette verso xmlrpc.php o endpoint sensibili della REST API.

Conclusione: Quando è consigliato disabilitare XML-RPC e limitare la REST API?

Disabilitare XML-RPC è quasi sempre consigliato nel 2025, a meno che tu non abbia una dipendenza specifica e consapevole da questa vecchia tecnologia. I rischi di sicurezza superano di gran lunga i benefici per la stragrande maggioranza dei siti WordPress moderni.

Limitare la REST API ai soli utenti autenticati è una scelta eccellente per i siti “tradizionali” (non headless) che non necessitano di esporre dati pubblicamente tramite API. Rafforza la sicurezza riducendo l’esposizione di informazioni senza compromettere le funzionalità essenziali per gli amministratori e gli editor.

Ricorda, disabilitare XML-RPC REST WordPress accessi non necessari è solo una parte di una strategia di sicurezza completa.

Checklist finale di sicurezza API

1. ✅ Valuta XML-RPC: Hai davvero bisogno di XML-RPC? (Probabilmente no).
2. ✅ Disabilita XML-RPC: Usa il filtro xmlrpc_enabled e/o la regola .htaccess/Nginx.
3. ✅ Valuta REST API Pubblica: Hai bisogno di endpoint REST API accessibili senza login? Per quali plugin/servizi?
4. ✅ Limita REST API: Se non serve pubblica, usa il filtro rest_authentication_errors per richiederla solo agli utenti autenticati, creando eccezioni per namespace specifici se necessario.
5. ✅ Test Funzionalità: Verifica che il sito funzioni correttamente dopo le modifiche (editor, login, form, plugin chiave).
6. ✅ Monitora: Tieni d’occhio i log del server e i report dei plugin di sicurezza.
7. ✅ Mantieni Aggiornato: Aggiorna sempre WordPress, temi e plugin.
8. ✅ Usa Pratiche Generali: Password robuste, plugin di sicurezza, WAF, backup regolari. Per approfondire le best practice di sviluppo e sicurezza su WordPress, consulta la WordPress per sviluppatori: guida completa.

Implementando questi snippet e seguendo queste raccomandazioni, farai un passo importante per rendere il tuo sito WordPress più sicuro e resiliente contro gli attacchi comuni.