Come fare un test di sicurezza su un'applicazione web: guida
Come fare un test di sicurezza su un'applicazione web? Si definisce prima il perimetro e si ottiene l'autorizzazione scritta. Poi si mappa l'applicazione, si cercano le vulnerabilità con strumenti automatici e verifiche manuali, si dimostra l'impatto reale e si documenta tutto in un report con priorità di correzione. Alla fine si ripete il controllo per confermare che le falle siano chiuse.
In questa guida vediamo ogni fase, le vulnerabilità da verificare e i casi in cui conviene affidarsi a uno specialista, soprattutto se la tua azienda a Milano gestisce dati di clienti, pagamenti o accessi riservati.
Prima di iniziare: autorizzazione, obiettivi e perimetro
Un test di sicurezza efficace parte da decisioni organizzative, non da strumenti. Senza un perimetro chiaro rischi di perdere tempo o, peggio, di causare disservizi in produzione.
Un'attività di questo tipo simula il comportamento di un attaccante, quindi richiede sempre un'autorizzazione scritta del titolare del sistema. Testare un'applicazione senza permesso può avere conseguenze legali, tra cui l'ipotesi di accesso abusivo a un sistema informatico.
Prima di procedere, chiarisci questi punti:
- Cosa si testa: domini, sottodomini, API, pannelli di amministrazione, app mobile collegate.
- Con quali accessi: nessun accesso (visione esterna), utente standard, amministratore.
- In quale ambiente: staging, se è fedele alla produzione, oppure produzione con cautele concordate.
- Quando: finestre temporali e referenti da avvisare in caso di problemi.
- Quali dati sono sensibili: per gestirli in modo conforme alle regole interne e al GDPR.
Come fare un test di sicurezza su un'applicazione web: le fasi
Il metodo più diffuso si ispira a riferimenti pubblici come la guida OWASP Web Security Testing Guide e la lista OWASP Top 10. Eccone una sintesi operativa.
- Raccolta informazioni. Si identificano tecnologie, framework, endpoint, parametri e ruoli utente. Più superficie scopri, più completo sarà il test.
- Mappatura delle funzionalità. Login, registrazione, recupero password, carrello, upload di file, area riservata: ogni flusso è un potenziale punto d'ingresso.
- Scansione automatica. Scanner come OWASP ZAP o Burp Suite individuano rapidamente problemi noti, ma producono falsi positivi e non capiscono la logica di business.
- Verifica manuale. È la parte a maggior valore: un tecnico prova a manipolare richieste, sessioni e permessi per far emergere falle che gli scanner non vedono.
- Sfruttamento controllato. Si dimostra l'impatto reale di una vulnerabilità, senza danneggiare dati o servizi.
- Report e priorità. Ogni problema viene descritto con prova, rischio e indicazioni di correzione.
- Retest. Dopo le correzioni si verifica che le falle siano davvero chiuse.
Uno scanner da solo non basta. Vale come primo controllo, non come test di sicurezza completo.
Le vulnerabilità da verificare in un'applicazione web
Non tutte le falle hanno lo stesso peso. Queste categorie compaiono spesso nei test e meritano attenzione specifica.
SQL injection: cos'è e come difendersi
La SQL injection avviene quando l'input dell'utente viene inserito in una query al database senza controlli adeguati. Un attaccante può leggere, modificare o cancellare dati che non dovrebbe vedere.
Nel test si provano input anomali su form, parametri URL, header e API. La difesa principale sono le query parametrizzate, la validazione dell'input e l'uso di account di database con privilegi minimi.
Cross-site scripting (XSS): esempi e prevenzione
Nel cross-site scripting un attaccante riesce a far eseguire script nel browser di un altro utente, per esempio tramite un commento, un campo di ricerca o un profilo che mostra contenuti non filtrati. Le conseguenze possono includere furto di sessione o manipolazione della pagina.
Per prevenirlo servono l'output encoding contestuale, la sanificazione dei contenuti, cookie con attributi di sicurezza e una Content Security Policy ben configurata.
Privilege escalation e controllo degli accessi
La privilege escalation si verifica quando un utente ottiene permessi superiori a quelli previsti, ad esempio accedendo a funzioni di amministrazione o ai dati di altri clienti modificando un identificativo nella richiesta. È una delle aree in cui il test manuale è insostituibile.
Per prevenirla, applica il principio del minimo privilegio e verifica i permessi lato server a ogni richiesta, non solo nell'interfaccia. Testa sempre con più ruoli utente.
Altri controlli importanti
- Autenticazione e gestione delle sessioni (password deboli, assenza di MFA, token prevedibili).
- Configurazioni errate, messaggi di errore troppo dettagliati, componenti non aggiornati.
- Upload di file non controllati e falle nella logica di business, come sconti o pagamenti manipolabili.
- Sicurezza delle API, spesso meno protette dell'interfaccia web.
Vulnerabilità, exploit e zero day: perché contano nel test
Una vulnerabilità è una debolezza nel codice, nella configurazione o nel processo. Un exploit è la tecnica, o lo strumento, che la sfrutta per ottenere un effetto concreto, come leggere dati o eseguire comandi. Una falla non sfruttata resta un rischio potenziale; con un exploit funzionante diventa un incidente possibile.
Una vulnerabilità zero day è una falla ancora sconosciuta al produttore, quindi priva di patch ufficiale. Nessun test può trovare tutto, ma una buona gestione di aggiornamenti, monitoraggio e riduzione della superficie d'attacco limita l'esposizione.
Anche i ransomware sfruttano spesso applicazioni esposte e non aggiornate come punto d'ingresso, per poi muoversi nella rete. Per questo un'applicazione web trascurata può diventare un problema per l'intera azienda, non solo per il sito. Per approfondire come questi temi si collegano alla protezione complessiva, puoi consultare l'approccio di Fred for Security alla sicurezza informatica.
Test interno o specialista esterno: come scegliere
Se la tua intenzione è valutare un servizio professionale, il punto è capire cosa ti serve davvero. Un team interno può eseguire controlli ricorrenti; un tecnico esterno porta indipendenza e un occhio non condizionato dal codice.
| Aspetto | Controlli interni | Specialista esterno |
|---|---|---|
| Obiettivo | Verifiche frequenti durante lo sviluppo | Valutazione indipendente e approfondita |
| Punto di vista | Conosce bene il codice | Ragiona come un attaccante reale |
| Rischio | Zone cieche e abitudini consolidate | Richiede un buon perimetro e briefing |
| Output | Segnalazioni tecniche | Report con prove, rischio e priorità |
Quando scegli un fornitore, chiedi quale metodologia usa, come tutela i dati durante il test, che cosa include il report e se è previsto un retest. Diffida di chi promette di «trovare tutto» o di garantire sicurezza assoluta. Se vuoi un confronto con un team specializzato, scopri i servizi di Fred for Security.
Dopo il test: report, correzioni e miglioramento continuo
Il valore di un test sta in ciò che fai dopo. Un buon report indica per ogni problema la descrizione, i passaggi per riprodurlo, l'impatto e la correzione consigliata.
Assegna le attività in base al rischio: prima le falle che espongono dati o permettono accessi non autorizzati, poi quelle meno critiche. Coinvolgi sviluppatori e responsabili del business, perché alcune correzioni richiedono modifiche ai processi e non solo al codice.
Poi integra la sicurezza nel ciclo di sviluppo: revisione del codice, aggiornamento delle dipendenze, test dopo ogni rilascio importante e retest. Le verifiche una tantum fotografano un momento; la sicurezza richiede continuità.
Conclusione
Fare un test di sicurezza su un'applicazione web significa procedere con metodo: autorizzazione, perimetro, analisi automatica e manuale, report e verifica delle correzioni. Più l'applicazione tratta dati sensibili o pagamenti, più conta la profondità del test e l'indipendenza di chi lo esegue.
Se vuoi capire da dove partire per la tua applicazione, puoi contattare Fred for Security e valutare insieme perimetro e obiettivi di una verifica adatta alla tua realtà.
Domande frequenti
Quanto costa un test di sicurezza su un'applicazione web?
Il costo dipende da fattori come numero di funzionalità, ruoli utente, API esposte, integrazioni e profondità richiesta. Non esiste un prezzo standard affidabile: per avere un preventivo corretto serve definire il perimetro e chiedere a più fornitori una proposta con metodologia, deliverable e tempi chiari.
Ogni quanto va ripetuto un test di sicurezza?
Conviene ripeterlo dopo modifiche rilevanti all'applicazione, come nuove funzioni, cambi di architettura o integrazioni, e comunque con una cadenza periodica definita dal livello di rischio. Un'app che gestisce pagamenti o dati personali merita verifiche più frequenti di un sito vetrina.
Qual è la differenza tra vulnerability assessment e penetration test?
Il vulnerability assessment individua e classifica le debolezze, di solito con scanner e verifiche mirate. Il penetration test va oltre: un tecnico prova a sfruttarle in modo controllato per dimostrare l'impatto reale, concatenando più falle e valutando fino a dove potrebbe spingersi un attaccante.
Posso testare un'applicazione web senza autorizzazione?
No. Testare sistemi senza permesso scritto del titolare può configurare reati informatici, come l'accesso abusivo a sistema informatico. Anche su app di terze parti o su servizi in hosting serve un'autorizzazione formale, che valga anche per il fornitore dell'infrastruttura, se previsto dai suoi termini.