OWASP Top 10 2025: le vulnerabilità web che ogni sviluppatore deve conoscere e risolvere

Hai mai affidato la sicurezza del tuo sito a un plugin? Lo vediamo quasi ogni settimana: sviluppatori bravissimi a scrivere codice funzionante, ma che considerano la sicurezza un optional. Poi arriva la notifica di un attacco, un defacement, o peggio: dati dei clienti esposti. Noi, di Meteora Web, gestiamo decine di progetti web e la fotografia è sempre la stessa: le vulnerabilità più comuni sono anche le più semplici da prevenire. L'OWASP Top 10 2025 elenca esattamente queste falle, e in questa guida le affrontiamo una per una con codice reale e azioni concrete.

Perché OWASP Top 10 è il tuo migliore amico (e non un nemico)

L'Open Web Application Security Project (OWASP) aggiorna periodicamente la lista delle dieci vulnerabilità più critiche per le applicazioni web. Non è un certificato da appendere al muro: è uno specchio di ciò che ogni giorno va storto nei server, nei database e nei form degli sviluppatori. Noi lo usiamo come checklist di audit. Perché un sito che ignora queste dieci cose è un sito che prima o poi verrà bucato. E quando parliamo di sicurezza nelle PMI italiane, la situazione è drammatica: backup mai configurati, credenziali in chiaro, form senza protezione. Ecco perché partiamo proprio da qui.

Le 10 vulnerabilità spiegate con codice e rimedi

Per ogni voce dell'OWASP Top 10 2025 ti mostriamo un esempio pratico di codice vulnerabile e la soluzione immediata. Non devi diventare un esperto di sicurezza: devi solo smettere di ripetere gli stessi errori.

1. Broken Access Control

Un utente normale può vedere i dati di un altro utente semplicemente modificando l'ID nell'URL? Questo è access control rotto. Esempio classico in PHP:

// VULNERABILE
$id = $_GET['id'];
$sql = "SELECT * FROM ordini WHERE id = $id";

// CORRETTO
session_start();
$id = intval($_GET['id']);
$user_id = $_SESSION['user_id'];
$sql = "SELECT * FROM ordini WHERE id = ? AND user_id = ?";
$stmt = $pdo->prepare($sql);
$stmt->execute([$id, $user_id]);

Cosa fare subito: verifica su ogni endpoint che l'utente abbia il permesso di accedere alla risorsa. Non fidarti mai dell'input.

2. Cryptographic Failures

Password salvate in chiaro? Dati sensibili trasmessi su HTTP? Siamo nel 2026, non è più accettabile. Usa password_hash() in PHP o bcrypt lato backend. Per i dati in transito, HTTPS obbligatorio e HSTS header.

// VULNERABILE
$password = $_POST['password'];
$sql = "INSERT INTO utenti (password) VALUES ('$password')";

// CORRETTO
$hash = password_hash($_POST['password'], PASSWORD_BCRYPT);
$stmt = $pdo->prepare("INSERT INTO utenti (password) VALUES (?)");
$stmt->execute([$hash]);

Cosa fare subito: attiva HTTPS su tutto il dominio. Usa Let's Encrypt per certificati gratuiti e rinnova automaticamente.

3. Injection

SQL, NoSQL, OS command injection. Il più classico: un input malevolo che modifica la query. La soluzione è sempre la stessa: parametri preparati (prepared statements).

// VULNERABILE
$username = $_POST['username'];
$sql = "SELECT * FROM utenti WHERE username = '$username'";

// CORRETTO
$stmt = $pdo->prepare("SELECT * FROM utenti WHERE username = ?");
$stmt->execute([$_POST['username']]);

Cosa fare subito: cerca nel tuo codice tutte le query costruite con concatenazione di stringhe e sostituiscile con prepared statements. Lo stesso vale per eval(), shell_exec() e funzioni simili.

4. Insecure Design

Non è solo codice: è architettura sbagliata a monte. Esempio: permettere a un utente di cambiare la propria email senza verificare la password attuale. La soluzione è nel design: security by design.

Cosa fare subito: ogni modifica di dati sensibili (email, password, indirizzo) richiede una riconferma della password o un'OTP. Non lasciare mai una backdoor nel flusso.

5. Security Misconfiguration

Errori comuni: directory listing attivo, credenziali di default, errori di debug visibili in produzione. Noi abbiamo visto server con display_errors = On in produzione. Basta un errore per esporre il percorso assoluto e il nome del database.

// In php.ini produzione
display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log

Cosa fare subito: esegui uno scan con SecLists o uno scanner automatico (Nikto, Wapiti). Disattiva tutto ciò che non serve.

6. Vulnerable and Outdated Components

WordPress, plugin, librerie JavaScript. Se non aggiorni, sei esposto. Lo abbiamo visto con clienti che usavano jQuery 1.x con vulnerabilità note.

Cosa fare subito: configura un sistema di aggiornamento automatico per le dipendenze (Dependabot, Renovate). Controlla almeno una volta al mese la lista delle librerie usate su CVE.

7. Identification and Authentication Failures

Sessioni non invalidate, password deboli, assenza di 2FA. Se un attacker riesce a impersonare un utente, la festa è finita.

// VULNERABILE: logout senza distruggere la sessione
session_start();
unset($_SESSION['user_id']);

// CORRETTO
session_start();
session_destroy();
setcookie(session_name(), '', time()-3600, '/');

Cosa fare subito: implementa 2FA (via TOTP o SMS). Usa session_regenerate_id() dopo il login. Imposta un timeout di inattività.

8. Software and Data Integrity Failures

Aggiornamenti non firmati, dipendenze da CDN non verificati, mancanza di checksum. Un attacker può iniettare codice malevolo in una libreria che carichi da un server non sicuro.

Cosa fare subito: usa Subresource Integrity (SRI) per tutti i CDN. Firma i tuoi aggiornamenti con GPG. Verifica sempre l'hash dei pacchetti installati.

9. Security Logging and Monitoring Failures

Se non tracci gli accessi, non puoi sapere se sei stato attaccato. Moltissime PMI non hanno log di accesso, e quando li hanno non li analizzano.

// Esempio di logging minimo
$log = date('Y-m-d H:i:s') . " - " . $_SERVER['REMOTE_ADDR'] . " - " . $event . PHP_EOL;
file_put_contents('/var/log/app.log', $log, FILE_APPEND);

Cosa fare subito: attiva i log di accesso sul server (Apache/Nginx). Configura un alert per tentativi di login falliti. Usa strumenti come ELK Stack per centralizzare.

10. Server-Side Request Forgery (SSRF)

Se la tua applicazione fa richieste HTTP a URL fornite dall'utente, un attacker può farla connettere a server interni (es. 127.0.0.1, metadati cloud).

// VULNERABILE
$url = $_GET['url'];
$content = file_get_contents($url);

// CORRETTO
$allowed_hosts = ['api.mioservizio.com', 'cdn.trusted.com'];
$parsed_url = parse_url($url);
if (!in_array($parsed_url['host'], $allowed_hosts)) {
    die('URL non consentito');
}

Cosa fare subito: whitelist degli host consentiti. Blocca IP privati e di metadati cloud (169.254.169.254, 100.100.100.200).

Come integrare queste verifiche nel workflow quotidiano

Non serve diventare paranoidi. Basta inserire strumenti automatici nel tuo flusso di sviluppo. Noi usiamo:

• Static Analysis: PHPStan / Psalm per PHP, ESLint con plugin security per JS.
• DAST: OWASP ZAP o Nikto per scan periodici in staging.
• CI/CD: GitHub Actions che lanciano tests di sicurezza su ogni push.

Se usi WordPress, controlla i plugin con WPScan. Per i gestionali Laravel, PHP Insights ti dice già molte cose.

In sintesi — cosa fare adesso

1. Fai un audit della tua applicazione con OWASP Top 10 come checklist.
2. Correggi subito le vulnerabilità di tipo Injection, Broken Access Control e Cryptographic Failures: sono le più facili da sfruttare.
3. Automatizza i controlli: se non hai tempo per leggere ogni riga, usa strumenti SAST/DAST.
4. Aggiorna tutte le dipendenze e configura gli aggiornamenti automatici.
5. Formati: dedica un giorno al mese alla sicurezza del tuo stack. È un investimento, non un costo.

Noi, di Meteora Web, abbiamo visto aziende perdere mesi di lavoro per una singola falla. Non lasciare che succeda a te. Se vuoi un check rapido della tua applicazione, contattaci.