
Sicurezza del software: 10 vulnerabilita comuni
Il 95% delle Vulnerabilita Sfruttate Sono Conosciute ed Evitabili
La maggior parte degli attacchi riusciti non sfrutta vulnerabilita zero-day sofisticate. Sfruttano falle conosciute e documentate che avrebbero potuto essere evitate con pratiche basilari di sviluppo sicuro. L'OWASP (Open Web Application Security Project) documenta le vulnerabilita piu critiche nelle applicazioni web dal 2003, e le stesse categorie compaiono ripetutamente.
Questo articolo copre le 10 vulnerabilita piu comuni, con esempi pratici e come correggerle.
1. Injection (SQL, NoSQL, Command)
L'injection si verifica quando dati non attendibili vengono inviati a un interprete come parte di un comando o di una query.
SQL Injection — esempio vulnerabile:
// NON fare MAI questo
const query = `SELECT * FROM users WHERE email = '${email}' AND password = '${password}'`;
Se l'utente inserisce ' OR '1'='1 come email, la query restituisce tutti gli utenti.
Correzione — query parametrizzate:
// Corretto: parametri separati dalla query
const result = await db.query(
'SELECT * FROM users WHERE email = $1 AND password = $2',
[email, hashedPassword]
);
Gli ORM moderni come Prisma e Drizzle utilizzano query parametrizzate di default. Il rischio emerge quando gli sviluppatori usano $queryRaw o costruiscono SQL manualmente.
2. Autenticazione Compromessa e Gestione delle Sessioni
Le falle di autenticazione includono: password deboli senza policy di robustezza, assenza di rate limiting sul login, token di sessione prevedibili, sessioni che non scadono.
Problemi comuni:
- Password conservate in chiaro o con hash MD5/SHA1
- Assenza di autenticazione a due fattori nelle operazioni critiche
- Token JWT senza scadenza o con secret debole
- Session fixation — riutilizzo del session ID dopo il login
Correzione:
// Hash corretto con bcrypt (costo minimo 10)
import bcrypt from 'bcryptjs';
const SALT_ROUNDS = 12;
const hashedPassword = await bcrypt.hash(plainPassword, SALT_ROUNDS);
// JWT con scadenza breve e refresh token
const token = jwt.sign(
{ userId: user.id },
process.env.JWT_SECRET!,
{ expiresIn: '15m' }
);
3. Esposizione di Dati Sensibili
I dati sensibili esposti includono password, token API, dati personali (codice fiscale, carta di credito), dati sanitari e dati finanziari conservati o trasmessi senza adeguata protezione.
Errori comuni:
- Dati sensibili nei log dell'applicazione
- Chiavi API nel repository Git
- Dati in cache senza TTL o senza crittografia
- Comunicazione HTTP invece di HTTPS
Correzione:
- Non loggare mai dati sensibili (
console.log(user)puo esporre la password) - Usare
.gitignoreper.enve non committare mai i secret - Crittografare i dati sensibili a riposo con AES-256
- Forzare HTTPS in tutti gli ambienti
4. XML External Entities (XXE)
Colpisce le applicazioni che processano XML. Un attaccante puo leggere file dal server, effettuare richieste interne (SSRF) o causare un denial of service.
Correzione: Disabilitare il processamento delle entita esterne nel parser XML. Nelle applicazioni moderne che usano JSON, il rischio e minimo — ma le API legacy processano ancora XML.
5. Controllo di Accesso Compromesso
Si verifica quando gli utenti riescono a eseguire azioni oltre i propri permessi. Include l'IDOR (Insecure Direct Object Reference) — accedere a risorse di altri utenti modificando un ID nell'URL.
Esempio vulnerabile:
// Vulnerabile: non verifica se l'ordine appartiene all'utente loggato
app.get('/orders/:orderId', async (req, res) => {
const order = await db.order.findUnique({ where: { id: req.params.orderId } });
res.json(order);
});
Correzione:
// Corretto: verifica la proprieta della risorsa
app.get('/orders/:orderId', authenticate, async (req, res) => {
const order = await db.order.findUnique({
where: { id: req.params.orderId, userId: req.user.id } // userId filtra per l'utente loggato
});
if (!order) return res.status(404).json({ error: 'Not found' });
res.json(order);
});
6. Configurazione di Sicurezza Errata
Configurazioni predefinite non sicure, permessi eccessivi, header HTTP assenti, porte non necessarie aperte.
Header di sicurezza essenziali:
// Next.js — next.config.js
const securityHeaders = [
{ key: 'X-Content-Type-Options', value: 'nosniff' },
{ key: 'X-Frame-Options', value: 'DENY' },
{ key: 'X-XSS-Protection', value: '1; mode=block' },
{ key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
{ key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
{
key: 'Content-Security-Policy',
value: "default-src 'self'; script-src 'self' 'unsafe-inline'"
}
];
7. Cross-Site Scripting (XSS)
L'XSS permette agli attaccanti di iniettare script malevoli nelle pagine visualizzate da altri utenti. Puo essere usato per rubare cookie di sessione, reindirizzare gli utenti o modificare il contenuto della pagina.
Tipi di XSS:
- Stored XSS: Script salvato nel database e mostrato ad altri utenti
- Reflected XSS: Script nell'URL riflesso nella risposta
- DOM-based XSS: Manipolazione del DOM tramite JavaScript lato client
Correzione: I framework moderni come React eseguono l'escape del contenuto automaticamente. Il rischio emerge con dangerouslySetInnerHTML o con la manipolazione diretta del DOM tramite innerHTML.
// Pericoloso
element.innerHTML = userInput;
// Sicuro
element.textContent = userInput;
// Oppure, se hai bisogno di HTML, usa una libreria di sanitizzazione come DOMPurify
element.innerHTML = DOMPurify.sanitize(userInput);
8. Deserializzazione Non Sicura
Deserializzare dati non attendibili puo risultare nell'esecuzione remota di codice. Colpisce principalmente linguaggi come Java e PHP, ma anche JavaScript con JSON.parse in combinazione con i prototipi.
Correzione: Validare e sanitizzare i dati deserializzati con schema (Zod, Joi) prima di processarli.
9. Utilizzo di Componenti con Vulnerabilita Note
Le dipendenze non aggiornate con CVE note sono un vettore di attacco diretto. La maggior parte dei progetti ha decine di dipendenze indirette che raramente vengono verificate.
Pratica obbligatoria:
# Verificare le dipendenze regolarmente
npm audit
# Correggere le vulnerabilita automaticamente (quando possibile)
npm audit fix
# Verificare licenze e vulnerabilita con strumento dedicato
npx snyk test
Configura gli avvisi automatici su GitHub (Dependabot) per ricevere PR automatiche quando vengono identificate dipendenze con CVE.
10. Logging e Monitoraggio Insufficienti
Senza log adeguati, gli attacchi in corso passano inosservati per giorni o settimane. Senza alert, scopri il problema quando il cliente si lamenta.
Cosa loggare:
- Tentativi di autenticazione (successo e fallimento)
- Modifiche dei permessi e accesso ai dati sensibili
- Errori di autorizzazione (403) — possono indicare un tentativo di IDOR
- Picchi anomali di richieste
Cosa NON loggare:
- Password (nemmeno come hash)
- Token di sessione completi
- Dati personali sensibili (codice fiscale, carta di credito)
Conclusione
La sicurezza non e una feature aggiuntiva — e parte dello sviluppo professionale. Le 10 categorie della OWASP Top 10 rappresentano vulnerabilita evitabili con pratiche basilari: query parametrizzate, validazione dell'input, controllo di accesso verificato lato server, dipendenze aggiornate e header corretti.
SystemForge include la revisione di sicurezza in tutti i progetti — Code Review con focus sull'OWASP, dependency audit e validazione degli header. Se vuoi verificare la sicurezza di un sistema esistente, contattaci.
Trasforma la tua idea in software
SystemForge costruisce prodotti digitali da zero fino al lancio.
Hai bisogno di aiuto?