--- title: "Penetration testing di un'applicazione web: come funziona davvero in un'azienda" description: "Cosa succede davvero in un penetration test di un'applicazione web: metodologia, fasi, vulnerabilità tipiche e come si traduce in remediation per una PMI." canonical: "https://www.mauriziofonte.it/blog/post/penetration-testing-applicazioni-web-come-funziona-azienda.html" author: "Maurizio Fonte" date: "2026-08-12T08:01:19+02:00" modified: "2026-08-12T08:01:19+02:00" section: "Penetration Testing" tags: ["Penetration Testing", "Sicurezza Applicazioni"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Penetration Testing](https://www.mauriziofonte.it/blog/cat/penetration-testing.html) [Sicurezza Applicazioni](https://www.mauriziofonte.it/blog/cat/sicurezza-applicazioni.html) # [Penetration testing di un'applicazione web: come funziona davvero in un'azienda](https://www.mauriziofonte.it/blog/post/penetration-testing-applicazioni-web-come-funziona-azienda.html) Mercoledì 12 Agosto 2026, alle 08:01 ![Penetration testing di un'applicazione web: come funziona davvero in un'azienda](https://www.mauriziofonte.it/image/005060200-penetration-testing-applicazioni-web-come-funziona-azienda.jpg) Quando un'azienda mi chiede un *penetration test*, la prima cosa che chiarisco è cosa non è: non è passare uno scanner automatico sull'applicazione e consegnare il suo output. Quello è un vulnerability scan, è utile, costa poco, e trova le cose ovvie, ma chiamarlo penetration test è come chiamare "diagnosi medica" la lettura di un termometro. Un penetration test vero è un percorso metodico in cui un essere umano, con la mentalità di chi attacca, esplora un'applicazione per capire come comprometterla davvero, e lo fa trovando le cose che uno scanner non vede: la logica di business che si può aggirare, l'autorizzazione che si può scavalcare, la catena di piccoli difetti che presi singolarmente sono innocui e insieme aprono una breccia. In un'attività di penetration testing, il valore non sta negli strumenti, sta nel ragionamento. In questo articolo racconto cosa succede davvero quando si testa un'applicazione web in azienda: le fasi del lavoro, le vulnerabilità che si trovano più spesso, come si distingue un problema reale da un falso allarme, e come tutto questo si traduce in interventi concreti e prioritizzati. Dalla prospettiva di chi attacca per difendere. ## Un penetration test è uno scan automatico? No, e confondere i due è l'errore che porta le aziende a sentirsi sicure quando non lo sono. Uno **scanner automatico** confronta l'applicazione con un database di pattern di vulnerabilità note: è veloce, esaustivo sulle cose standardizzabili, e produce molti risultati, una buona parte dei quali falsi positivi. Trova la versione di un componente con una falla nota, l'header di sicurezza mancante, il pattern di SQL injection più banale. È un controllo prezioso, ma ha un limite strutturale: vede solo ciò che è stato programmato per vedere, e un attaccante reale non si limita a quello. Un **penetration test** aggiunge l'elemento che lo scanner non ha, l'intelligenza avversaria. Un tester umano capisce cosa fa l'applicazione, qual è la logica del business che implementa, dove stanno i dati che valgono, e ragiona come farebbe un attaccante motivato: non "questa pagina ha una vulnerabilità nel database delle firme", ma "se questo carrello permette di modificare il prezzo lato client e il server non lo ricontrolla, posso comprare a un euro". Questo tipo di ragionamento, sulla logica e non solo sui pattern, è ciò che nessuno scanner sa fare, ed è esattamente dove vivono le vulnerabilità più gravi e più costose delle applicazioni reali. La metodologia di riferimento del settore, la Web Security Testing Guide di [OWASP](https://owasp.org/), codifica proprio questo approccio strutturato che va oltre la scansione. > Uno scanner trova ciò che sa cercare; un attaccante trova ciò che tu non hai pensato di proteggere. Il penetration test serve a portare quel secondo sguardo, quello avversario, sul tuo sistema prima che lo faccia qualcuno con intenzioni peggiori. ## Quali sono le fasi di un penetration test? È un percorso strutturato che va dalla conoscenza del bersaglio allo sfruttamento controllato, e ogni fase prepara la successiva. La prima è la **ricognizione**: si raccoglie tutto il possibile sull'applicazione, le sue tecnologie, i suoi endpoint, il modo in cui gestisce le sessioni, la sua superficie esposta. È la fase in cui ci si fa un'idea di come è costruito il sistema, perché non si può attaccare bene ciò che non si capisce. La seconda è la **mappatura**: si esplora sistematicamente l'applicazione, si tracciano tutti i suoi punti di ingresso, i flussi, i ruoli utente, e si costruisce una mappa di dove potrebbero annidarsi i problemi. La terza fase è l'**analisi delle vulnerabilità**: si esaminano i punti mappati cercando debolezze, combinando strumenti per le verifiche meccaniche e analisi manuale per la logica. La quarta, il cuore del lavoro, è lo **sfruttamento controllato**: si prova davvero a sfruttare le debolezze trovate, ma in modo controllato e concordato, per dimostrare che la vulnerabilità è reale e capirne l'impatto effettivo. La differenza tra "questa cosa sembra vulnerabile" e "ho dimostrato che da qui si accede ai dati di tutti gli utenti" è tutta in questa fase. La quinta è l'**eventuale post-sfruttamento**: capire fin dove un attaccante potrebbe spingersi una volta dentro, perché spesso il primo punto d'ingresso non è il danno, è la porta verso il danno. E l'ultima è il **report**, che traduce tutto in qualcosa di azionabile. Ogni fase ha senso solo se prepara la successiva, e saltarle, come fa uno scanner che va dritto all'analisi, è ciò che fa perdere le vulnerabilità che contano. ## Quali vulnerabilità si trovano più spesso? Si trovano soprattutto i problemi di autorizzazione, i difetti di logica applicativa e le injection meno ovvie, cioè proprio le classi che gli scanner faticano a vedere. La più comune e la più sottovalutata è il **controllo degli accessi rotto**: l'applicazione mostra all'utente solo ciò che dovrebbe vedere, ma il server non verifica davvero che la richiesta sia autorizzata, così cambiando un identificativo nell'URL o nella richiesta si accede ai dati di un altro utente. È una falla banale da sfruttare e devastante negli effetti, e si trova con impressionante frequenza perché nasce da un controllo mancante, non da un errore di codice visibile. Subito dopo vengono i **difetti di logica di business**: l'applicazione fa esattamente quello per cui è programmata, ma il flusso può essere abusato in modi che chi l'ha scritta non aveva previsto. Saltare un passaggio di pagamento, applicare uno sconto più volte, manipolare la quantità per ottenere un rimborso maggiore dell'acquisto. Nessuno scanner li trova, perché non sono bug tecnici, sono il sistema che funziona "correttamente" in uno scenario non previsto. Poi ci sono le **injection di seconda mano**, dove un dato malevolo viene salvato in un punto e sfruttato quando viene riutilizzato altrove, sfuggendo ai controlli che guardano solo l'ingresso immediato. E le catene: vulnerabilità come la falsificazione di richieste lato server o gli attacchi sulla logica di autenticazione che, concatenate, portano molto più lontano di quanto ciascuna farebbe da sola. Ho raccontato un esempio concreto di queste concatenazioni nell'articolo sugli [attacchi alla logica applicativa tra SSRF e OAuth](https://www.mauriziofonte.it/blog/post/ssrf-oauth-exploitation-attacchi-logica-applicativa-waf.html). Se vuoi capire come applico questa prospettiva offensiva alla difesa di un'applicazione reale, nel [mio profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su penetration testing e hardening per le PMI. ## Cosa si concorda prima di iniziare? Si concorda il perimetro, le regole d'ingaggio e l'autorizzazione formale, perché un penetration test è un'attività che senza queste premesse sarebbe indistinguibile da un attacco vero. Prima di toccare qualunque sistema, si definisce il **perimetro**: quali applicazioni, quali ambienti, quali funzionalità sono nello scope, e cosa è esplicitamente fuori. Questo non è burocrazia, è ciò che evita che il test danneggi sistemi non previsti o tocchi dati che non doveva toccare. Un test senza un perimetro chiaro è un rischio per l'azienda stessa. Poi si stabiliscono le **regole d'ingaggio**: in quali orari si può testare, per non impattare la produzione nei momenti critici, quali tecniche sono ammesse e quali no, cosa fare se si scopre una compromissione preesistente, come comunicare se qualcosa va storto durante il test. Si decide anche il livello di conoscenza iniziale: un test "a scatola nera" parte senza informazioni, simulando un attaccante esterno; uno "a scatola bianca" parte con accesso al codice e alla documentazione, ed è più efficiente perché non spreca tempo a scoprire ciò che l'azienda potrebbe semplicemente dire. La scelta dipende da cosa si vuole simulare e dal budget. Soprattutto, si firma l'**autorizzazione formale**: il documento che rende l'attività lecita, perché senza il consenso scritto del proprietario del sistema, testare la sicurezza di un'applicazione è un reato, non un servizio. È la differenza giuridica fondamentale tra chi attacca per difendere e chi attacca e basta. C'è anche la questione del **quando** ha senso fare un penetration test, perché non è un'attività da una volta sola. I momenti giusti sono precisi: prima del lancio di una nuova applicazione che tratta dati sensibili, dopo un cambiamento architetturale importante che può aver introdotto nuove superfici, periodicamente per le applicazioni critiche perché il codice cambia e con esso il rischio, e quando un requisito normativo o un cliente lo richiede esplicitamente. Un test fatto una volta e mai più dà una falsa sicurezza, perché fotografa il rischio in un istante mentre l'applicazione continua a evolvere. ## Come si distingue un finding reale da un falso positivo? Lo si distingue dimostrandolo: un finding reale è uno che si riesce a sfruttare e che ha un impatto concreto, un falso positivo è un allarme che non si traduce in nulla. È qui che il valore umano del penetration test diventa evidente. Uno scanner segnala una potenziale vulnerabilità ogni volta che un pattern corrisponde, e la maggior parte di quelle segnalazioni, una volta verificate, si rivelano non sfruttabili: protette da un altro controllo, irraggiungibili nel contesto reale, o semplicemente falsi riconoscimenti. Consegnare a un'azienda l'output grezzo di uno scanner, pieno di centinaia di "vulnerabilità" la cui maggioranza è rumore, è un disservizio, perché seppellisce i pochi problemi veri sotto una montagna di falsi allarmi e fa perdere fiducia nell'intero esercizio. Il tester verifica ogni finding rilevante provando a sfruttarlo, e tiene solo quelli che si dimostrano reali e ne misura l'impatto effettivo. Questo lavoro di **separazione del segnale dal rumore** è una delle cose che giustificano il costo di un penetration test fatto da una persona competente rispetto a uno scan automatico: il primo ti consegna una lista corta di problemi veri e dimostrati, il secondo una lista lunga che devi ancora verificare tu, senza averne gli strumenti. La fiducia in un report di sicurezza nasce proprio da qui: ogni voce è qualcosa che è stato dimostrato, non ipotizzato, e questo cambia completamente come l'azienda può agire di conseguenza. ## Come diventa remediation prioritizzata? Diventa un report che ordina i problemi per rischio reale e dice, per ciascuno, cosa fare, così l'azienda sa da dove partire invece di annegare in un elenco indistinto. Un buon report di penetration test non è una lista di vulnerabilità, è uno strumento decisionale. Ogni finding viene **prioritizzato in base al rischio**, che è la combinazione di quanto è grave l'impatto se sfruttato e quanto è facile sfruttarlo: una falla che espone tutti i dati dei clienti ed è banale da innescare sta in cima; una debolezza minore e difficile da sfruttare sta in fondo. Questa prioritizzazione è ciò che permette a un'azienda con risorse limitate, e tutte lo sono, di affrontare prima ciò che conta. Per ogni problema, il report dice anche **cosa fare per risolverlo**, in termini concreti e comprensibili, non solo "presente vulnerabilità X". E traduce l'impatto tecnico in impatto di business, perché il titolare o il responsabile che deve decidere dove investire il budget di sicurezza non ragiona in termini di vulnerabilità ma in termini di conseguenze: cosa rischio se non sistemo questa cosa, e quanto mi costa sistemarla. Questa traduzione, dal tecnico al decisionale, è ciò che trasforma un penetration test da esercizio fine a sé stesso in una guida per migliorare davvero la sicurezza. Un buon report contiene anche un elemento che molti trascurano: il **percorso di sfruttamento documentato**, cioè la spiegazione passo per passo di come si è arrivati a compromettere il sistema. Questo non serve solo a dimostrare il finding, serve a far capire al team di sviluppo il ragionamento dell'attaccante, così che impari a riconoscere quel tipo di errore in futuro e non si limiti a tappare il singolo buco. Un report che insegna vale più di uno che elenca, perché trasferisce competenza invece che solo informazione. E include una fase spesso saltata, la **verifica della remediation**: dopo che l'azienda ha applicato le correzioni, si ricontrolla che i problemi siano davvero risolti e che le correzioni non ne abbiano introdotti di nuovi, perché una correzione affrettata può aprire una falla diversa da quella che chiudeva. Senza questa chiusura del cerchio, non si sa se il lavoro ha davvero migliorato la sicurezza o solo spostato il problema. Il filo che lega tutto è che un penetration test fatto bene è un investimento nella conoscenza del proprio rischio reale, non un bollino da appendere. Non serve a dire "siamo sicuri", serve a sapere esattamente dove non lo sei, prima che lo scopra qualcuno con intenzioni peggiori, e a sapere in che ordine intervenire. La prospettiva offensiva, quella di chi pensa come un attaccante, applicata alla difesa, è ciò che porta alla luce i problemi che restano invisibili a chi guarda il sistema solo dal lato di chi lo ha costruito. Non puoi difendere bene ciò che non hai mai provato ad attaccare, ed è esattamente per questo che il penetration test esiste. Se vuoi sapere dove la tua applicazione è davvero vulnerabile, con una lista corta di problemi dimostrati e prioritizzati invece di un report automatico da decifrare, [contattami per una consulenza diretta](https://www.mauriziofonte.it/pages/contattami): partiamo da cosa protegge davvero valore nella tua applicazione, e proviamo a romperlo prima che lo faccia qualcun altro. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Mercoledì 12 Agosto 2026, alle 08:01 [« Articolo precedente2FA e NIS2 con Zitadel su un sistema di posta legacy11 Agosto 2026](https://www.mauriziofonte.it/blog/post/zitadel-2fa-nis2-posta-legacy-postmaster.html)[Articolo successivo »Sincronizzare le identità Zitadel tra più ambienti senza trascinare il database12 Agosto 2026](https://www.mauriziofonte.it/blog/post/zitadel-sincronizzazione-identita-cross-ambiente.html) ### Articoli correlati a Penetration testing di un'applicazione web: come funziona davvero in un'azienda - [Penetration testing di un'applicazione Laravel: metodologia e vulnerabilità tipiche](https://www.mauriziofonte.it/blog/post/penetration-testing-applicazione-laravel-metodologia-vulnerabilita.html) In un recente assessment su un gestionale Laravel per una PMI manifatturiera, ho trovato mass assignment non protetto, IDOR su quattro endpoint · 8 Ottobre 2025 ![Penetration testing di un'applicazione Laravel: metodologia e vulnerabilità tipiche](https://www.mauriziofonte.it/image/002650070-penetration-testing-applicazione-laravel-metodologia-vulnerabilita.jpg) - [SSRF e OAuth exploitation: attacchi alla logica applicativa che il WAF non vede](https://www.mauriziofonte.it/blog/post/ssrf-oauth-exploitation-attacchi-logica-applicativa-waf.html) Un WAF filtra pattern noti, ma gli attacchi alla logica applicativa gli passano sotto. Come funzionano davvero la Server Side Request Forgery · 17 Agosto 2026 ![SSRF e OAuth exploitation: attacchi alla logica applicativa che il WAF non vede](https://www.mauriziofonte.it/image/005090070-ssrf-oauth-exploitation-attacchi-logica-applicativa-waf.jpg) - [La pipeline CI/CD come vettore d'attacco: il punto debole di sicurezza che si ignora](https://www.mauriziofonte.it/blog/post/cicd-vettore-attacco-pipeline-deploy-punto-debole-sicurezza.html) La pipeline di deploy ha accesso a segreti, registry e produzione, eppure viene trattata con meno attenzione del codice applicativo. I vettori · 13 Agosto 2026 ![La pipeline CI/CD come vettore d'attacco: il punto debole di sicurezza che si ignora](https://www.mauriziofonte.it/image/005070070-cicd-vettore-attacco-pipeline-deploy-punto-debole-sicurezza.jpg) - [Container escape e sicurezza Docker: la vulnerabilità che molti team ignorano](https://www.mauriziofonte.it/blog/post/container-escape-sicurezza-docker-vulnerabilita-team-ignora.html) Molti team trattano il container come una sandbox di sicurezza, ma per default non lo è. I vettori di escape su Docker: privileged mode, socket · 14 Agosto 2026 ![Container escape e sicurezza Docker: la vulnerabilità che molti team ignorano](https://www.mauriziofonte.it/image/005080070-container-escape-sicurezza-docker-vulnerabilita-team-ignora.jpg) - [Red team su infrastruttura cloud PMI: tecniche di ricognizione e lateral movement](https://www.mauriziofonte.it/blog/post/red-team-infrastruttura-cloud-pmi-ricognizione-lateral-movement.html) 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 · 15 Ottobre 2025 ![Red team su infrastruttura cloud PMI: tecniche di ricognizione e lateral movement](https://www.mauriziofonte.it/image/002810070-red-team-infrastruttura-cloud-pmi-ricognizione-lateral-movement.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Penetration testing di un'applicazione web: come funziona davvero in un'azienda", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/penetration-testing-applicazioni-web-come-funziona-azienda.html Pubblicato: 2026-08-12 · Aggiornato: 2026-08-12. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.