Penetration testing di un'applicazione web: come funziona davvero in un'azienda
Un penetration test non è uno scan automatico: è un percorso metodico dalla ricognizione allo sfruttamento controllato. Cosa accade davvero quando si testa un'applicazione web in azienda: le fasi, le vulnerabilità che si trovano più spesso (auth, logica applicativa, injection di seconda mano), come si distingue un finding reale da un falso positivo e come il report si traduce in remediation prioritizzate. Dalla prospettiva di chi attacca per difendere. Continua a leggere
Ultima modifica:
Attivare l'autenticazione a due fattori su un pannello di posta sembra una spunta da mettere, finché non ti accorgi che il codice via email finirebbe su una casella tecnica che per standard è recapitata all'operatore e non al cliente. Il difetto non è il secondo fattore: è che l'identità di accesso è una casella e non una persona. Il percorso di rimedio in tre passi, come si convive con i due sistemi durante la transizione, e le scadenze NIS2 reali che lo rendono urgente. 
Un setup Docker per Laravel che funziona uguale in sviluppo e in produzione elimina la classe di bug che si manifestano solo sul server. Come containerizzare un'applicazione Laravel in modo pulito: ambiente di sviluppo riproducibile, Dockerfile multi-stage per la produzione, gestione separata di code, cache e asset, e i punti dove la configurazione dev e prod deve divergere. Pattern concreti, non un docker-compose copiato. 
Aggiungere il single sign-on a un prodotto che gira anche presso clienti senza identity provider non è mettere un flag: è progettare due forme del prodotto che convivono nello stesso codice. E siccome il flusso coinvolge due applicazioni, la modalità effettiva non è una configurazione ma un'intersezione, che va scoperta invece che assunta. Il pattern della negoziazione, il degrado direzionale, la macchina a cinque stati e come si collauda un prodotto che le ha tutte. 
Per una PMI italiana l'AI Act passa dall'astratto al concreto con l'enforcement del 2 agosto 2026. Cosa fare nella pratica: censire i sistemi AI usati e il loro ruolo, applicare gli obblighi di trasparenza dell'Art. 50 dove si genera o si usa contenuto AI, capire quali fornitori GPAI sono coinvolti. I primi adempimenti operativi, distinguendo ciò che è in vigore da ciò che è ancora provvisorio per via del Digital Omnibus. 
Il collegamento che porta l'utente da un'applicazione all'altra già autenticato e sulla risorsa giusta è la funzionalità che tutti vogliono e che quasi nessuno implementa senza aprire un buco. Il problema non è l'autenticazione, che il protocollo risolve: è che un URL è un dato che l'utente controlla, e ogni parametro che ci metti diventa qualcosa su cui qualcuno proverà a barare. L'invariante che ho adottato, i vettori che ho provato e i compromessi che ho accettato. 
Bash resta il collante dell'automazione infrastrutturale, ma lo script usa e getta non scala. Pattern enterprise per scrivere automazione Bash manutenibile: funzioni riutilizzabili, strict mode con set -euo pipefail, gestione robusta degli errori e dei default, logging strutturato. Come trasformare una collezione di script in una toolchain affidabile per gestire un parco di VPS senza sorprese al primo edge case. 
Mettere i permessi dentro il token è la prima ottimizzazione che viene in mente e la più difficile da disfare: risparmia una query e, in cambio, rende la revoca inefficace fino alla scadenza. Ma rileggerli non basta, perché fra il controllo e l'uso resta una finestra in cui lo stato può cambiare. Il pattern che chiude entrambe le falle, il codice che lo implementa e la disciplina che impedisce a un'operazione nuova di sfuggire alla classificazione. 
I crawler AI consumano il contenuto di un sito senza generare visite: per un publisher la questione è governarli, non solo bloccarli. Gli strumenti Cloudflare per farlo: managed robots.txt, Pay Per Crawl, Content Signals, e come distinguere i crawler legittimi dal probing ostile. Hardening oltre robots.txt per chi vuole restare citabile dagli assistant AI senza farsi svuotare il contenuto, con i tradeoff tra visibilità e controllo. 
C'è un momento, in ogni migrazione verso il single sign-on, in cui l'applicazione smette di avere la password dell'utente. Sembra un progresso e lo è, ma se quella password serviva anche ad accedere ai dati, in quell'istante hai silenziosamente rimosso il controllo di accesso e nessun test se ne accorge. Come ho ricostruito il recinto a livello applicativo, perché un solo livello non basta, come si enumera davvero la superficie da proteggere, e il buco cross-tenant che l'audit ha trovato.