La sicurezza web è uno di quei temi che tutti "considerano importanti"… finché non succede qualcosa. Poi improvvisamente diventa la priorità assoluta. Classico.
Nel 2026 il livello medio degli attacchi è salito. Non servono più hacker da film: tool automatici, bot e script pronti bastano per trovare falle in pochi minuti. La differenza tra un progetto sicuro e uno vulnerabile non è la fortuna. È come è stato progettato fin dall'inizio.
1. OWASP Top 10: la base (che molti ignorano comunque)
L'OWASP Top 10 è la lista delle vulnerabilità più critiche nelle web app. Non è teoria accademica: è ciò che viene sfruttato davvero, ogni giorno.
Le categorie principali
- Broken Access Control
- Cryptographic Failures
- Injection
- Insecure Design
- Security Misconfiguration
- Vulnerable and Outdated Components
- Identification and Authentication Failures
- Software and Data Integrity Failures
- Security Logging and Monitoring Failures
- Server-Side Request Forgery (SSRF)
Tradotto: se ignori questa lista, stai costruendo una porta aperta.
2. Broken Access Control (il problema più sottovalutato)
Succede quando un utente riesce ad accedere a dati non autorizzati, modificare risorse altrui o bypassare i permessi previsti. Un esempio classico: cambiare un ID nell'URL e accedere ai dati di un altro utente senza alcun controllo lato server.
Come proteggerti
- controlli di autorizzazione rigorosi lato server, sempre
- mai fidarsi dei dati provenienti dal client
- validare ogni richiesta rispetto ai permessi dell'utente autenticato
3. Injection (SQL, NoSQL, command, ecc.)
Classico intramontabile. Ancora devastante. Il problema è semplice: input utente non sanitizzato porta a esecuzione di codice non voluto. SQL Injection, Command Injection e le loro varianti moderne sono tra le vulnerabilità più sfruttate.
Soluzioni
- prepared statements e query parametrizzate
- ORM sicuri con sanitizzazione automatica
- validazione rigorosa di tutti gli input
Se concateni stringhe nelle query, stai chiedendo problemi.
4. Cryptographic Failures (dati sensibili esposti)
Errori comuni
- password salvate in chiaro o con algoritmi deboli
- algoritmi crittografici obsoleti come MD5 o SHA-1
- dati sensibili trasmessi senza HTTPS
Best practice
- usa bcrypt o argon2 per l'hashing delle password
- HTTPS ovunque, senza eccezioni
- mai salvare dati sensibili in chiaro nel database
5. Insecure Design (il problema nasce prima del codice)
Qui il punto è scomodo: non è un bug. È un errore di progettazione che nessuna patch può correggere completamente.
- flussi applicativi senza controlli di sicurezza integrati
- logiche di business vulnerabili per come sono state concepite
- mancanza di rate limiting e throttling
Se il design è sbagliato, il codice perfetto non salva nulla.
6. Security Misconfiguration
Il modo più veloce per farsi bucare. Non serve un attacco sofisticato: basta una configurazione sbagliata.
Errori tipici
- modalità debug attiva in produzione
- directory o file di configurazione esposti pubblicamente
- header di sicurezza HTTP mancanti o mal configurati
Checklist
- disabilita debug e informazioni di errore in produzione
- configura correttamente tutti gli ambienti
- implementa security headers su ogni risposta HTTP
7. Vulnerable and Outdated Components
Usi librerie e dipendenze. Tutti lo fanno. Il problema sono le versioni obsolete con vulnerabilità note e non patchate.
- aggiornamenti regolari di tutte le dipendenze
- audit periodico con strumenti dedicati
- tool automatici come Snyk o Dependabot per il monitoraggio continuo
8. Authentication & Session Management
Errori comuni
- password deboli permesse senza policy
- sessioni non invalidate correttamente al logout
- token di sessione esposti in URL o log
Best practice
- autenticazione robusta con MFA dove possibile
- gestione sicura dei token con scadenza appropriata
- invalidazione delle sessioni attive al logout e al cambio password
9. SSRF (Server-Side Request Forgery)
Quando il server può fare richieste verso URL arbitrari, un attaccante può sfruttarlo per raggiungere servizi interni, metadata cloud o API protette che non dovrebbero essere accessibili dall'esterno.
Difesa
- whitelist degli URL e domini autorizzati
- validazione rigorosa di tutti gli input che contengono URL
- blocco delle richieste verso reti interne e indirizzi riservati
10. Logging e monitoring (o scopri l'attacco quando è tardi)
Molti sistemi non loggano abbastanza e non monitorano anomalie. Il risultato è che un attacco può andare avanti per giorni o settimane prima che qualcuno se ne accorga.
- logging strutturato di tutte le operazioni critiche
- alert automatici su comportamenti anomali e soglie superate
- analisi continua dei log con retention adeguata
11. Best practice fondamentali (quelle vere)
Input validation
- valida sempre lato server, senza eccezioni
- non fidarti mai dei dati provenienti dal client, anche se sembrano sicuri
Principle of least privilege
- ogni servizio, utente e processo ha solo i permessi strettamente necessari
Rate limiting
- blocca gli attacchi brute force con limiti per IP e utente
- limita le richieste alle API per prevenire abusi
HTTPS obbligatorio
- nessuna eccezione, neanche in sviluppo o staging
Security headers
- Content Security Policy (CSP) per prevenire XSS
- X-Frame-Options per prevenire clickjacking
- X-Content-Type-Options per prevenire MIME sniffing
12. DevSecOps: sicurezza integrata, non aggiunta dopo
Nel 2026 la sicurezza non è "la controlliamo prima del lancio". È parte integrante del processo di sviluppo, dal primo commit all'ultimo deploy.
Pipeline moderna
- code review con checklist di sicurezza
- static analysis automatica ad ogni push
- vulnerability scan delle dipendenze
- test automatici di sicurezza in CI/CD
13. Protezione lato frontend (sì, serve comunque)
Anche se la sicurezza vera è server-first, il frontend è comunque un vettore di attacco da non trascurare:
- prevenzione XSS con sanitizzazione dell'output
- gestione sicura dei token senza esposizione in localStorage
- politiche CSP restrittive per limitare script non autorizzati
14. Error handling intelligente
Errori troppo dettagliati aiutano gli attaccanti a capire la struttura dell'applicazione. Errori troppo vaghi frustrano gli utenti legittimi. L'equilibrio giusto è questo:
- messaggi generici e non tecnici lato client
- dettagli completi e strutturati solo nei log server
15. Backup e disaster recovery
Prima o poi qualcosa succede: un attacco, un errore umano, un guasto. Devi essere pronto.
- backup automatici verificati regolarmente
- processo di restore testato periodicamente
- piano di emergenza documentato e conosciuto dal team
Se non hai mai testato un restore, non hai un backup. Hai solo una speranza.
Conclusione
La sicurezza web nel 2026 non è un'opzione. È una responsabilità verso gli utenti, i dati e il business.
Le vulnerabilità più gravi non sono nuove, non sono complesse e sono evitabili con le pratiche giuste. La differenza la fa chi progetta con la sicurezza in mente dall'inizio, applica best practice in modo sistematico e monitora costantemente.
Gli altri imparano dopo un attacco. E di solito costa molto più di quanto sarebbe costato farlo bene dall'inizio.