Sistemi Digitali6 min di lettura

Upload file ecommerce sicuri: allegati, quarantena e distribuzione controllata

Una guida operativa per gestire allegati ecommerce con allowlist, upload diretto, quarantena, scansione malware, storage privato e download controllato.

Allegati ecommerce attraversano livelli separati di convalida, quarantena e scansione prima di raggiungere un archivio protetto

Un file caricato è un input non attendibile

Resi con fotografie, personalizzazioni grafiche, documenti B2B e ticket di assistenza trasformano l’upload in una funzione commerciale. Trasformano anche ogni allegato in contenuto non attendibile: nome, estensione e tipo dichiarato provengono dal client e non dimostrano che i byte siano sicuri. Il rischio non riguarda soltanto il malware. Un file può sfruttare parser vulnerabili, consumare spazio, sovraccaricare la scansione, sovrascrivere un oggetto esistente o diventare pubblico prima dei controlli.

La risposta non è un singolo antivirus, ma una pipeline di difesa in profondità. Come scelta progettuale fail-closed, raccomandiamo stati separati per autorizzazione, vincoli applicativi, storage privato, quarantena, analisi, pubblicazione e download. In questo modello ogni passaggio accetta un oggetto soltanto dopo l’esito del precedente e conserva abbastanza evidenza per capire chi ha caricato cosa, per quale pratica e con quale versione delle regole.

Definire perimetro e politica prima del codice

Classificare flussi e conseguenze

Costruisci un inventario per caso d’uso: estensioni necessarie, dimensione massima, quantità per richiesta, utenti autorizzati, durata di conservazione, destinazione e soggetti che potranno scaricare. Una fotografia di un reso, un PDF fiscale e un file sorgente per la stampa non hanno lo stesso profilo. Evita un endpoint universale con una lista permissiva; associa invece una policy esplicita al contesto di business e registra la versione applicata.

Definisci gli stati minimi, per esempio requested, uploaded, quarantined, accepted, rejected ed expired. Solo accepted può diventare disponibile al destinatario. Errori, timeout o indisponibilità dello scanner non equivalgono a un esito pulito: l’oggetto resta isolato e il sistema decide se ritentare o richiedere un nuovo caricamento. Questa semantica impedisce che un guasto trasformi la quarantena in una scorciatoia.

Validare l’intento e i byte su più livelli

Allowlist, dimensioni e nomi generati

Usa una allowlist di estensioni realmente necessarie e applicala dopo aver normalizzato il nome, gestendo maiuscole, doppi suffissi e caratteri ambigui. Il Content-Type inviato dal browser è utile come segnale, ma non è affidabile da solo. Confrontalo con estensione, firma o magic bytes e risultato di un parser adatto al formato. Anche un controllo coerente non rende il file innocuo: riduce gli input inattesi prima dell’analisi successiva.

Imponi limiti sia prima sia durante il trasferimento e rifiuta contenuti parziali o superiori alla policy. Non utilizzare il nome originale come chiave di storage. Genera un identificatore casuale non prevedibile, conserva il nome fornito dall’utente soltanto come metadato normalizzato e impedisci traversal, separatori di percorso e collisioni. Verifica inoltre che la pratica appartenga all’utente autorizzato e proteggi la richiesta di inizializzazione dalle azioni cross-site secondo l’architettura dell’applicazione.

Separare trasferimento, storage e autorizzazione

Upload diretto con permessi minimi

Un URL prefirmato può consentire al browser di inviare l’oggetto direttamente allo storage senza transitare i byte dal server applicativo. Non è però una decisione di sicurezza completa: chi possiede l’URL può usarlo entro le condizioni e la scadenza previste, con i poteri concessi dall’identità che lo ha generato. Crea quindi URL brevi, legati a una chiave nuova e a un singolo intento, dopo aver autorizzato utente, ordine o ticket.

Lo storage di ingresso deve essere privato e distinto dalla destinazione servita. Non permettere al client di scegliere liberamente bucket, percorso pubblico o chiave definitiva. Se una stessa chiave esiste, un nuovo caricamento può sostituire l’oggetto; l’unicità generata evita questa collisione. Alla conferma, il backend controlla presenza, dimensione e metadati attesi, collega l’oggetto alla pratica e lo porta in quarantena senza renderlo raggiungibile tramite URL pubblico.

Progettare il flusso di quarantena e scansione

Trattare ogni esito come dato operativo

Una possibile implementazione operativa usa un worker isolato che preleva l’oggetto con credenziali di sola lettura sul perimetro necessario, calcola un hash, identifica il tipo reale ed esegue i controlli previsti. Un motore come ClamAV può essere invocato tramite processo o servizio, ma richiede firme mantenute e limiti coerenti per archivi, ricorsione, tempo e dimensione estratta. Se il formato lo consente e il rischio lo richiede, una fase di normalizzazione o content disarm and reconstruction può ridurre contenuti attivi senza sostituire la scansione.

Registra versione del motore e delle firme, hash, durata, risultato e motivo del rifiuto con un codice interno. Non esporre dettagli diagnostici che aiutino ad adattare un payload. Un rilevamento sposta l’oggetto in uno stato non distribuibile e attiva la procedura prevista; un errore tecnico resta in quarantena. Evita retry senza limite: usa tentativi controllati, coda di errore e un allarme quando età o volume degli oggetti isolati supera le soglie interne.

Distribuire soltanto oggetti accettati

Download mediato e header coerenti

Come scelta progettuale fail-closed, il passaggio ad accepted dovrebbe essere una transizione atomica e verificabile, non una copia implicita eseguita dal client. Per i documenti privati, autorizza ogni download rispetto a account, ordine, ruolo e scadenza, poi usa un collegamento temporaneo o uno stream mediato. Imposta un Content-Type coerente con il formato verificato e considera Content-Disposition: attachment quando il contenuto deve essere scaricato anziché visualizzato inline. Il nome proposto resta un suggerimento e va sanificato.

X-Content-Type-Options: nosniff blocca una richiesta destinata a script o foglio di stile quando il MIME dichiarato non è valido per quella destinazione; per gli altri tipi di risposta disabilita il MIME sniffing. È un livello di difesa, non uno scanner degli allegati. La protezione nasce dall’insieme di storage privato, autorizzazione, tipo verificato e risposta controllata. Se alcuni media devono essere pubblici, pubblica una derivata rigenerata in un percorso separato, non l’originale non modificato, e impedisci l’esecuzione sul dominio applicativo.

Misurare sicurezza e affidabilità insieme

Osserva richieste inizializzate, upload completati, byte ricevuti, rifiuti per policy, tipi incoerenti, esiti della scansione, errori, timeout e tempo trascorso in quarantena. Segmenta per flusso e versione della policy, non per dati personali non necessari. Aggiungi indicatori di capacità: profondità della coda, età dell’oggetto più vecchio, spazio occupato, ritenti e percentuale di download autorizzati o negati.

Collega gli eventi con identificatori tecnici che non includano il nome originale o segreti. Un picco di errori può indicare firme non aggiornate, un parser instabile, abuso o una modifica lecita del client. Dashboard e allarmi devono permettere di sospendere un tipo di file, bloccare nuove inizializzazioni o mantenere tutto in quarantena senza perdere gli oggetti e senza aprire un percorso alternativo non controllato.

Testare incidenti, cancellazione e recupero

Prova file vuoti, estensioni doppie, MIME incoerenti, archivi protetti o eccessivamente annidati, trasferimenti interrotti, oggetti oltre soglia, collisioni, scanner indisponibile e download da account non autorizzato. Verifica che nessun esito diverso da pulito renda l’oggetto distribuibile. Esegui inoltre test di scadenza, cancellazione, audit e ripristino. Come ulteriore scelta fail-closed, configura il recupero affinché una copia di backup non reintroduca automaticamente un allegato respinto o scaduto.

Una pipeline solida rende visibile ogni confine: il client propone, l’applicazione autorizza, lo storage isola, i controlli classificano e il servizio di distribuzione decide l’accesso. Per progettare storage, code e controlli coerenti con il tuo ecommerce, esplora i nostri servizi per sistemi ecommerce. Se vuoi trasformare upload sparsi in un flusso verificabile, contatta AE Digital Agency per definire policy, quarantena e criteri operativi.

file uploadsicurezza ecommerceallegatiquarantenamalwareobject storagemime type

Domande frequenti

Controllare estensione e Content-Type rende sicuro un file caricato?

No. Entrambi sono segnali utili ma controllabili dal client. Vanno confrontati con firma, tipo reale e parser, poi affiancati da limiti, storage privato, quarantena, scansione e distribuzione autorizzata.

Un URL prefirmato può rendere pubblico lo storage?

Non richiede che il bucket sia pubblico, ma concede a chi possiede l’URL l’operazione prevista entro scadenza e condizioni. Deve quindi nascere dopo l’autorizzazione, usare una chiave unica e avere durata contenuta.

Che cosa succede se lo scanner malware non risponde?

Il file non va considerato pulito. Resta in quarantena con uno stato di errore, può seguire retry controllati e deve generare un allarme se supera le soglie operative definite.

Come si consegna in sicurezza un allegato ecommerce accettato?

Il backend verifica account, ordine o ruolo, poi rilascia un URL temporaneo o media lo stream. La risposta usa tipo verificato, nome sanificato e Content-Disposition appropriato al caso d’uso.

Articoli correlati

Hai un progetto simile?

Raccontaci il problema. Costruiamo la soluzione.

Parliamone

Hai un progetto in mente?

Raccontaci il problema. Costruiamo la soluzione.

Parliamone