Le 10 vulnerabilità del codice da cercare nel 2026

La maggior parte delle violazioni nasce ancora da una manciata di classi di bug ben note. I framework sono diventati più sicuri, ma gli errori si sono spostati: negli handler delle API, nei job in background, nel codice di infrastruttura e nel collante tra i servizi. Questa è la lista che controlliamo per prima in ogni audit, con il CWE che troverai in un report di CodeAuditAgent.

1. Controllo degli accessi violato (CWE-639, CWE-862)

È di gran lunga la vulnerabilità grave più comune: un endpoint carica un record tramite ID senza verificare che appartenga a chi fa la richiesta. L'autenticazione ti dice chi è qualcuno; l'autorizzazione deve avvenire su ogni singola query.

// Scope every lookup to the owner
const invoice = await db.invoice.findFirst({
  where: { id, userId: session.user.id },
});

2. Injection (CWE-89, CWE-78)

SQL costruito concatenando stringhe, comandi shell ed espressioni di template sono ancora ovunque, di solito in quell'unica query che qualcuno ha scritto a mano per motivi di performance. Parametrizza la query o passa gli argomenti come array; non concatenare mai l'input.

3. Segreti hardcoded (CWE-798)

Chiavi API committate nel repository, token di test che si sono rivelati attivi, chiavi private nei file di configurazione. Spostali in variabili d'ambiente o in un secret manager e ruota tutto ciò che sia mai stato committato: cancellare la riga non cancella la cronologia.

4. Server-side request forgery (CWE-918)

Qualsiasi funzionalità che recupera un URL fornito dall'utente, come webhook, anteprime dei link o importazioni, può essere puntata verso la tua rete interna o l'endpoint dei metadati cloud. Usa una allowlist di host, risolvi e verifica l'IP e blocca gli intervalli privati.

5. Cross-site scripting (CWE-79)

I framework moderni applicano l'escaping per impostazione predefinita, quindi oggi l'XSS si nasconde nelle scappatoie: prop con HTML grezzo, renderer markdown e URL inseriti negli attributi href. Sanifica l'HTML con una libreria affidabile e rifiuta gli URL javascript:.

6. Deserializzazione insicura ed eval (CWE-502, CWE-95)

Pickle, il caricamento di YAML, gli object stream di Java e l'eval dinamico trasformano i dati in codice. Usa loader sicuri e JSON validato tramite schema.

7. Crittografia debole (CWE-327, CWE-330)

MD5 o SHA-1 per le password, IV statici, Math.random() per i token. Usa un algoritmo di hashing delle password pensato per questo scopo (Argon2id, bcrypt, scrypt) e una sorgente di numeri casuali crittograficamente sicura.

8. Open redirect (CWE-601)

Un parametro next o returnTo che accetta qualsiasi URL trasforma il tuo dominio in un trampolino affidabile per il phishing. Accetta solo percorsi relativi della stessa origine.

9. Rate limiting assente (CWE-307, CWE-770)

Login, reset della password, OTP e qualsiasi endpoint che ti costa denaro (email, SMS, chiamate AI) hanno bisogno di limiti per utente e per IP. Senza di essi, gli attacchi brute force e quelli che fanno esplodere la bolletta sono banali.

10. Configurazione di sicurezza errata (CWE-16)

CORS con wildcard e credenziali, modalità debug in produzione, stack trace dettagliati, policy dei bucket troppo permissive. Raramente sembrano bug in una code review perché vivono nella configurazione, ed è proprio per questo che vanno revisionati come codice.

Come usare questa lista

• Controlla le classi da 1 a 3 in ogni pull request; sono quelle con l'impatto maggiore e le più facili da non notare.
• Tratta la configurazione dell'infrastruttura e della CI come codice soggetto a revisione.
• Registra il CWE in ogni vulnerabilità rilevata, così da poter tracciare le correzioni e misurare le tendenze.