A02:2025 Security Misconfiguration: hardening di server e framework

Nel 2021 era al quinto posto, attualmente, nella OWASP Top 10:2025, è salita al secondo: il 100% delle applicazioni testate presentava forme di configurazione errata. Non serve un exploit sofisticato per sfruttarla: basta che qualcuno abbia lasciato una porta socchiusa: cloud, container e infrastrutture, questo ha generato un aumento esponenziale del numero di porte da controllare.

1. Credenziali di default: la porta lasciata con la chiave di fabbrica

Lo scenario ufficiale OWASP è quasi banale nella sua semplicità: un server applicativo viene installato con applicazioni di esempio non rimosse (magari proprio una console di amministrazione) e gli account di default non vengono cambiati. L'attaccante prova la password che sta scritta nella documentazione pubblica del prodotto, ed è dentro.

admin / admin admin / password root / (vuota)

Il fix ufficiale: un processo di hardening ripetibile, automatizzato, che rimuove account, applicazioni di esempio e componenti non necessari prima che l'ambiente vada in produzione, e credenziali diverse tra sviluppo, test e produzione.

2. Verbose errors: quando l'errore racconta troppo

Uno scenario altrettanto concreto: il server è configurato per restituire messaggi di errore dettagliati (stack trace completi) direttamente all'utente. Utilissimo in sviluppo, pericoloso in produzione: espone percorsi interni, query, e versioni di componenti che potrebbero avere vulnerabilità note. Ecco un esempio di un errore dettagliato che non si dovrebbe vedere in produzione:

Fatal error: Uncaught PDOException: SQLSTATE[42S02] in /var/www/app/models/Utente.php:47 Stack trace: #0 /var/www/app/controllers/Login.php:23 #1 {main}

Il messaggio dice a chiunque il percorso reale del server, il nome del file e della classe, e persino la riga di codice coinvolta: informazioni che un attaccante userebbe per orientarsi. Il fix: una configurazione centrale che intercetta questi messaggi prima che arrivino all'utente, mostrando un errore generico e memorizzando i dettagli dell'errore in un file di log sul server. Portemmo fare un esempio: sbagliando a bussare a una porta, il citofono ci risponde con nome completo degli abitanti, orari in cui sono in casa e dove tengono le chiavi di riserva. Con un messaggio generico: «Errore, numero sbagliato» è tutto quello che serve per informare l'estraneo che ha sbagliato il numero del citofno.

3. Cloud storage aperto: il magazzino senza serratura

Lo scenario ufficiale è diretto: un cloud provider ha di default i permessi di condivisione aperti verso Internet: questo permette a dati sensibili archiviati nello storage cloud di essere raggiunti da chiunque. Non è un attacco: è un bucket lasciato pubblico per errore, o mai messo in sicurezza dopo la configurazione iniziale.

Il fix ufficiale include un compito specifico: rivedere periodicamente i permessi dello storage cloud (l'esempio citato da OWASP sono i permessi dei bucket S3), come parte dello stesso processo con cui gestisci patch e aggiornamenti: non una verifica «una volta e via». Il permesso «aperto a tutti» spesso non nasce da un attacco: nasce da una comodità temporanea mai più rivista.

4. Security header mancanti: la porta senza cartello «vietato l'ingresso»

OWASP la elenca esplicitamente tra le condizioni di vulnerabilità: il server non invia header di sicurezza, o li invia con valori non sicuri. Sono righe che il browser legge per capire come comportarsi con la tua pagina.

Strict-Transport-Security: max-age=31536000 X-Content-Type-Options: nosniff X-Frame-Options: DENY Content-Security-Policy: default-src 'self'

Il fix ufficiale li chiama esplicitamente «directive di sicurezza inviate al client»: vanno impostati esplicitamente, non lasciati ai valori (assenti) di default del server.

5. Altre configurazioni pericolose da conoscere

• Directory listing attivo: uno scenario ufficiale OWASP descrive un attaccante che semplicemente elenca il contenuto delle cartelle del server, scaricando file compilati e facendo reverse engineering del codice.
• Funzionalità inutilizzate ancora attive: porte, servizi, pagine, account o framework di test lasciati installati «per sicurezza», che in realtà aumentano solo la superficie d'attacco.
• Ambienti diversi tra loro: sviluppo, test e produzione configurati in modo incoerente rendono impossibile fidarsi che «funziona in test» significhi «è sicuro in produzione».

Fonte: OWASP Top 10:2025: A02: scenario #1 (sample application con account di default); sezione «How to prevent», hardening ripetibile con credenziali diverse per ambiente.

In sintesi

Un solo principio le riassume tutte: nessuna di queste falle richiede un genio del crimine informatico, richiedono solo qualcuno che non ha finito di sistemare casa prima di aprire la porta. Il fix, quasi sempre, è lo stesso: un processo di hardening ripetibile e verificato, non una lista di buone intenzioni.