L'OWASP Top 10 2021 e' un buon punto di partenza per ragionare di sicurezza applicativa, ma e' anche la lista che piu' frequentemente viene citata senza essere veramente applicata. La maggior parte dei team di sviluppo italiani che incontriamo conosce la lista. Pochissimi hanno strumenti automatici che verificano costantemente la conformita'. Praticamente nessuno ha integrato la sicurezza nel ciclo CI/CD in modo che un commit pericoloso venga bloccato prima di arrivare in produzione.
In questo articolo raccontiamo come abbiamo aiutato alcuni nostri clienti a passare dal "abbiamo letto OWASP" al "OWASP e' nel nostro processo di rilascio".
A01 — Broken Access Control
La categoria che ricorre piu' spesso nei pentest che abbiamo eseguito. Pattern tipici osservati: oggetti accessibili tramite ID consecutivi prevedibili (/api/invoice/123 dove 123 e' un ID auto-increment), assenza di controllo lato server su risorse di proprieta' di altri tenant, ruoli applicativi gestiti solo lato frontend.
Mitigazione pratica: ogni endpoint che restituisce o modifica risorse di un utente deve verificare ownership a livello di repository/query, non a livello di route. Usare UUID v4 al posto di auto-increment per gli ID esposti. Implementare politiche di accesso dichiarative (attribute-based o role-based) testate con suite automatica.
A02 — Cryptographic Failures
Categoria spesso fraintesa come "usare TLS". In realta' include: password non hashate correttamente (MD5, SHA1, bcrypt con cost factor 4), dati sensibili in cleartext nel database (CF, IBAN, dati sanitari), JWT firmati con HS256 e secret debole, cookies senza flag Secure e HttpOnly.
Standard 2026: password con Argon2id (memory 64MB, iterations 4, parallelism 2), dati strategici cifrati a riposo con chiave KMS-managed, JWT con RS256 chiavi 2048+ ruotate ogni 90 giorni, secrets fuori dal repository sempre.
A03 — Injection
SQL injection e XSS sono ancora vivi nel 2026. Negli audit recenti abbiamo trovato SQLi in form di ricerca con concatenazione di stringhe, XSS riflesso in pagine di errore custom, XSS persistito in commenti utente non sanitizzati, comando shell injection in upload di file processati con tool esterni.
Pattern di protezione: prepared statement obbligatori per ogni query con input utente, output escaping context-aware (HTML vs JS vs URL vs attribute), Content Security Policy stretta che blocca eval e inline script. Per Twig, mai disabilitare l'auto-escape; per React, mai usare dangerouslySetInnerHTML con input utente.
A04 — Insecure Design
La categoria piu' difficile da automatizzare. Riguarda decisioni architetturali fatte male. Esempi: workflow di reset password che permette enumerazione utenti, sistema di rate-limit per IP che non protegge da botnet, autenticazione a fattore singolo per operazioni finanziarie, segregazione di dati multi-tenant ottenuta solo a livello applicativo.
Mitigazione: threat modeling almeno una volta per progetto, prima dello sviluppo. Workshop di 2-3 giornate con il team tech + business per identificare gli scenari di abuso e progettare le contro-misure architetturali. Costo: 5-15k. Beneficio: evita rifacimenti costosi post-lancio.
A05 — Security Misconfiguration
Configurazioni default lasciate in produzione, header HTTP mancanti (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy), backup di database accessibili pubblicamente su S3, pannelli admin esposti senza WAF, debug mode in produzione.
Strumenti utili: Security Headers (securityheaders.com), Mozilla Observatory, Trivy per scan container image. Integrazione in CI: ogni deploy passa attraverso uno scan automatico, build fallisce se mancano header critici.
A06 — Vulnerable and Outdated Components
Categoria che si previene SOLO con automazione. Manualmente e' impossibile tenere traccia di librerie patchate. Strumenti: Dependabot (GitHub), Renovate (auto-update), Snyk (alert proattivi), Trivy (scan container), composer-audit + npm-audit + pip-audit nei pipeline CI.
Pratica: ogni Pull Request che introduce o aggiorna dipendenze passa attraverso audit automatico; build fallisce se introduce CVE high/critical non documentati. Settimanale: revisione manuale delle proposte di update auto.
A07 — Identification and Authentication Failures
Login senza rate-limiting, brute-force possibile per ore, sessioni con lifetime infinito, recupero password con domanda "nome del cane", autenticazione MFA disponibile ma non obbligatoria per admin.
Standard moderno: rate-limit aggressivo (5 tentativi per IP+username in 15 minuti, poi captcha o lockout 1 ora), session con rotazione token su login/privilege change, lifetime configurabile per ruolo (admin 1h, utente 24h), MFA obbligatoria per ruoli sensibili, password reset via link signed con expire 1h e single-use.
A08 — Software and Data Integrity Failures
Categoria che copre attacchi alla supply chain: pacchetti npm/pypi malevoli typosquatting, CI/CD pipeline che eseguono codice non firmato, aggiornamenti software via canali non autenticati, deserialization di dati non firmati.
Pratica: SBOM (Software Bill of Materials) generato automaticamente a ogni release, package-lock.json / Pipfile.lock obbligatorio in repository, scan SCA (Software Composition Analysis) prima del deploy, container image firmate con Sigstore/Cosign.
A09 — Security Logging and Monitoring Failures
Il caso classico: l'attacco e' avvenuto due settimane fa e nessuno se ne accorge perche' i log non sono analizzati. Eventi critici (login falliti ripetuti, accessi admin fuori orario, modifiche di permessi, query massive) non hanno alert real-time.
Standard minimo per qualsiasi progetto enterprise: log centralizzato (Loki, ELK, CloudWatch), alert su pattern critici tramite regole, retention 12 mesi, dashboard di overview per CISO/CIO con KPI di sicurezza, runbook per incident response definito prima dell'incidente.
A10 — Server-Side Request Forgery
L'utente puo' fare in modo che il vostro server faccia una richiesta HTTP a una URL controllata dall'attaccante. Tipico in feature di "importa immagine da URL", "genera anteprima link", proxy webhook.
Mitigazione: lista bianca rigorosa di host autorizzati, validazione DNS (no IP privati, no localhost, no 169.254.169.254 AWS metadata), timeout aggressivi, network policy che impedisce ai container applicativi di raggiungere subnet interne sensibili.
FAQ
Quanto costa fare bene la security su un progetto medio?
Il 10-15% del budget di sviluppo, se integrata da subito. Se aggiunta a posteriori dopo un audit, il 30-50% per recuperare il debito.
Servono pentest manuali oppure basta l'automazione?
Servono entrambi. Automazione (SAST, DAST, dependency scan, container scan) intercetta l'80% delle vulnerabilita' note. Pentest manuali pre-go-live e annuali intercettano il 20% delle vulnerabilita' di logica/business che gli scanner non vedono.
Conviene seguire anche standard ulteriori come ISO 27001 o NIS2?
Per PMI sotto 250 dipendenti, ISO 27001 e' over-engineering finche' non lo richiede un cliente. NIS2 e' obbligatoria per molte categorie (energia, sanita', finanza, alcuni servizi digitali) dal 2024. Vale la pena assessment di applicabilita'.
Quale strumento usare per partire?
Semgrep (SAST, free e ottimo), OWASP ZAP (DAST automatico), Trivy (scan container e dipendenze), gitleaks (no secret in repo), securityheaders.com (header HTTP). Tutti gratis o open. Setup CI 2 giorni di lavoro.
Conclusione
OWASP Top 10 non e' una checklist, e' una bussola. Diventa efficace quando i suoi principi sono codificati in regole automatiche che bloccano i commit pericolosi prima del deploy. Investire in automazione di sicurezza ha ROI altissimo: la prossima violazione costa molto piu' degli strumenti per prevenirla.
Per un assessment del vostro stack applicativo, apriamo un confronto tecnico.