Pagina 5 di 6
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.
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
Quando lo sviluppatore freelance scompare e l'account del provider è intestato alla sua partita IVA, il server dedicato non è solo un problema tecnico: è una questione di proprietà legale, credenziali irrecuperabili e certificati in scadenza. Il caso reale di un cliente genovese del settore nautico B2B, un Hetzner AX51-NVMe con Magento 2 e gestionale custom in produzione, e i sei giorni di lavoro con cui ho restituito al titolare il controllo completo dell'infrastruttura. Continua a leggere
Un attacco di credential stuffing che genera 14.000 richieste al minuto su un'infrastruttura PMI è la cosa più simile a un'emergenza notturna che capita a chi gestisce server PHP in produzione. Il caso reale di un cliente toscano del marzo 2025, la pipeline di difesa stratificata Nginx + Fail2ban + Cloudflare con cui ho riportato il sito a regime in 47 minuti, e il decalogo operativo per non farsi cogliere impreparati. Continua a leggere
Quando un sito PHP viene compromesso su un server Hetzner o OVH, il riflesso istintivo del cliente è "rimuovere i file infetti e ripartire". È sbagliato e fa danni. Il protocollo corretto è cinque fasi strutturate: contenimento immediato senza distruggere evidenze, raccolta forensics, eradicazione completa, ripristino da fonte fidata, hardening permanente. E sotto NIS2 va aggiunta una sesta fase giuridica: la notifica al Garante entro 72 ore. 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.
