ATTACCO ALL'ECOMMERCE!

Quando pensiamo ad un attacco informatico contro un e-commerce immaginiamo ancora troppo spesso qualcuno davanti a un computer che cerca una password, individua una falla e tenta di entrare nel pannello amministrativo, ma oggi questa rappresentazione è parecchio lontana dalla realtà perché un attacco moderno può iniziare molto prima che qualcuno tenti realmente di violare qualcosa e può partire da migliaia di richieste apparentemente innocue che osservano il sito, cercano di capire quale tecnologia utilizza, individuano le API disponibili, riconoscono componenti e comportamenti interessanti e soltanto dopo decidono dove conviene concentrare l'attacco.

La cosa più importante da capire è che tutto questo può avvenire mentre il negozio continua tranquillamente a funzionar e quindi gli ordini arrivano, i clienti navigano, il sito non mostra nessuna schermata inquietante e l'amministratore potrebbe non accorgersi assolutamente di nulla mentre, nel frattempo, qualcuno sta già costruendo una mappa tecnica dell'e-commerce. Ed è proprio da qui che bisogna partire per capire cosa significhino realmente termini come WAF, bot protection, rate limiting e sicurezza delle API.

UN E-COMMERCE NON SOLTANTO UN SITO

Prendiamo come riferimento due piattaforme molto diffuse nelle loro versioni gratuite: PrestaShop 9 e Magento Open Source 2.4.9. Sono software maturi e molto completi, ma proprio per questo un e-commerce costruito con queste piattaforme non è semplicemente un insieme di pagine web perché dietro il catalogo che vede il cliente esistono account, carrello, checkout, ordini, magazzino, pagamenti, pannello amministrativo, moduli aggiuntivi, collegamenti con gestionali, corrieri e sistemi esterni, oltre a una quantità crescente di API.

Il commerciante vede prodotti, clienti e ordini mentre chi studia il sistema da un punto di vista offensivo vede superfici differenti attraverso le quali l'applicazione accetta richieste e restituisce informazioni, ed è proprio questo cambiamento di prospettiva che permette di comprendere come vengono costruiti molti attacchi reali.

PRIMA TE LO STUDIANO, POI ATTACCANO

La prima fase è ricognitiva e non significa necessariamente che qualcuno stia già cercando di penetrare nel server, piuttosto che sta cercando di capire cosa si trova davanti: quale piattaforma viene utilizzata, quali servizi sono raggiungibili, quali API esistono, quali tecnologie rispondono e quali componenti sembrano installati, e molte di queste informazioni possono essere raccolte semplicemente osservando ciò che il sito restituisce pubblicamente e quindi, in questa fase, non serve ancora sfruttare una vulnerabilità perché è più simile a qualcuno che gira intorno a un edificio, osserva ingressi, finestre e sistemi di sorveglianza e soltanto dopo decide se esiste un punto interessante.

Farlo manualmente su migliaia di siti è lento, mentre oggi farlo con degli agenti ai cambia completamente sia la scala del problema che il campo di battaglia; se prima ci si trovava davanti ad ackers-geni brillanti quanto prezzolati e senza etica che con notti insonni e valanghe di ore perse tra matematiche logiche, complesse attività su server di attacco e mare di codice di elevatissima qualità, oggi sostanzialmente qualsiasi smanettone probabilmente privo di ogni virtù quanto privo delle basilari conoscenze informartiche è in grado, con gli strumenti AI giusti, di fare molto più danno in molto meno tempo ed in maniera molto più silenziosa e furba. E chi amministra un ecommerce deve rendersene conto quanto prima.

IL BOT È IL PRIMO ANELLO DELLA CATENA

Un bot può interrogare automaticamente migliaia di pagine, endpoint e servizi alla ricerca di determinate caratteristiche, anche se naturalmente non tutti i bot sono ostili: Google utilizza bot per indicizzare il Web, esistono sistemi automatici di monitoraggio, comparatori e oggi anche agenti AI che navigano autonomamente, quindi il problema è anche quello di distinguere il traffico automatico utile da quello indesiderato o apertamente ostile.

Ed è una distinzione sempre più difficile perché limitarsi all'indirizzo IP non è sufficiente, così come non basta credere a ciò che un programma dichiara di essere, e per questo le soluzioni moderne di bot management cercano di analizzare anche il comportamento complessivo delle richieste. La questione diventa ancora più importante perché un bot non deve necessariamente trovare una vulnerabilità per creare un problema.

ATTACCARE SENZA "BUCARE" NULLA

Pensiamo alla pagina di login, che è stata costruita appositamente per accettare username e password, ma che un programma automatico può utilizzare per provare grandi quantità di credenziali rubate precedentemente altrove, dando luogo al cosiddetto credential stuffing. Il codice del login potrebbe essere perfettamente corretto e l'attacco nascere semplicemente dall'automazione di una funzione legittima.

Lo stesso principio può essere applicato al checkout, alla creazione degli account, ai coupon, al recupero password oppure alla disponibilità del magazzino, perché un bot potrebbe per esempio utilizzare il carrello in maniera anomala oppure interrogare continuamente il catalogo per raccogliere prezzi e disponibilità. Dal punto di vista HTTP ogni richiesta potrebbe risultare perfettamente valida, ma osservando l'insieme delle operazioni il comportamento cambia completamente significato ed è proprio qui che un semplice firewall tradizionale inizia a non bastare.

POI ARRIVANO LE VULNERABILITÀ VERE

L'altra possibilità è che durante la ricognizione venga individuato un componente effettivamente vulnerabile e la falla può essere nel core di PrestaShop o Magento, ma molto spesso può trovarsi anche in un modulo, in una libreria, in un'integrazione oppure in un componente installato anni prima e mai più controllato. Per questo la frase "uso l'ultima versione di PrestaShop" non equivale a "il mio negozio è sicuro" e la stessa cosa vale per Magento.

PrestaShop 9.1.5, pubblicato nell'agosto 2026, ha corretto per esempio vulnerabilità differenti tra loro, comprese una SSRF, una SQL Injection nel back office e un problema nella gestione degli indirizzi IP quando il negozio opera dietro proxy o CDN, e quest'ultimo caso è particolarmente interessante perché dimostra come una vulnerabilità possa compromettere anche altre protezioni basate sull'IP, come logging, geoblocking o rate limiting.

Magento ci offre un esempio ancora più recente perché il 7 settembre 2026 Adobe ha pubblicato un bollettino relativo a una vulnerabilità critica di Adobe Commerce e Magento Open Source, CVE-2026-75650, specificando di essere a conoscenza di sfruttamenti reali, mentre il giorno successivo sono arrivati ulteriori aggiornamenti di sicurezza e indicazioni specifiche sull'hotfix da applicare. Questo ci insegna una cosa fondamentale: essere sull'ultima versione disponibile non significa automaticamente avere applicato tutte le correzioni necessarie.

ECCO PERCHÉ ESISTE IL WAF

WAF significa Web Application Firewall e, per chi non è tecnico, possiamo immaginarlo come un posto di controllo collocato prima dell'e-commerce, perché la richiesta del visitatore non arriva immediatamente a PrestaShop o Magento ma passa prima attraverso un sistema che può analizzarla e decidere se lasciarla passare, limitarla oppure bloccarla.

La differenza rispetto a un normale firewall è importante perché un firewall di rete controlla principalmente connessioni e protocolli, mentre un WAF osserva, giudica ed agisce in base al traffico HTTP applicativo (il livello applicazione dello stack ISO-OSI) e può quindi capire se una richiesta sta andando verso il login, verso un'API oppure verso una funzione particolarmente delicata applicando regole differenti. In un'architettura moderna, inoltre, il WAF viene spesso affiancato da CDN, protezione DDoS, sistemi anti-bot e rate limiting e più traffico malevolo viene fermato prima di raggiungere PHP, Magento, PrestaShop o il database, minore sarà anche il carico sull'infrastruttura.

LA "PATCH VIRTUALE"

Una delle funzioni più interessanti di un WAF è la possibilità, in determinati casi, di bloccare temporaneamente una classe di attacco mentre si attende di aggiornare l'applicazione, tecnica che viene spesso chiamata virtual patching ed è molto utile, ma bisogna capire bene cosa significa perché il WAF non ha corretto il software ma ha semplicemente messo una protezione davanti al punto vulnerabile, mentre la patch vera e propria rimane indispensabile.

MA WAF NON RISOLVE TUTTO

Un WAF può essere molto efficace contro molte categorie di attacco, ma non può capire automaticamente qualsiasi abuso dell'applicazione perché, se qualcuno utilizza credenziali realmente valide oppure possiede una chiave API corretta, la richiesta potrebbe apparire del tutto normale e lo stesso vale per determinati errori di business logic, perchè se il software permette legalmente un'operazione che non avrebbe dovuto consentire in quel contesto, non è detto che il WAF possa capirlo, ed è esattamente per questo che sicurezza applicativa, WAF, gestione dei bot e controllo delle API devono essere considerate parti dello stesso sistema, prima linea e non prodotti alternativi tra loro.

LE API SONO DIVENTATE UNA DELLE PARTI PIÙ IMPORTANTI DELL'ECOMMERCE

Un negozio moderno deve poter comunicare continuamente con altri sistemi, deve sincronizzare prezzi e prodotti, aggiornare il magazzino, ricevere informazioni dai pagamenti per modificare gli stati degli ordini oppure inviare ordini a gestionali e corrieri, e gran parte di queste comunicazioni avviene attraverso API.

PrestaShop 9, per esempio, dispone di una nuova Admin API basata su API Platform e OAuth2, con permessi assegnabili attraverso scope e questo principio è corretto ed importantissimo perché un'applicazione deve poter fare soltanto ciò di cui ha realmente bisogno, come nel caso di un gestionale che deve aggiornare il magazzino e dove non esiste alcuna ragione per concedergli automaticamente privilegi amministrativi sull'intero negozio.

Magento Open Source utilizza invece diffusamente REST e GraphQL e quest'ultimo è particolarmente interessante perché permette di richiedere molte informazioni in modo estremamente flessibile, ma proprio questa potenza può creare problemi se le query diventano troppo profonde o complesse, motivo per cui Magento dispone di limiti specifici destinati a impedire che una singola richiesta obblighi il server a svolgere una quantità sproporzionata di lavoro.

IL PROBLEMA NON È SOLTANTO CHI SEI, MA COSA PUOI FARE

La sicurezza delle API ruota soprattutto intorno all'autorizzazione perché non basta sapere che qualcuno possiede un token valido, ma bisogna sapere quali dati può leggere, quali può modificare e quante volte può effettuare determinate operazioni. OWASP dedica ormai una propria Top 10 esclusivamente alla sicurezza delle API proprio perché molte vulnerabilità moderne non consistono nell'entrare nel sistema senza autenticazione, ma nell'utilizzare male privilegi che il sistema ha concesso, e questo principio diventa particolarmente importante negli e-commerce perché le API possono raggiungere ordini, clienti, prodotti, inventario e processi amministrativi.

CARDING COME METODO DI VERIFICA PIRATA

Un negozio online può essere utilizzato anche per verificare automaticamente se dati di carte di pagamento rubate altrove siano ancora validi e l'attaccante, in quel caso, non è necessariamente interessato ai prodotti del negozio perché sta semplicemente utilizzando il checkout come strumento di verifica. Ancora una volta non è detto che esista una vulnerabilità nel codice, perché siamo davanti a una funzione legittima utilizzata in maniera ostile.

Magento prevede infatti controlli di rate limiting anche per ridurre questo genere di abuso sulle operazioni di pagamento ed è proprio il rate limiting uno degli strumenti più semplici e importanti, perché se una persona compie normalmente poche operazioni in un determinato intervallo di tempo mentre un'automazione ne esegue migliaia, la frequenza diventa un segnale fondamentale.

Un'ultima precisazione su questo nel caso abbiate letto o se qualcuno vi avesse detto che per il carding non si usano più gli e-commerce perché ormai basta un banale script in Python gestito da una AI, sappiate che chi vi ha detto ciò potrebbe essere il classico smanettone che usa l'AI per fare idiozie sul web. Il motivo è puramente tecnico e normativo, ovvero che uno script isolato non ha alcun permesso per dialogare direttamente con i circuiti bancari, poiché per verificare una carta serve un Merchant Account ed un'azienda reale. Lo script non sostituisce un e-commerce, ma lo sfrutta come prestanome inconsapevole bombardando il checkout di finti acquisti per costringere il server del negoziante legittimo a interrogare la banca al posto del criminale. Lo dico perchè spesso ci si trova davanti a sistemi compromessi con checkout pieni zeppi di quelle che gli amministratori definivano tentativi errati..

DAL RATE LIMITING AL BOT MANAGEMENT

Naturalmente il concetto non può ridursi a "dieci richieste e poi blocco l'IP" perché oggi il traffico può provenire da migliaia di indirizzi differenti e molti utenti reali possono condividere lo stesso indirizzo, quindi i sistemi più evoluti osservano diversi segnali contemporaneamente e cercano di riconoscere un comportamento. Una richiesta isolata può sembrare innocua, mentre diecimila richieste simili eseguite con la stessa logica raccontano una storia completamente diversa, ed è esattamente qui che si inserisce il concetto di AI Traffic Control.

COS'È DAVVERO AI TRAFFIC CONTROL

Nel contesto dal quale proviene questa espressione, AI Traffic Control non è uno standard universale del Web, ma il nome utilizzato nell'ecosistema Host.it e Magentiamo per descrivere una soluzione di controllo intelligente del traffico. L'idea è comunque interessante indipendentemente dal nome commerciale perché consiste nel non limitarsi a cercare soltanto firme di attacchi già conosciuti, ma nell'analizzare il comportamento del traffico e individuare pattern anomali.

L'intelligenza artificiale può aiutare soprattutto nell'analisi di grandi quantità di log e nella ricerca di comportamenti ricorrenti difficili da individuare manualmente, ma alla fine il sistema deve sempre trasformare quella valutazione in una decisione concreta, consentendo, bloccando, limitando oppure richiedendo una verifica aggiuntiva. La parte importante non è quindi avere la parola AI nella descrizione del prodotto, ma capire quali informazioni vengono osservate, come vengono prese le decisioni e soprattutto come vengono gestiti gli errori.

LA NUOVA GENERAZIONE DI WAF

Nello stesso ambito troviamo oggi soluzioni come Blackwall, che operano come reverse proxy davanti all'applicazione e combinano protezione WAF, analisi del traffico, bot management e rate limiting. Il concetto interessante è il passaggio da una protezione basata soltanto sulla singola richiesta a una protezione capace di osservare anche il comportamento complessivo.

Un visitatore umano apre la home, guarda qualche prodotto, utilizza la ricerca e magari aggiunge qualcosa al carrello, mentre Googlebot percorre sistematicamente le pagine ma può essere riconosciuto come crawler legittimo; un programma che scarica migliaia di schede prodotto oppure tenta continuamente autenticazioni può invece mostrare un comportamento incompatibile con quello di un normale visitatore. Una buona protezione deve riuscire a distinguere queste situazioni senza danneggiare il traffico reale.

IL PROBLEMA PIÙ PERICOLOSO È QUELLO CHE NON PASSA DAL WAF

Possiamo installare il miglior WAF disponibile e commettere comunque un errore elementare, cioè lasciare il server originale direttamente raggiungibile da Internet, perché in quel caso qualcuno potrebbe tentare di arrivare direttamente all'origin e aggirare completamente il livello di protezione. Per questo nelle architetture ben progettate il traffico pubblico dovrebbe essere obbligato a passare attraverso il sistema di protezione.

Lo stesso principio vale per API dimenticate, vecchi sottodomini, pannelli amministrativi secondari oppure servizi creati anni prima, perché un attaccante non ha nessun motivo per entrare dalla porta principale se trova una finestra aperta sul retro.

E POI CI SONO I MODULI

È forse uno dei problemi più sottovalutati perché PrestaShop e Magento possono essere perfettamente aggiornati mentre un modulo installato continua a eseguire codice vecchio e possiede accesso agli ordini, ai clienti oppure al checkout. Quel modulo fa parte dell'e-commerce esattamente come il core e per questo la sicurezza parte anche da una cosa apparentemente banale: sapere esattamente quali componenti sono installati e mantenerli aggiornati.

BLOCCARE TUTTO NON È SICUREZZA

La parte difficile arriva proprio qui perché rendere un sito inaccessibile è semplicissimo, mentre la sicurezza di un e-commerce deve proteggere il sistema continuando a permettere ai clienti, ai motori di ricerca, ai gateway di pagamento, ai corrieri e ai gestionali di funzionare correttamente.

Una WAF configurata male può bloccare clienti reali, rompere un webhook oppure impedire a un sistema esterno di comunicare con il negozio, quindi il problema non consiste soltanto nel fermare ciò che è ostile ma nel farlo senza distruggere ciò che è legittimo, ed è probabilmente qui che i sistemi moderni di analisi comportamentale diventano realmente interessanti.

LA CATENA D'ATTACCO, SENZA PUNTI CIECHI

A questo punto possiamo vedere l'attacco nel suo insieme perché prima arriva la ricognizione e viene costruita una mappa della superficie esposta, poi il traffico automatizzato individua le parti più interessanti, come login, API, checkout o componenti specifici, e a quel punto l'attaccante può cercare una vulnerabilità vera oppure abusare di una funzione perfettamente legittima.

La difesa deve quindi operare a più livelli perché il traffico inutile dovrebbe essere fermato prima di raggiungere l'applicazione, le richieste anomale dovrebbero incontrare rate limiting e bot management, gli attacchi riconoscibili dovrebbero essere intercettati dal WAF e le API dovrebbero applicare autenticazione e autorizzazioni rigorose, ma soprattutto dobbiamo poter ricostruire ciò che è accaduto perché un sistema che blocca qualcosa senza spiegarci perché lo ha fatto è molto meno utile di quanto sembri.

LA DOMANDA GIUSTA NON È PIÙ "HO IL FIREWALL?"

Chi amministra un e-commerce dovrebbe iniziare a fare domande differenti e chiedersi se il server può essere raggiunto direttamente oppure se tutto il traffico passa realmente attraverso la protezione, se esiste una WAF applicativa mantenuta e aggiornata, se login, checkout e API hanno limiti specifici, quali integrazioni possiedono credenziali valide e quali moduli sono installati e controllati.

Sono poche domande, ma raccontano molto più della frase "abbiamo il firewall".

L'ECOMMERCE CHE VEDE L'ATTACCANTE NON È QUELLO CHE VEDIAMO NOI

Noi vediamo catalogo, clienti, ordini e pagamenti mentre chi studia il sistema da un punto di vista offensivo vede richieste, endpoint, sessioni, token, autorizzazioni, moduli e comportamenti, ed è questa probabilmente la cosa più importante da comprendere.

La sicurezza moderna non può più limitarsi a chiedersi se una singola richiesta sia buona o cattiva, ma deve capire chi sta parlando con il negozio, cosa sta cercando di fare, con quale frequenza e fino a dove gli abbiamo consentito di arrivare. Il bot può essere soltanto il primo anello della catena, la vulnerabilità applicativa può essere soltanto quello successivo e il WAF non è il muro definitivo ma uno dei posti di controllo.

La vera protezione nasce quando riusciamo a osservare l'intero percorso che una richiesta compie da Internet fino alla parte più delicata del nostro sistema di vendita, perché chi vuole attaccarlo quel percorso lo studia già e noi dobbiamo conoscerlo almeno altrettanto bene.

Federico Lomazzi

Settembre 2026