Un penetration test per eCommerce non dovrebbe finire con un PDF pieno di sigle incomprensibili. Dovrebbe aiutarti a capire cosa rischi, cosa sistemare prima e come verificare che il problema sia davvero risolto.
Molti report di sicurezza sembrano tecnici ma non sono operativi: elenco di vulnerabilita generiche, screenshot senza contesto, severita assegnate a caso, nessuna priorita business, nessuna evidenza riproducibile e nessun piano di remediation.
Per un eCommerce questo non basta. Un negozio online ha checkout, account clienti, ordini, pagamenti, coupon, spedizioni, API, feed, CRM, gestionali, marketplace, form e dati personali. Un report serio deve parlare questa lingua.
Prima del report: lo scope deve essere chiaro
Il primo segnale di serieta e lo scope. Prima di testare, bisogna sapere cosa rientra e cosa no.
- Dominio principale e sottodomini.
- Ambiente testato: produzione, staging o copia dedicata.
- Area pubblica, area clienti, checkout, backoffice, API.
- Account di test disponibili.
- Ruoli utente: cliente, agente, admin, staff, B2B.
- Gateway pagamento e metodi fittizi o reali.
- Integrazioni con gestionale, CRM, corrieri, feed e marketplace.
- Limiti operativi: orari, rate limit, test distruttivi esclusi.
- Contatti di emergenza.
Senza scope, un penetration test rischia di essere troppo superficiale o troppo pericoloso. Su un eCommerce reale bisogna testare bene, ma senza rompere vendite, ordini o dati.
Executive summary: serve anche a chi decide budget
Un buon report deve avere una sintesi comprensibile anche a chi non e tecnico.
L'executive summary dovrebbe spiegare:
- livello di rischio generale;
- aree piu esposte;
- impatti possibili su vendite, dati e continuita;
- numero di vulnerabilita per severita;
- priorita immediate;
- tempi consigliati di remediation;
- rischi residui dopo gli interventi.
Se il report non aiuta a decidere cosa fare lunedi mattina, manca un pezzo fondamentale.
Findings: ogni vulnerabilita deve essere riproducibile
Ogni finding deve contenere dati chiari, non solo un titolo.
- Titolo: nome comprensibile della vulnerabilita.
- Severita: critica, alta, media, bassa o informativa.
- Asset coinvolto: URL, endpoint, funzione, ruolo o modulo.
- Descrizione: cosa succede e perche e un problema.
- Impatto: cosa puo ottenere un attaccante.
- Passi di riproduzione: come verificare il problema.
- Evidenze: screenshot, request/response, log o payload sanificati.
- Raccomandazione: come risolvere in modo concreto.
- Riferimenti: OWASP, CWE, CVE o documentazione tecnica.
- Stato remediation: aperto, mitigato, risolto, da ritestare.
Un finding che non si puo riprodurre e difficile da correggere. Uno sviluppatore deve poter aprire il report e capire dove intervenire.
Le aree critiche di un eCommerce
Un test eCommerce deve andare oltre le scansioni automatiche.
Le aree da includere sono:
- Account clienti: registrazione, login, reset password, cambio email, indirizzi.
- Checkout: carrello, coupon, spedizione, pagamenti, conferma ordine.
- Ordini: visibilita, modifica, IDOR, accesso a ordini altrui.
- API: autenticazione, autorizzazione, rate limit, dati esposti.
- Backoffice: ruoli, permessi, upload, esportazioni e azioni admin.
- Catalogo: ricerca, filtri, parametri, upload immagini, import/export.
- Form: contatti, newsletter, recensioni, ticket e allegati.
- Integrazioni: gestionale, CRM, corrieri, marketplace, feed.
- Sessioni: cookie, logout, durata, protezione account.
- Dati personali: esposizione, download, log e permessi.
La differenza tra un test generico e un test eCommerce sta proprio qui: capire i flussi di vendita e i dati reali che passano nel sistema.
OWASP, API e logica business
OWASP e una base importante, ma non basta spuntare una lista.
Un eCommerce puo avere vulnerabilita tecniche classiche:
- SQL injection;
- XSS;
- CSRF;
- IDOR;
- file upload insicuro;
- sessioni deboli;
- configurazioni errate;
- API esposte male.
Ma puo avere anche bug di logica business:
- coupon cumulabili oltre il previsto;
- prezzi manipolabili lato client;
- spese di spedizione aggirabili;
- ordine visibile cambiando un ID;
- reso o rimborso attivabile senza autorizzazione;
- stock o carrello alterabili con richieste modificate;
- ruoli B2B o listini agenti non isolati correttamente.
Questi problemi spesso non emergono da una scansione automatica. Serve capire il funzionamento del negozio.
Severita: non basta dire "critico"
La severita deve essere motivata. Una vulnerabilita critica su un endpoint non raggiungibile e diversa da una vulnerabilita media sfruttabile da qualunque cliente loggato.
Un report serio valuta:
- facilita di sfruttamento;
- privilegi richiesti;
- impatto su dati personali;
- impatto su ordini e pagamenti;
- possibilita di automazione;
- esposizione pubblica;
- presenza di mitigazioni;
- probabilita reale nel contesto specifico.
La priorita deve aiutare a decidere: cosa si sistema oggi, cosa entro 7 giorni, cosa nel prossimo ciclo di sviluppo.
Remediation: il report deve dire come risolvere
Dire "sanitizzare input" o "migliorare sicurezza" non basta.
La remediation deve essere concreta:
- file, funzione o endpoint interessato;
- controllo mancante;
- pattern consigliato;
- test da aggiungere;
- configurazione da modificare;
- misura temporanea se la fix richiede tempo;
- impatto previsto su UX o performance;
- criterio per considerare il finding chiuso.
Il report deve essere usabile dal team tecnico, non solo archiviabile in una cartella.
Retest: senza verifica finale manca meta lavoro
Dopo le correzioni serve un retest. Non e una formalita.
Il retest verifica se:
- la vulnerabilita e stata davvero risolta;
- la fix non ha creato regressioni;
- le mitigazioni sono efficaci;
- i finding possono essere chiusi;
- rimangono rischi residui da accettare o pianificare.
Un report senza retest lascia il cliente nel dubbio: "abbiamo corretto o abbiamo solo cambiato qualcosa?"
Cosa deve consegnare un fornitore serio
- Scope e metodologia.
- Executive summary.
- Elenco asset testati.
- Finding tecnici dettagliati.
- Risk matrix.
- Evidenze riproducibili.
- Priorita remediation.
- Indicazioni per sviluppatori.
- Elenco esclusioni e limiti del test.
- Retest report dopo le correzioni.
Se ricevi solo un PDF automatico con cento segnalazioni generiche, non hai un penetration test: hai una scansione.
Come lo gestiamo in BitHub
Nei test su eCommerce partiamo dai flussi reali: catalogo, ricerca, carrello, checkout, account, ordini, API, integrazioni e backoffice.
Il risultato deve essere utile a tre persone diverse:
- il titolare, che deve capire rischio e priorita;
- il team tecnico, che deve correggere senza ambiguita;
- chi gestisce il business, che deve sapere quali processi proteggere.
Questo si collega ai nostri servizi di penetration test eCommerce, vulnerability assessment e cyber security per siti web.
Fonti utili
Per la struttura del report e dei controlli abbiamo considerato OWASP Web Security Testing Guide, OWASP ASVS e OWASP API Security Project.
FAQ
Quanto dura un penetration test eCommerce?
Dipende da scope, complessita, API, ruoli e integrazioni. Un test serio richiede prima definizione scope, poi esecuzione, report, remediation e retest.
Una scansione automatica basta?
No. Le scansioni aiutano, ma non trovano molti bug di logica business, autorizzazioni errate, problemi checkout o vulnerabilita legate ai flussi reali.
Il test va fatto in produzione?
Non sempre. Si puo lavorare su staging se e fedele alla produzione. Alcuni controlli pero richiedono verifica controllata sull'ambiente reale.
Il report deve includere prove tecniche?
Si. Senza evidenze e passi di riproduzione, il team tecnico fatica a correggere e a verificare la soluzione.
Serve il retest?
Si. Il retest conferma che le vulnerabilita siano state risolte e che non siano nate regressioni.
Vuoi un report che serva davvero?
Possiamo definire lo scope del tuo eCommerce, testare le aree critiche e consegnare un report chiaro, prioritizzato e utilizzabile dal team tecnico.