secaudit.eu
Protezione

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.

Di , AngelForce OÜ 6 min di lettura

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

Diagramma: i dieci rischi dell'OWASP Top 10:2025 raggruppati in base a dove si trovano in un sito WordPress
Dove si manifestano i dieci rischi OWASP in un tipico sito WordPress.
OWASP 2025Come si presenta in WordPressPrimo controllo
A01 Broken Access ControlEndpoint AJAX o REST dei plugin senza verifica di capability o nonceRuoli ed endpoint dei plugin
A02 Security MisconfigurationErrori visibili sul sito in produzione, elenchi delle directory aperti, backup nella web rootImpostazioni di debug, configurazione del server
A03 Software Supply Chain FailuresPlugin e temi obsoleti, abbandonati o «nulled»Inventario dei plugin
A04 Cryptographic FailuresHTTPS non ovunque, chiavi trapelate o un backup di wp-config.php scaricabileHTTPS e segreti
A05 InjectionSQL injection e cross-site scripting nel codice di plugin o temiRevisione del codice, aggiornamenti
A06 Insecure DesignFunzioni che si fidano del browser, per esempio un prezzo inviato dal clientRevisione della progettazione
A07 Authentication FailuresPassword deboli o riutilizzate, nessun secondo fattore, tentativi di login illimitati2FA, limiti ai login
A08 Software or Data Integrity FailuresFile del core modificati, codice iniettato, unserialize() non sicuroChecksum
A09 Security Logging and Alerting FailuresNessuna traccia di login, nuovi amministratori o modifiche ai fileLog delle attività
A10 Mishandling of Exceptional ConditionsErrori PHP che rivelano percorsi, controlli che concedono l'accesso quando fallisconoImpostazioni 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 con check_ajax_referer() o wp_verify_nonce() e assegnare a ogni route REST un permission_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
Melike Görel

Melike Görel scrive le guide di secaudit.eu sulla sicurezza di WordPress e sulla conformità alle norme UE per AngelForce OÜ, l’azienda di software di Tallinn che sta dietro a secaudit.eu.

Realizzato con l’aiuto dell’IA e verificato prima della pubblicazione. Questo articolo è un’informazione generale e non una consulenza legale.