# Un logo che può eseguire codice: perché gli SVG caricati sono un rischio sottovalutato

> Gli SVG possono contenere script. Perché i loghi caricati sono un vero rischio di sicurezza — e come la bonifica al caricamento lo risolve davvero.

Un SVG non è un file immagine nel senso consueto, ma un documento di testo che può contenere script — e quindi ogni logo caricato è, nel dubbio, codice eseguibile. Il formato SVG prevede esplicitamente un proprio elemento script; serve ad [aggiungere script a un documento SVG](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/script). Proprio per questo la bonifica di questi file appartiene alle fondamenta, non alla responsabilità di chi in quel momento sta caricando un logo.

Non lo scrivo per fare allarmismo. Lo scrivo perché è una falla che vedo da anni in progetti per il resto costruiti bene — e perché è uno dei pochi problemi di sicurezza che si risolvono per bene una volta sola, e poi non si toccano mai più.

## Perché un SVG può fare qualcosa che un JPG non può

Un JPG o un PNG è una griglia: una tabella di puntini colorati. Un browser non può ricavarne altro che colore sullo schermo. Un SVG invece è un'istruzione di disegno in forma di testo — strutturata come un documento, con elementi, attributi e annidamenti. È questa struttura a rendere gli SVG nitidi a qualsiasi ingrandimento e leggerissimi. Ed è la stessa struttura all'origine del problema.

In quella struttura, però, ci sta molto più della geometria. Un SVG può contenere un elemento script. Può portare attributi di evento che fanno partire codice al caricamento o al clic. Può incorporare contenuti estranei e rimandare a indirizzi esterni. E un logo con uno script dentro è identico, a vedersi, a un logo senza. Né nell'anteprima né nel gestore file la differenza si nota. Si nota solo aprendo il file in un editor di testo — cosa che nella pratica non fa nessuno.

## Dove il rischio diventa un incidente

Il punto critico è preciso: quando il file caricato viene poi servito sotto il tuo stesso indirizzo. Se qualcuno lo apre direttamente, lo script contenuto gira nel contesto del tuo dominio — con tutto quello che il browser si porta dietro lì: sessione autenticata, permessi, fiducia.

Non è un costrutto teorico. È una classe di vulnerabilità documentata e ricorrente. Un esempio consultabile pubblicamente: in un'applicazione open source per l'autenticazione a due fattori gli SVG venivano accettati come tipo di immagine valido e serviti, alla richiesta diretta, senza header di protezione. Un attaccante poteva caricare un SVG con dentro del JavaScript; chi apriva poi il file direttamente consegnava la propria sessione. Il caso è registrato come CVE-2024-52597, pubblicato il 20 novembre 2024, valutato CVSS 6.1 e risolto nella versione 5.4.1 ([GitHub Security Advisory](https://github.com/Bubka/2FAuth/security/advisories/GHSA-q5p4-6q4v-gqg3)).

La sequenza è sempre la stessa: permesso di caricare, salvataggio senza controlli, distribuzione sotto il proprio indirizzo. Tre passaggi che, presi uno per uno, sembrano tutti innocui.

## L'equivoco del «tanto lo mostriamo solo come immagine»

Un'obiezione ricorrente suona così: tanto le immagini le inseriamo solo come immagini, non succede nulla. La prima parte è perfino vera. Se un SVG viene inserito come immagine — tramite un elemento immagine o come sfondo via regola di stile — di norma valgono delle restrizioni: JavaScript non viene eseguito e le risorse esterne non vengono caricate. Ma queste restrizioni valgono [espressamente solo per il contesto immagine](https://developer.mozilla.org/en-US/docs/Web/SVG/Guides/SVG_as_an_Image). Se lo stesso file viene aperto direttamente o incorporato come documento, decadono — e l'SVG si comporta con tutte le sue funzioni, esecuzione di script inclusa.

Ed è esattamente il punto che l'obiezione non vede: come inserisci il file nel tuo sito lo decidi tu. Se qualcuno ne apre l'indirizzo direttamente nel browser, non lo decidi tu. Da quando un file ha un indirizzo pubblico, la chiamata diretta è sempre possibile.

## Chi carica davvero gli SVG

La risposta spiega perché il tema è così persistente: praticamente tutti, e quasi mai con un controllo. Il logo arriva dalla grafica, il set di icone da una libreria, la cartina dall'associazione turistica, il logo del partner via e-mail dal partner stesso. Questi file passano per diverse mani prima di finire in un sistema redazionale. In quella catena nessuno ha il compito di guardare dentro il file — e nessuno avrebbe lo strumento per farlo.

Ecco perché «basta fare attenzione» qui non è una soluzione. Una regola che dipende dall'attenzione di chi sta sostituendo un logo di corsa non è una regola. È una speranza.

## La soluzione va messa alla porta, non alla finestra

L'approccio che funziona è la sanificazione degli upload: il file viene controllato e ripulito prima ancora di essere salvato — e a essere salvata è la versione ripulita, non l'originale. Dietro ci sono quattro regole:

- **Permettere invece di vietare.** Non passa «tutto tranne gli script», ma solo il vocabolario di disegno conosciuto: tracciati, forme, colori, sfumature, filtri. Tutto ciò che non è in quell'elenco viene scartato. Le liste di divieti si aggirano; quelle di permessi no.
- **Script e contenuti estranei incorporati vengono eliminati.** L'elemento script e allo stesso modo il meccanismo con cui si può infilare HTML arbitrario dentro una grafica.
- **Gli attributi di evento vengono eliminati.** Tutto ciò che al caricamento, al clic o in caso di errore potrebbe far partire del codice.
- **I riferimenti possono puntare solo verso l'interno.** I rimandi interni allo stesso file sono ammessi — sono normale tecnica di disegno. Quelli verso l'esterno no, comunque siano scritti. Perché è proprio qui che si gioca sporco: grafie insolite, namespace diversi, annidamenti creativi.

Il motivo per cui questo deve avvenire al caricamento e non alla visualizzazione è banale e decisivo: un file si salva una volta e si distribuisce mille. Se la bonifica sta alla porta, ogni percorso di uscita successivo eredita automaticamente il file pulito — il sito, la cache, un export, un servizio di distribuzione esterno. Se sta alla finestra, devi montarla su ogni singola finestra e una te la dimenticherai.

## Due dettagli che si scoprono solo nella pratica

Costruendo la cosa si vede che qui due dettagli in apparenza insignificanti decidono tra successo e grattacapi.

Primo, l'indicazione della dimensione. Se un file rimpicciolisce durante la bonifica, la dimensione dichiarata all'inizio non è più corretta. Se non viene aggiornata, il salvataggio si interrompe in un punto completamente diverso — con un messaggio d'errore che non ha nulla a che fare con la sicurezza. Sono effetti collaterali come questo a far smontare in silenzio le misure di sicurezza: non perché siano sbagliate, ma perché fanno male nel punto sbagliato.

Secondo, l'elenco dei tipi di file ammessi. Una formula generica del tipo «tutte le immagini» è comoda e pericolosa, perché include tacitamente ogni formato futuro. Un elenco esplicito e finito è più scomodo e giusto. Ci va aggiunto un limite di dimensione stretto e dedicato per questo tipo di grafica — un logo non ha bisogno di 25 megabyte, e un limite stretto riduce di riflesso quanto si può nascondere in un file del genere.

## I limiti, detti con onestà

Tre cose che non voglio sostenere.

Nessuna bonifica è sicura al cento per cento. La rincorsa tra filtri e aggiramenti ingegnosi va avanti, e per questo la bonifica è uno strato di una protezione a più livelli, non l'intera protezione.

Vale dal momento in cui è stata installata. I file finiti nel sistema prima non diventano puliti retroattivamente — chi aggiunge una misura del genere dovrebbe guardarsi una volta l'archivio esistente, a parte.

Ed è una decisione del tutto legittima non permettere affatto il caricamento di SVG alla redazione e far inserire i loghi una volta sola da una persona tecnicamente responsabile. Meno comodità, meno superficie d'attacco. Da noi l'SVG è permesso e viene ripulito al salvataggio, perché avere loghi nitidi su qualsiasi dimensione di schermo è un vantaggio quotidiano reale — ma è una valutazione, non una costante di natura.

## Che cosa farne, se le decisioni le prendi tu

Non devi costruirlo tu. Devi solo sapere che cosa chiedere. Tre domande da fare a chiunque si occupi delle tue fondamenta digitali:

1. I file caricati vengono ripuliti al salvataggio — o archiviati così come sono?
2. Quali tipi di file sono ammessi: un elenco esplicito o una formula generica?
3. Che ne è dei file caricati prima di questa regola?

Se la risposta alla prima domanda è «se ne occupa un'estensione acquistata», la domanda successiva è chi mantiene quell'estensione e cosa succede quando smette di essere mantenuta. Da noi questo tipo di protezione sta nelle fondamenta stesse — non come modulo aggiuntivo da attivare o da dimenticare. Che cos'altro è compreso di serie lo trovi nella [panoramica delle funzionalità](https://btlabs.dev/it/funzionalita); in che cosa questo si distingue da un sistema basato su estensioni lo abbiamo scritto nel [confronto](https://btlabs.dev/it/confronto) dedicato.

Se non sei sicuro di come il tuo sistema attuale gestisca i caricamenti: [fatti sentire](https://btlabs.dev/it/contatti) — è una domanda che si chiarisce in una conversazione, non in un preventivo.

---
Source: https://btlabs.dev/it/posts/svg-caricati-rischio-sottovalutato
Last-Modified: 2026-08-25T07:00:01.115Z
Languages: [de](https://btlabs.dev/llms/de/posts/svg-uploads-unterschaetztes-risiko) · [en](https://btlabs.dev/llms/en/posts/svg-uploads-underestimated-risk)
See also: [llms.txt](https://btlabs.dev/llms.txt) · [ai.txt (Policy)](https://btlabs.dev/ai.txt) · [identity.json](https://btlabs.dev/identity.json)