OWASP Top 10:2025 spiegata per WordPress
L'OWASP Top 10:2025 applicata a WordPress: come si presenta ogni rischio in plugin, temi e impostazioni e quali controlli possono fare titolari e sviluppatori.
Anche in: English Deutsch Français Español Polski Português Türkçe
L'OWASP Top 10 è l'elenco più noto dei rischi di sicurezza per le applicazioni web, e la sua edizione 2025 sostituisce quella del 2021. Applicata a WordPress, si legge come una mappa dei modi in cui i siti vengono violati davvero: controlli dei permessi mancanti nei plugin, configurazioni trascurate e componenti obsoleti o abbandonati.
Questa guida traduce ciascuno dei dieci rischi nel linguaggio di WordPress e mostra quali possono verificare già oggi i titolari dei siti e quali possono essere corretti solo dagli sviluppatori, nel codice.
Che cos'è l'OWASP Top 10, e che cosa non è
L'elenco è pubblicato dalla OWASP Foundation, una comunità senza scopo di lucro dedicata alla sicurezza del software. OWASP lo definisce «a standard awareness document for developers and web application security» (un documento di sensibilizzazione di riferimento per gli sviluppatori e per la sicurezza delle applicazioni web): una classifica delle categorie di rischio più critiche, costruita a partire da dati sulle vulnerabilità e da un sondaggio nella comunità.
Non è una certificazione, e nessun sito è «conforme a OWASP». Serve a decidere dove guardare per primo. Per un elenco dettagliato di requisiti verificabili, OWASP pubblica un documento apposito, l'Application Security Verification Standard (ASVS).
Che cosa cambia nel 2025
Rispetto al 2021, l'OWASP Top 10:2025 introduce due nuove categorie e qualche spostamento:
- A03 Software Supply Chain Failures è nuova e riguarda la catena di fornitura del software. Allarga la vecchia categoria «Vulnerable and Outdated Components» a tutto ciò con cui si costruisce e si aggiorna il software.
- A10 Mishandling of Exceptional Conditions è nuova: gestione carente degli errori, errori logici e sistemi che, quando qualcosa va storto, restano aperti («fail open»).
- La server-side request forgery (SSRF) non è più una categoria a sé: ora rientra in A01 Broken Access Control.
- Security Misconfiguration è salita dal quinto al secondo posto.
- A09 ora si chiama Security Logging and Alerting Failures, a ricordare che i log che nessuno legge non servono a nulla.
I dieci rischi tradotti per WordPress
| OWASP 2025 | Come si presenta in WordPress | Primo controllo |
|---|---|---|
| A01 Broken Access Control | Endpoint AJAX o REST dei plugin senza verifica di capability o nonce | Ruoli ed endpoint dei plugin |
| A02 Security Misconfiguration | Errori visibili sul sito in produzione, elenchi delle directory aperti, backup nella web root | Impostazioni di debug, configurazione del server |
| A03 Software Supply Chain Failures | Plugin e temi obsoleti, abbandonati o «nulled» | Inventario dei plugin |
| A04 Cryptographic Failures | HTTPS non ovunque, chiavi trapelate o un backup di wp-config.php scaricabile | HTTPS e segreti |
| A05 Injection | SQL injection e cross-site scripting nel codice di plugin o temi | Revisione del codice, aggiornamenti |
| A06 Insecure Design | Funzioni che si fidano del browser, per esempio un prezzo inviato dal client | Revisione della progettazione |
| A07 Authentication Failures | Password deboli o riutilizzate, nessun secondo fattore, tentativi di login illimitati | 2FA, limiti ai login |
| A08 Software or Data Integrity Failures | File del core modificati, codice iniettato, unserialize() non sicuro | Checksum |
| A09 Security Logging and Alerting Failures | Nessuna traccia di login, nuovi amministratori o modifiche ai file | Log delle attività |
| A10 Mishandling of Exceptional Conditions | Errori PHP che rivelano percorsi, controlli che concedono l'accesso quando falliscono | Impostazioni degli errori |
Anche in WordPress il controllo degli accessi difettoso (Broken Access Control) è in cima alla lista: il report di Patchstack State of WordPress Security in 2026 lo indica come la categoria di vulnerabilità più sfruttata del 2025. Patchstack è un fornitore di sicurezza: è una fonte ben informata, ma pur sempre una sola.
Cinque rischi che i titolari del sito possono verificare oggi
Per questi controlli non serve leggere codice. Ognuno richiede pochi minuti dalla bacheca o con WP-CLI.
A03: conoscere e aggiornare i componenti
La maggior parte delle vulnerabilità di WordPress si trova nei plugin e nei temi, non nel core. Conviene tenere un inventario, installare rapidamente gli aggiornamenti di sicurezza ed eliminare ciò che non si usa. Questo comando elenca i plugin per cui è disponibile un aggiornamento:
wp plugin list --update=available --fields=name,version,update_version
La nostra guida ai plugin WordPress vulnerabili tratta nel dettaglio i plugin abbandonati e le copie «nulled».
A02 e A10: nascondere gli errori ai visitatori
Un sito in produzione non dovrebbe mai mostrare errori o avvisi PHP, perché rivelano i percorsi dei file e a volte dettagli del database. In wp-config.php il debug va lasciato disattivato sull'ambiente di produzione:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
Verificare inoltre che il server non mostri l'elenco dei contenuti delle directory e che nessun file di backup o di esportazione sia raggiungibile all'interno della web root.
A07: proteggere ogni login
Attivare l'autenticazione a due fattori per tutti gli Amministratori e gli Editori e limitare i tentativi di login falliti. La nostra guida all'autenticazione a due fattori per WordPress illustra le opzioni, dalle app di autenticazione alle passkey.
A08: verificare che i file siano originali
WP-CLI confronta i file del sito con i checksum ufficiali di WordPress.org:
wp core verify-checksums
wp plugin verify-checksums --all
Qualsiasi file del core modificato o sconosciuto merita un controllo. I plugin che non provengono da WordPress.org non si possono verificare in questo modo: vanno confrontati con una copia appena scaricata dal fornitore.
A09: registrare gli eventi e ricevere avvisi
Registrare login, nuovi utenti, cambi di ruolo, installazioni di plugin e modifiche ai file, e fare in modo che qualcuno venga avvisato. Senza queste registrazioni, dopo un incidente non si riesce a ricostruire che cosa sia successo né a rispettare il termine di 72 ore per la notifica previsto dal GDPR, descritto nella nostra guida al data breach.
Tre rischi che solo gli sviluppatori possono correggere
Per chi sviluppa plugin o temi, A01, A05 e A10 si riducono soprattutto a poche funzioni di WordPress usate con coerenza.
- Controllo degli accessi (A01): verificare
current_user_can()prima di ogni azione privilegiata, validare i nonce concheck_ajax_referer()owp_verify_nonce()e assegnare a ogni route REST unpermission_callback. Da WordPress 5.5 una route che ne è priva genera un avviso (notice); per le route pensate per essere pubbliche WordPress consiglia__return_true. - SSRF (ora parte di A01): quando si richiama un URL fornito da un utente, usare
wp_safe_remote_get(). La funzione convalida l'indirizzo e ogni reindirizzamento e, per impostazione predefinita, rifiuta le reti locali e private. - Injection (A05): costruire le query con
$wpdb->prepare(), ripulire l'input nel momento in cui arriva (sanitize_text_field(),absint()) ed eseguire l'escape dell'output il più tardi possibile (esc_html(),esc_attr(),esc_url()). - Condizioni eccezionali (A10): controllare
is_wp_error()su ogni chiamata che può fallire e fare in modo che i controlli di sicurezza, se falliscono, restino chiusi («fail closed»): se una verifica dei permessi o della licenza non si può completare, l'azione va negata.
Una route REST che segue queste regole si presenta così:
register_rest_route( 'myplugin/v1', '/report', array(
'methods' => 'POST',
'callback' => 'myplugin_save_report',
'permission_callback' => function () {
return current_user_can( 'manage_options' );
},
) );
Il capitolo sulla sicurezza del manuale per sviluppatori di WordPress spiega ogni funzione con esempi.
OWASP, GDPR e NIS2
L'OWASP Top 10 non è una legge, ma è un riferimento diffuso per lo «stato dell'arte» della sicurezza web. L'articolo 32 del GDPR richiede misure tecniche adeguate e una procedura per testare, verificare e valutare regolarmente la loro efficacia. Verificare un sito WordPress rispetto alle dieci categorie è un modo pratico per dimostrare l'esistenza di questa procedura.
Per i soggetti che rientrano nella NIS2, l'articolo 21, paragrafo 2, include tra le misure minime la sicurezza nell'acquisizione, nello sviluppo e nella manutenzione, compresa la gestione delle vulnerabilità. A03 e A05 si collegano direttamente a questo obbligo.
Il nostro plugin Security Audit & Compliance associa ogni risultato a una categoria dell'OWASP Top 10:2025, accanto all'articolo 32 del GDPR e all'articolo 21 della NIS2, così che il report mostri a quale rischio appartiene un problema. Rileva e segnala; la decisione su come correggere resta a chi gestisce il sito. Ecco che cosa verifica.
Domande frequenti
L'OWASP Top 10 è un obbligo di legge?
No. È un documento di sensibilizzazione. Leggi come il GDPR richiedono una sicurezza adeguata, e la Top 10 aiuta a capire che cosa significhi in concreto per un sito web.
Con l'edizione 2025 bisogna rifare la revisione di sicurezza?
Non da zero. La maggior parte dei rischi è rimasta; basta aggiornare i propri appunti per le nuove categorie A03 e A10 e per la nuova numerazione.
Il core di WordPress è di per sé un grande rischio OWASP?
Raramente. Patchstack ha contato sei vulnerabilità nel core nel 2025, tutte a bassa priorità, contro migliaia nei plugin e nei temi. Il rischio sta nell'elenco dei plugin installati.
Questo articolo ha carattere informativo generale e non costituisce consulenza legale.
Controlla il tuo sito
Security Audit & Compliance è il plugin WordPress di secaudit.eu: cerca malware, spam nascosto, file core modificati e codice vulnerabile, e collega i risultati all’art. 32 del GDPR, all’art. 21 della NIS2 e alla OWASP Top 10.
Scopri cosa controlla il plugin