Sicurezza e-commerce: come proteggere il sito e i dati dei clienti

Immagina questa scena.

Un cliente compra sul tuo shop online. Inserisce nome, indirizzo, numero di carta. Clicca su "Acquista". Si fida di te.

Nel frattempo, da qualche parte, qualcuno sta girando tra le righe del tuo database. Silenziosamente. Senza che tu te ne accorga.

Può sembrare fantascienza. Non lo è.

La sicurezza del tuo e-commerce non è un tema tecnico da delegare al tuo sviluppatore e dimenticare. È un tema di reputazione, di fiducia, di sopravvivenza.

Il problema più comune: si agisce solo dopo il danno

Nella nostra esperienza, la sicurezza viene affrontata in due momenti: quando si apre il sito (spesso in fretta, tra mille altre priorità) e quando succede qualcosa di brutto.

Nel mezzo, anni di "funziona, non tocchiamo niente."

Eppure bastano pochi accorgimenti — alcuni gratuiti, altri con costi contenuti — per abbassare drasticamente il rischio. Non serve diventare esperti di cybersecurity. Serve smettere di fare le cose che aprono le porte agli attacchi.

1. HTTPS e certificato SSL: non è opzionale, è il pavimento

Se il tuo sito non usa HTTPS stai trasmettendo i dati dei tuoi clienti in chiaro. Chiunque si trovi sulla stessa rete può intercettarli con un semplice attacco man-in-the-middle.

Il certificato SSL/TLS è oggi gratuito con Let's Encrypt — supportato da qualsiasi hosting moderno. Però attenzione: HTTPS va abilitato sull'intero sito, non solo sulla pagina di checkout. Un sito che passa da HTTP a HTTPS solo al momento del pagamento è ancora vulnerabile nelle fasi precedenti, e Google lo penalizza nelle ricerche.

Un dettaglio operativo spesso trascurato: il certificato va rinnovato ogni 90 giorni (Let's Encrypt) o ogni anno (certificati a pagamento). Configura il rinnovo automatico — con Certbot è una riga di comando — oppure metti un promemoria nel calendario. Un certificato scaduto fa scattare l'avviso "Connessione non sicura" su tutti i browser: perdi il cliente prima che veda il primo prodotto.

2. Autenticazione a due fattori: non tutta uguale

Questo è il punto dove la maggior parte degli articoli si ferma a "attiva il 2FA". Noi andiamo un passo più avanti.

SMS vs TOTP: non è la stessa cosa.

Il 2FA via SMS — quello che ti manda un codice sul telefono — è meglio di niente, ma è vulnerabile agli attacchi SIM swapping (dove il criminale convince l'operatore telefonico a trasferire il tuo numero su una SIM nuova). Lo stesso Kinsta ha eliminato il 2FA via SMS dai propri sistemi perché non abbastanza sicuro.

Il metodo corretto per un pannello admin è il TOTP (Time-based One-Time Password): un'app come Google Authenticator, Authy o 1Password genera un codice che cambia ogni 30 secondi, senza passare per la rete telefonica. Impossibile intercettarlo con un SIM swap.

Dove attivarlo — e in che ordine di priorità:

• Pannello admin del CMS (WordPress/WooCommerce: plugin WP 2FA o Wordfence; Shopify: nelle impostazioni account; Magento: modulo nativo da abilitare)
• Hosting e accesso server (cPanel, SSH)
• Provider email aziendale (l'email è spesso il punto di recupero di tutti gli altri account — se cade quella, cadono tutti)
• Gateway di pagamento (Stripe, PayPal hanno il 2FA nativo — abilitarlo è obbligatorio se hai più di un collaboratore con accesso)

Step-up authentication per i clienti.

Una pratica avanzata ma sempre più diffusa: invece di chiedere il 2FA a ogni login (che frena la conversione), si attiva solo nelle azioni ad alto rischio — aggiungere un nuovo metodo di pagamento, cambiare email o indirizzo, visualizzare lo storico ordini completo. È il compromesso giusto tra sicurezza e UX.

3. Aggiornamenti: il rischio nascosto nei plugin che "funzionano"

WordPress, WooCommerce, Shopify, Magento rilasciano aggiornamenti regolari. Spesso non aggiungono funzionalità — tappano falle scoperte nel frattempo, molte delle quali già sfruttate attivamente.

Un punto critico che viene quasi sempre ignorato: i plugin abbandonati. Un plugin che non riceve aggiornamenti da più di 12 mesi è una porta di accesso aperta. Non importa se "funziona ancora" — non riceve più patch di sicurezza. Va rimosso o sostituito.

La procedura corretta non è aggiornare direttamente in produzione: crea un ambiente di staging (una copia del sito), testa gli aggiornamenti lì, poi trasferisci in live. Hosting come WP Engine, Kinsta o Siteground lo includono nel piano. Evita di scoprire che un aggiornamento ha rotto il checkout con i clienti già sul sito.

Per WordPress, dal rilascio della versione 6.6 è possibile fare rollback automatico in caso di aggiornamento plugin fallito — un safety net utile se decidi di abilitare gli update automatici.

4. Accessi e permessi: il principio del minimo privilegio

Il problema non è solo la password debole. È la struttura degli accessi.

Il principio da seguire: ogni utente deve avere accesso solo a quello che serve per fare il suo lavoro, niente di più. Un content editor non ha bisogno dei permessi di amministratore. Un collaboratore esterno che lavora solo sui prodotti non deve poter modificare le impostazioni di pagamento.

Questo si chiama RBAC (Role-Based Access Control) ed è disponibile nativamente su tutte le piattaforme e-commerce principali.

Nella pratica:

• Nessun account admin condiviso tra più persone: ognuno ha il suo, così puoi tracciare chi ha fatto cosa
• Quando un collaboratore smette di lavorare con te, l'accesso va rimosso immediatamente — non "quando hai tempo"
• Cambia le credenziali predefinite dell'admin panel (su WordPress, l'URL /wp-admin è noto a tutti — spostarlo con un plugin riduce il volume di attacchi automatici brute-force)
• Limita i tentativi di login falliti: dopo 5 tentativi errati, blocco temporaneo. Wordfence, Fail2Ban o il firewall dell'hosting lo fanno in automatico

Un password manager risolve il problema "non riesco a gestire password diverse per ogni accesso" e costa meno di un caffè al mese. Noi in studio usiamo Zoho Vault — integrato nel pacchetto Zoho One insieme a CRM, mail e analytics — che ci permette di condividere le credenziali del team in modo sicuro, con permessi per ruolo e log di accesso completo. Se già lavori nell'ecosistema Zoho è la scelta più naturale; in alternativa Bitwarden (open source, gratuito) o 1Password per i team sono entrambi solidi.

5. Dati dei clienti: meno ne raccogli, meno puoi perdere

Con il GDPR la questione non è solo tecnica — è legale. Ma c'è un principio pratico che vale indipendentemente dalla normativa: ogni dato che raccogli è un dato che puoi perdere.

I dati di pagamento non dovresti mai gestirli tu direttamente. Gateway certificati PCI-DSS come Stripe, PayPal, Nexi o Satispay gestiscono l'intera transazione nei loro sistemi. La certificazione PCI-DSS è uno standard di sicurezza rigoroso che richiede audit indipendenti — usare un gateway certificato significa che quella responsabilità non è tua.

Un dettaglio tecnico: se usi Stripe o Braintree, scegli l'integrazione con Stripe.js / hosted fields invece di passare i dati carta attraverso i tuoi server. In questo modo il numero di carta non transita mai dal tuo dominio — e il tuo scope PCI si riduce drasticamente.

Per tutto il resto — email, indirizzi, storico ordini — cifra i dati sensibili nel database (non solo in transito). Se usi MySQL, crittografa le colonne con i dati personali. Se usi un servizio cloud, abilita la cifratura at-rest che tutti i provider principali (AWS, Google Cloud, Azure) offrono di default.

6. Backup: non basta farlo, bisogna saperlo ripristinare

Un ransomware cifra tutti i tuoi file. Un errore umano cancella il database degli ordini. Un aggiornamento mal riuscito manda offline il checkout alle 11 di mattina di sabato. Con backup recenti, si risolve. Senza, può essere la fine.

Le regole operative:

• Frequenza proporzionale all'attività: se hai 50 ordini al giorno, un backup settimanale non basta. Con WooCommerce o Shopify Plus, backup giornalieri automatici sono lo standard minimo
• Regola del 3-2-1: 3 copie dei dati, su 2 supporti diversi, di cui 1 offsite (fuori dal server principale). Se il server viene compromesso o va in fiamme, il backup sullo stesso server è perso insieme a tutto il resto
• Test di ripristino periodico: un backup non testato è un backup di cui non sai se funziona. Simula un ripristino su un ambiente di staging almeno ogni trimestre
• Snapshot del database separato dal backup dei file: in caso di corruzione del DB, poter ripristinare solo i dati senza ricaricare l'intero sito risparmia ore

7. Header HTTP di sicurezza: la protezione invisibile che quasi nessuno configura

Ogni risposta del tuo server include degli header HTTP — istruzioni che il browser riceve prima ancora di caricare la pagina. La maggior parte dei siti e-commerce li ignora completamente. È un errore, perché configurarli bene chiude una classe intera di attacchi senza toccare il codice del sito.

I quattro che contano davvero:

Come verificare la situazione attuale del tuo sito: securityheaders.com analizza gli header in tempo reale e restituisce un voto A–F con la lista esatta di cosa manca e come aggiungerlo. La configurazione si fa in poche righe nel file .htaccess (Apache) o nginx.conf — il tuo sviluppatore ci mette meno di un'ora. Il risultato è invisibile all'utente finale, ma chiude vulnerabilità che nessun plugin di sicurezza copre.

Sicurezza e fiducia: due facce della stessa medaglia

C'è un ultimo aspetto che vale la pena nominare, anche se non è strettamente tecnico.

I clienti non leggono le tue policy di sicurezza. Non verificano il tuo certificato SSL. Ma sentono se un sito ispira fiducia — nei dettagli visivi, nella chiarezza delle informazioni, nella facilità con cui trovano cosa succede ai loro dati.

Un sito sicuro che comunica di esserlo — badge di pagamento riconoscibili, informativa privacy chiara, politica di reso facilmente accessibile — converte di più. Non perché la sicurezza sia un'arma di marketing, ma perché la fiducia si costruisce con la coerenza tra quello che sei e quello che mostri.

In sintesi

Proteggere un e-commerce non richiede un reparto IT dedicato. Richiede metodo e continuità: 2FA TOTP su tutti gli accessi critici, HTTPS sull'intero sito, aggiornamenti su staging, permessi minimi per ruolo, gateway certificati PCI-DSS, backup con test di ripristino, header HTTP configurati.

Clusit — Associazione Italiana per la Sicurezza Informatica, Rapporto Clusit 2024 sulla sicurezza ICT in Italia — clusit.it

Let's Encrypt, autorità di certificazione gratuita e automatizzata — letsencrypt.org

Kinsta, "Two-Factor Authentication (2FA) and MyKinsta Improvements" — rimozione del 2FA via SMS — kinsta.com

Make WordPress Core, "Rollback Auto-Update" — funzione introdotta con WordPress 6.6 — make.wordpress.org

OWASP Secure Headers Project, riferimento su Content-Security-Policy, HSTS e header HTTP di sicurezza — owasp.org

SecurityHeaders.com, strumento di analisi degli header HTTP in tempo reale — securityheaders.com

PCI Security Standards Council, standard PCI-DSS per la gestione dei dati di pagamento — pcisecuritystandards.org

Huntress, "British Airways Data Breach" — analisi dell'attacco Magecart — huntress.com

Il certificato SSL è a pagamento?

No: con Let's Encrypt è gratuito ed è supportato da qualsiasi hosting moderno. Va però abilitato sull'intero sito, non solo sulla pagina di checkout, e rinnovato automaticamente (ogni 90 giorni con Let's Encrypt).

Meglio il 2FA via SMS o tramite app?

Tramite app (TOTP). Il 2FA via SMS è vulnerabile al SIM swapping; un'app come Google Authenticator, Authy o 1Password genera un codice che cambia ogni 30 secondi senza passare dalla rete telefonica.

Posso aggiornare plugin e tema direttamente in produzione?

Meglio di no. Crea un ambiente di staging, testa lì gli aggiornamenti e poi trasferiscili in live. Rimuovi i plugin abbandonati da più di 12 mesi, perché non ricevono più patch di sicurezza.

Devo gestire io i dati delle carte di credito?

No. Usa gateway certificati PCI-DSS come Stripe, PayPal, Nexi o Satispay e integrazioni come Stripe.js / hosted fields, così il numero di carta non transita mai dai tuoi server e il tuo scope PCI si riduce drasticamente.