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.
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
Content Security Policy per ecommerce: rollout sicuro tra checkout e analytics
Una guida operativa per introdurre la CSP senza bloccare pagamenti, consenso e misurazione: inventario, Report-Only, nonce, test dei percorsi e canary.
Passkey per ecommerce: rollout controllato tra login, checkout e recupero account
Un runbook operativo per introdurre le passkey senza bloccare guest checkout o utenti esistenti: flussi WebAuthn, fallback, recovery, metriche e rollout progressivo.
Disaster recovery ecommerce: RPO, RTO e test di ripristino
Come trasformare backup e procedure sparse in un piano di recupero ecommerce misurabile, provato end-to-end e collegato alle priorità del business.
