FCHEADERJSPLACEHOLDER

Sicurezza e-commerce dopo la fine di Magento 1: cosa faccio davvero

Fabio Canovi imprenditore digitale nel settore e-Commerce in Italia.
Fabio Canovi
Consulente Adobe · AI Specialist

Sono passati tre mesi dalla fine del supporto ufficiale a Magento 1, arrivata lo scorso 30 giugno. Nella pratica significa una cosa sola: da quel giorno non escono più patch di sicurezza. Nessuna. E il pezzo di codice che gestisce il carrello, il checkout e i dati di pagamento dei tuoi clienti è, da tre mesi, un bersaglio fermo.

Lavoro su Magento dal 2011 e ho visto nascere e morire parecchie versioni. Ma questa fine, con i numeri di installato che ancora girano su M1, mi preoccupa più delle altre. Voglio raccontare cosa faccio davvero, sul campo, per i negozi che sono ancora lì, e perché tutto quello che faccio resta comunque una toppa.

Perché stare su Magento 1 oggi è un rischio concreto

Il problema non è teorico. Un e-commerce senza patch è come una casa con le serrature che non si aggiornano mentre in giro cambiano i grimaldelli. La minaccia più insidiosa in questo momento si chiama Magecart: una famiglia di attacchi di web skimming in cui l’attaccante inietta qualche riga di JavaScript nelle pagine di checkout e copia in tempo reale i dati della carta mentre il cliente li digita. Il negozio continua a funzionare, gli ordini arrivano, tutto sembra normale. Intanto i numeri di carta escono dalla porta sul retro.

La cosa che dico sempre ai merchant è questa: su Magento 1 non è questione di “se”, ma di “quando” e di “per quanto tempo non te ne accorgi”. Ho visto skimmer restare attivi per settimane prima di essere individuati, perché non lasciano segni visibili sul frontend. E oltre al danno diretto ai clienti c’è il tema PCI DSS: girare software fuori supporto rende molto difficile restare compliant, e in caso di data breach la posizione del merchant davanti a banche e circuiti è debolissima.

Cosa faccio davvero per proteggere un negozio ancora su M1

Quando un cliente non può migrare dall’oggi al domani — e capita, per budget, stagionalità o customizzazioni pesanti — non lo lascio scoperto. Metto in campo una serie di mitigazioni. Sono onesto fin dall’inizio: servono a ridurre la superficie e il tempo di esposizione, non ad azzerare il rischio.

1. WAF davanti a tutto. La prima cosa è mettere un Web Application Firewall tra Internet e il negozio, tipicamente a livello di CDN. Filtra i pattern di attacco noti, blocca buona parte dei tentativi di injection e mi dà un punto unico dove applicare regole quando esce una nuova vulnerabilità pubblica. È la mossa con il miglior rapporto tra sforzo e protezione ottenuta.

2. Hardening dell’admin. Il pannello di amministrazione è la porta principale. Sposto la URL di login da quella di default, la chiudo dietro un vincolo di IP o una VPN quando il cliente ha uno staff piccolo e stabile, forzo password lunghe e uniche, e aggiungo autenticazione a due fattori sopra l’admin. Magento 1 non ha un 2FA nativo decente, quindi lo aggiungo con un layer esterno o a livello di server.

3. Backup delle patch di community. Il supporto ufficiale è finito, ma la conoscenza delle vulnerabilità continua a circolare. Applico manualmente le correzioni che diventano di dominio pubblico e tengo sotto controllo la mia lista di punti sensibili nel codice custom. È lavoro artigianale, va fatto con testa, ma tappa buchi reali.

4. Monitoraggio dell’integrità dei file. Questa per me è la mitigazione più importante contro Magecart. Metto in piedi un controllo che confronta i file del negozio con una baseline nota e mi avvisa quando qualcosa cambia dove non dovrebbe. Tengo d’occhio in particolare i template di checkout e qualsiasi JavaScript servito nelle pagine di pagamento. Se compare una riga che non ho messo io, voglio saperlo in minuti, non in settimane.

5. Igiene di base che nessuno guarda mai. Rimuovo utenti admin dimenticati, revoco chiavi API inutilizzate, disattivo estensioni che non servono più (ogni estensione è codice di terzi, quindi superficie d’attacco), e verifico i permessi dei file sul server. Sono cose noiose e proprio per questo trascurate. Sono anche quelle da cui passa la metà degli incidenti che ho visto.

Perché resta comunque una toppa

Voglio essere chiaro, perché qui vedo troppa gente vendere illusioni. Tutto quello che ho elencato non trasforma Magento 1 in una piattaforma sicura. Riduce la probabilità di essere colpiti e il tempo in cui un attacco resta invisibile. Nient’altro.

Un WAF filtra ciò che conosce, non la vulnerabilità zero-day che uscirà il mese prossimo su una piattaforma che nessuno correggerà più. Il monitoraggio ti dice che sei stato compromesso, cioè arriva dopo. Le patch di community coprono ciò che è già noto e pubblico, sempre con ritardo. Stai costruendo un perimetro di sabbia attorno a una struttura che, per definizione, non riceverà più rinforzi.

La vera risposta è una sola, e non è tecnica ma di decisione: migrare. Su Magento 2 / Adobe Commerce, o su un’altra piattaforma che riceve aggiornamenti di sicurezza. So che la migrazione fa paura per costi e tempi, e ne parlo con i merchant senza indorare la pillola. Ma il calcolo va fatto onesto: il costo della migrazione è noto e pianificabile, il costo di un data breach su una piattaforma fuori supporto no. Nella mia esperienza chi rimanda continua a rimandare finché non succede qualcosa, e allora il conto è molto più salato.

E chi è già su Magento 2? Non sei automaticamente al sicuro

Attenzione a non leggere questo pezzo come “M1 male, M2 e sono tranquillo”. La sicurezza non è uno stato che raggiungi, è una manutenzione che fai. Anche sui negozi che seguo su Magento 2 e Adobe Commerce insisto su tre cose:

  • 2FA sull’admin, sempre. Su Magento 2 l’autenticazione a due fattori è integrata. Va tenuta attiva per tutti, senza eccezioni “solo per me che faccio in fretta”. È esattamente l’eccezione da cui entrano.
  • Patch di sicurezza applicate in fretta. Adobe rilascia bollettini di sicurezza con una certa regolarità. La finestra tra la pubblicazione della patch e lo sfruttamento della falla si è accorciata molto: applicare in giornata o in pochi giorni fa la differenza. Un negozio aggiornato con mesi di ritardo è vulnerabile quanto uno su M1, solo con più scuse.
  • Igiene continua. Le stesse cose noiose di prima: utenti, chiavi API, estensioni di terze parti, permessi. Ogni estensione che installi è codice che non hai scritto tu e che eredita i tuoi privilegi. Vale la pena chiedersi, ogni volta, se serve davvero.

In sintesi

Su Magento 1, oggi, si lavora in difesa: WAF, hardening dell’admin, monitoraggio dell’integrità dei file, patch di community e igiene. Tutto utile, tutto necessario, e tutto insufficiente come stato definitivo. È un ponte, non una destinazione. La destinazione è una piattaforma che riceve ancora aggiornamenti. E se sei già su Magento 2, la sicurezza non è un traguardo tagliato: è 2FA acceso, patch tempestive e disciplina, tutti i giorni.

Mini-FAQ

Magento 1 è ancora utilizzabile dopo la fine del supporto?
Tecnicamente sì, il software continua a funzionare. Ma dal 30 giugno 2020 non riceve più patch di sicurezza ufficiali, quindi ogni nuova vulnerabilità resta aperta. È utilizzabile, non è difendibile a lungo termine.

Un WAF basta a proteggere un e-commerce su Magento 1?
No. Un WAF riduce gli attacchi noti e dà un punto centrale per applicare regole, ma non copre le vulnerabilità nuove né sostituisce le patch. È una mitigazione importante, non una soluzione.

Cos’è Magecart e perché è pericoloso su M1?
Magecart indica attacchi di web skimming che iniettano JavaScript nel checkout per rubare i dati delle carte in tempo reale, senza segni visibili. Su una piattaforma senza patch è particolarmente pericoloso perché le falle di ingresso non vengono più chiuse.

Migrare a Magento 2 mette al sicuro in automatico?
No. Magento 2 riceve aggiornamenti, ma la sicurezza dipende da come lo gestisci: 2FA attivo sull’admin, patch applicate in fretta e igiene continua su utenti, chiavi API ed estensioni.

Qual è la vera soluzione per chi è ancora su Magento 1?
Migrare verso una piattaforma che riceve ancora aggiornamenti di sicurezza. Le mitigazioni servono a comprare tempo in sicurezza durante la transizione, non a evitarla.


Chi sono. Sono Fabio Canovi, mi occupo di e-commerce enterprise su Magento e Adobe Commerce da oltre dieci anni, dai tempi di Magento 1. Sono tra i primi in Italia ad aver ottenuto la certificazione Adobe Commerce. Progetto, gestisco e metto in sicurezza store per merchant mid-market, e scrivo di quello che vedo davvero sul campo.

Fabio Canovi imprenditore digitale nel settore e-Commerce in Italia.
Chi sono
Sono Fabio Canovi, consulente Adobe presso il gruppo Lutech. Tra i primi in Italia certificato Adobe Commerce e certificato AEM, Analytics e Target (Master su Target). Negli ultimi due anni ho unito le competenze Adobe con l’AI agentica, lavorando con Claude Code e Cowork e costruendo MCP su misura per portare gli agenti dentro le piattaforme e-commerce reali.

Articoli correlati