Ruoli e permessi WordPress: gestire chi fa cosa senza dare admin a chi non serve

Il primo controllo che facciamo quando entriamo in un sito WordPress nuovo è guardare la lista utenti. Nove volte su dieci troviamo cinque o sei amministratori — il titolare, l'agenzia che ha fatto il sito, il freelance che ha fatto il logo, il cugino che ha sistemato il menu, e qualcuno che nessuno ricorda più chi sia. Ognuno di questi amministratori è una porta d'ingresso per un attaccante: se uno di loro usa una password debole, se uno ha l'email compromessa, se uno non ha l'autenticazione a due fattori, l'intero sito è esposto.

Il principio del minimo privilegio dice una cosa semplice: dai a ogni utente solo i permessi strettamente necessari al suo lavoro. Chi scrive articoli non deve poter installare plugin. Chi gestisce i commenti non deve poter modificare i temi. Chi carica i prodotti non deve poter gestire gli utenti. WordPress ha sei ruoli di default, ma quasi nessuno usa i ruoli intermedi — si salta direttamente da subscriber ad amministratore, e questa è la prima cosa da correggere.

I sei ruoli di default (e perché quasi mai bastano)

WordPress definisce sei ruoli standard: Super Admin (solo multisite), Administrator, Editor, Author, Contributor, Subscriber. La struttura è gerarchica — ogni ruolo eredita le capability del ruolo inferiore. Il problema è che i ruoli intermedi sono pensati per blog, non per siti aziendali. Un Editor può pubblicare e modificare i post di tutti, ma non può caricare file nella media library (su alcune configurazioni), non può gestire i widget, e non ha accesso ai form di contatto. Un Author può pubblicare solo i propri post. La realtà aziendale è più sfumata: serve un ruolo che possa gestire i prodotti WooCommerce senza toccare i plugin, o un ruolo che possa moderare i commenti senza pubblicare articoli.

Creare un ruolo personalizzato con capability mirate

La funzione add_role registra un nuovo ruolo con un array di capability. La chiave è selezionare solo le capability necessarie — non copiare tutto dall'Administrator. Un esempio: un ruolo 'Gestore Shop' che può gestire prodotti e ordini WooCommerce ma non può installare plugin o modificare i temi:

// Registra il ruolo 'Gestore Shop' all'attivazione del tema/plugin
add_action( 'init', function () {
    // Verifica che il ruolo non esista già (evita duplicati al re-save dei permalink)
    if ( get_role( 'shop_manager_custom' ) ) {
        return;
    }

    add_role( 'shop_manager_custom', 'Gestore Shop', array(
        // Capability di base (lette dal ruolo Author)
        'read'                   => true,
        'upload_files'           => true,
        'edit_posts'             => true,
        'edit_published_posts'   => true,
        'publish_posts'          => true,
        'delete_posts'           => true,

        // Capability WooCommerce (prodotti e ordini)
        'edit_products'              => true,
        'edit_published_products'    => true,
        'publish_products'           => true,
        'read_product'               => true,
        'edit_shop_orders'           => true,
        'read_shop_order'            => true,
        'edit_others_shop_orders'    => true,

        // Esplicitamente NEGA le capability pericolose
        'install_plugins'        => false,
        'activate_plugins'       => false,
        'edit_plugins'           => false,
        'edit_themes'            => false,
        'switch_themes'          => false,
        'manage_options'         => false,
        'edit_users'             => false,
        'create_users'           => false,
        'delete_users'           => false,
    ) );
} );

Modificare un ruolo esistente invece di crearne uno nuovo

A volte non serve un ruolo nuovo, ma togliere capability a uno esistente. Il caso più comune: l'Editor che non deve poter pubblicare (solo salvare in bozza per approvazione). Si fa con role_manager:

// Rimuovi la capability 'publish_posts' dal ruolo Editor
add_action( 'init', function () {
    $role = get_role( 'editor' );
    if ( $role && $role->has_cap( 'publish_posts' ) ) {
        $role->remove_cap( 'publish_posts' );
    }
} );

// Verifica le capability di un ruolo da terminale
// wp cap list editor --format=json

Il controllo periodico: chi può davvero fare cosa

La gestione dei ruoli non è set-and-forget. Ogni tre mesi conviene fare un audit: quanti amministratori ci sono, quando hanno fatto l'ultimo login, e se qualcuno ha capability che non dovrebbe avere. WP-CLI rende l'audit rapido:

# Lista tutti gli utenti con ruolo amministratore
wp user list --role=administrator --fields=ID,user_login,user_email,registered,last_login

# Lista le capability di un utente specifico
wp cap list <user-id>

# Trova utenti che non hanno mai fatto login (possibili account orfani)
wp user list --fields=ID,user_login,user_email,last_login --format=csv | grep 'last_login,0'

# Rimuovi il ruolo admin da un utente (mantieni un altro ruolo)
wp user remove-role <user-id> administrator
wp user add-role <user-id> editor

La gestione dei ruoli è noiosa, lo sappiamo. Ma è una delle poche cose che riduce la superficie d'attacco in modo proporzionale allo sforzo. Togliere l'admin a cinque persone che non ne hanno bisogno è un intervento di cinque minuti che elimina cinque potenziali punti di ingresso. Nessun plugin di sicurezza ti dà lo stesso risultato con lo stesso sforzo.