Se costruisci plugin WordPress, la sicurezza non è opzionale. Una singola vulnerabilità nel tuo plugin può compromettere migliaia di siti, distruggere la tua reputazione ed esporti a responsabilità legali. La directory dei plugin WordPress ha rimosso centinaia di plugin per problemi di sicurezza, e le vulnerabilità più comuni sono prevenibili con precauzioni di base.
Questa guida copre le best practice di sicurezza che ogni sviluppatore di plugin WordPress deve seguire. Non sono teoriche — sono il livello minimo per pubblicare un plugin che non metta a rischio i tuoi utenti.
Validazione dell'Input: Non Fidarti Mai dell'Input Utente
La prima regola della sicurezza WordPress è la stessa di ogni altra applicazione web: non fidarti mai dell'input utente. Ogni dato che proviene da una richiesta — parametri GET, dati POST, valori dei cookie, file caricati — deve essere validato prima di usarlo.
WordPress fornisce diverse funzioni per sanificare l'input. Usa sanitize_text_field() per il testo semplice, sanitize_email() per gli indirizzi email, sanitize_key() per le chiavi del database, sanitize_title() per gli slug, absint() per gli interi e wp_kses() per il contenuto HTML che deve permettere tag specifici. Non usare mai $_POST o $_GET direttamente senza sanitizzazione.
La regola è semplice: sanifica all'ingresso, escapa all'uscita. Valida tutto ciò che ricevi, escapa tutto ciò che produci.
Escaping dell'Output: Prevenire gli Attacchi XSS
Il Cross-Site Scripting (XSS) è la vulnerabilità più comune nei plugin WordPress. Si verifica quando i dati forniti dall'utente vengono emessi senza un escaping adeguato, permettendo agli attaccanti di iniettare JavaScript in pagine che altri utenti vedranno.
WordPress fornisce funzioni di escaping specifiche per contesto. Usa esc_html() quando emetti testo semplice dentro tag HTML, esc_attr() per i valori degli attributi, esc_url() per gli URL, esc_js() per JavaScript inline e wp_kses_post() per il contenuto dei post che deve preservare un po' di HTML. Per i dati visualizzati negli attributi HTML, usa sempre esc_attr().
Lo sviluppo WordPress moderno usa sempre più React per le interfacce admin, che gestisce l'escaping automaticamente. Ma per l'output renderizzato in PHP tradizionale, l'escaping manuale è essenziale.
Prevenzione dell'SQL Injection
Gli attacchi SQL injection possono permettere a un attaccante di leggere, modificare o eliminare i contenuti del tuo database. La classe wpdb di WordPress fornisce prepared statement che prevengono l'SQL injection se usati correttamente.
Non usare mai $wpdb->query() con valori concatenati. Usa sempre $wpdb->prepare() con la sintassi dei segnaposto. Il segnaposto %s è per le stringhe, %d per gli interi e %f per i float. Se devi usare clausole IN() con array, usa array_fill per generare il numero giusto di segnaposto.
Ancora meglio che usare $wpdb direttamente è usare le API WordPress di livello superiore come WP_Query, get_posts() e get_term_by(). Queste funzioni gestiscono la prevenzione dell'SQL injection internamente.
Nonce: Proteggersi dal CSRF
Gli attacchi di Cross-Site Request Forgery (CSRF) ingannano gli utenti autenticati facendoli eseguire azioni che non intendevano. I nonce WordPress prevengono questi attacchi aggiungendo un token monouso a moduli e URL.
Usa wp_nonce_field() nei tuoi moduli e controllalo con check_admin_referer() all'invio. Per gli URL, usa wp_nonce_url() e verificalo con wp_verify_nonce(). Per le richieste AJAX, includi un nonce nei dati della richiesta e verificalo con check_ajax_referer().
I nonce non proteggono da tutti gli attacchi CSRF, ma alzano significativamente l'asticella. Combinati con controlli di capability adeguati, prevengono i vettori di attacco più comuni.
Controlli delle Capability: Chi Può Fare Cosa
Ogni pagina admin, handler AJAX ed endpoint REST API del tuo plugin dovrebbe verificare che l'utente corrente abbia le capability richieste. Usa current_user_can() con il livello di capability appropriato per ogni azione.
Per le pagine admin registrate con add_menu_page() e add_submenu_page(), specifica la capability richiesta negli argomenti della funzione. WordPress gestirà il controllo automaticamente. Per gli handler AJAX personalizzati e gli endpoint REST, aggiungi controlli espliciti current_user_can().
Archiviazione Sicura dei Dati
Non archiviare mai dati sensibili in chiaro. Se devi archiviare chiavi API, token o password, usa le funzioni di crittografia di WordPress o, meglio ancora, lascia che l'utente le inserisca ogni volta piuttosto che archiviarle del tutto.
Per archiviare le credenziali API, usa la Options API con valori crittografati. WordPress non fornisce crittografia integrata, ma puoi usare openssl_encrypt() e openssl_decrypt() con una chiave derivata dalla costante AUTH_KEY del sito.
Non archiviare le credenziali nei file del plugin, nemmeno come costanti. Saranno visibili a chiunque possa leggere il codice sorgente del tuo plugin, e saranno esposte se il tuo plugin viene inviato alla directory WordPress.org.
Gestione Sicura dei File
Se il tuo plugin gestisce caricamenti di file, devi validare i tipi di file, controllare le dimensioni, scansionare i contenuti dannosi e archiviare i file in una posizione non accessibile direttamente dal web. Usa wp_handle_upload() per i caricamenti standard, che gestisce molti controlli di sicurezza automaticamente.
Per i download di file, non accettare mai un percorso file dall'utente. Usa un ID o una chiave che mappi a un file sul tuo server. Questo previene gli attacchi di path traversal in cui un attaccante richiede file al di fuori della tua directory prevista.
Il punto fondamentale
La sicurezza WordPress non è complicata. Le regole sono consolidate: sanifica l'input, escapa l'output, usa prepared statement, verifica i nonce, controlla le capability e archivia i dati in modo sicuro. Seguire queste pratiche in modo coerente previene il 99% delle vulnerabilità comuni.
Se pubblichi nella directory dei plugin WordPress.org, il tuo plugin sarà sottoposto a revisione di sicurezza. Superare quella revisione dovrebbe essere il tuo pavimento, non il tuo soffitto. Tratta la sicurezza come una pratica continua, non come una checklist una tantum, e i tuoi utenti ne trarranno beneficio.
