Pagina 5 di 7
La maggior parte delle compromissioni non nasce da un exploit sofisticato, ma da una validazione mancante, un upload non filtrato, un secret in chiaro. La sicurezza applicativa è il livello dove un'azienda si gioca i dati dei clienti, e dove un intervento mirato vale più di qualsiasi appliance perimetrale. Questa categoria vive lì, dentro il codice.
Il primo tema sono le classi di vulnerabilità che continuano a colpire: OWASP Top 10 applicata sul serio, XSS, SQL injection, SSRF e attacchi alla logica che il WAF non vede, autenticazione fatta bene (JWT senza le trappole dell'algorithm confusion, OAuth, WebAuthn e passwordless), crittografia con libsodium invece che a mano, sicurezza degli upload. Non teoria: gli errori che trovo davvero negli assessment, con la difesa corrispondente.
Il secondo tema è la difesa lungo tutta la pipeline: gestione dei segreti e rotazione delle credenziali, security testing automatico (SAST e DAST) in CI, protezione della supply chain con Composer, WAF configurato per non bloccare il traffico legittimo. La sicurezza applicativa non è un controllo finale, è una postura che attraversa sviluppo e rilascio.
Il terzo tema è la nuova superficie del codice AI-generated, che entra in produzione più in fretta di quanto venga revisionato e porta con sé classi di vulnerabilità ricorrenti: capirle e auditarle in modo sistematico è ormai parte del mestiere.
Se vuoi un audit di sicurezza applicativo o mettere in sicurezza un'applicazione, vedi la consulenza cybersecurity e NIS2 o scrivimi.
La sicurezza che funziona è quella scritta nel codice, non quella comprata e mai configurata.
Ho trovato un SSRF in un sistema di webhook di un SaaS Laravel durante un assessment. Il client HTTP di Laravel, senza validazione dell'URL di destinazione, permetteva di raggiungere i metadata AWS e l'intranet del cliente. Vi spiego il percorso di exploitation completo e le tre righe di codice che lo avrebbero impedito. Continua a leggere
Dopo aver introdotto PHPStan a livello 9 su un progetto Laravel legacy con 80.000 righe di codice, ho trovato 340 errori di tipo - di cui 12 erano vulnerabilità di sicurezza reali, tra cui due SQL injection potenziali e una IDOR. L'analisi statica non sostituisce il pen test, ma lo rende più efficiente. Continua a leggere
Lo XSS stored che ho trovato in un CMS proprietario di un cliente media non era ovvio: si attivava solo in un campo amministrativo raramente utilizzato. Il payload sopravviveva a tre livelli di sanitizzazione perché ognuno usava una libreria diversa. Vi mostro la catena di bypass e come costruire una CSP che regge. Continua a leggere
In un engagement red team su un'azienda retail con tre VPS e un cluster Docker, siamo passati da un form upload con SSRF a root su tutti i server in 4 ore. Il percorso di attacco era banale ma invisibile dai tool di monitoring standard. Vi descrivo la catena di compromissione e le contromisure. Continua a leggere
Ho trovato una SQL injection in un gestionale di ordini PHP usato da un'azienda con 80 dipendenti. Il codice era del 2019, aggiornato più volte, ma la query vulnerabile era sopravvissuta a tutti i refactoring. Vi spiego perché SQLi è ancora viva, quali pattern la nascondono e come fare code review mirata. Continua a leggere
La versione 2025 dell'OWASP Top 10 introduce cambiamenti significativi rispetto al 2021, in particolare sull'insecure design e sulla sicurezza del codice generato da AI. Ho analizzato 12 applicazioni PHP di clienti PMI contro il nuovo framework: i risultati mostrano pattern di vulnerabilità diversi rispetto a cinque anni fa. Continua a leggere
In un recente assessment su un gestionale Laravel per una PMI manifatturiera, ho trovato mass assignment non protetto, IDOR su quattro endpoint API, e un file .env esposto via misconfiguration Nginx. Nessuna di queste vulnerabilità richiedeva strumenti sofisticati per essere trovata - bastava sapere dove guardare. Continua a leggere
Le credenziali del database di un cliente erano hardcoded nel file .env committato su un repo privato - privato, ma con accesso a 8 collaboratori. Quando uno di loro ha lasciato l'azienda, abbiamo scoperto che non esisteva un modo rapido per ruotare tutte le credenziali. HashiCorp Vault ha risolto il problema strutturalmente. Continua a leggere
Dopo la backdoor xz-utils e il compromise di tj-actions del 2025, ho auditato le dipendenze Composer di 12 clienti PHP: 3 avevano pacchetti con nomi sospetti, nessuno aveva allow-plugins configurato, zero SBOM. Il playbook che ho implementato: pinning, audit in CI, blocco script e SBOM CycloneDX. Continua a leggere
Un gestionale PHP 7.0 con 14 SQL injection, 23 punti XSS e un file phpinfo.php accessibile pubblicamente con tutte le credenziali visibili. L'audit che ho condotto in 3 giorni con grep, Psalm taint analysis e OWASP ZAP, e il piano di remediation che ha chiuso le 37 vulnerabilità critiche in due settimane. Continua a leggere
Tool gratuiti per verificare e irrobustire le tue applicazioni:
Audit JWT, Analisi security headers, Generatore CSP, Hash bcrypt e argon2, Cifratura AES.
