Il 76% non aveva una CSP e il 64% poteva essere caricato all’interno di un frame controllato da un altro sito. Sono i due risultati più eclatanti di una revisione dei siti web di protocolli DeFi pubblicata su DEV Community. L’analisi ha esaminato le risposte ricevute da un normale browser; non ha tentato di sfruttare i siti né di connettersi ai loro wallet.
La distinzione è importante: le cifre descrivono la configurazione visibile delle pagine analizzate, non incidenti o perdite. Tuttavia, indicano difese web che possono essere rilevanti quando un’interfaccia invita a firmare operazioni con un wallet.
Cosa ha misurato la revisione
Il team è partito dai protocolli di DefiLlama dotati di un sito web — circa 4.000 domini — e ne ha scelti 1.000 a caso. Di questi, 896 hanno risposto; 39 hanno bloccato i controlli automatizzati e 65 non hanno risposto. Le percentuali pubblicate si basano su questi 896 siti.
Il controllo è stato passivo: è stata caricata la pagina iniziale e sono state verificate le intestazioni di risposta, gli indicatori dei cookie, HTTPS, gli script di terze parti e i link non funzionanti. Non sono stati effettuati accessi, connessioni a wallet, invii di moduli né ricerche di file nascosti. Non sono stati pubblicati neanche i nomi dei progetti o i risultati individuali.
Oltre all’assenza di CSP e di protezione dal framing, il team ha rilevato che il 35% non aveva HSTS, il 27% caricava script di terze parti senza Subresource Integrity (SRI), il 6% aveva cookie privi degli attributi Secure o HttpOnly e il 5% presentava link non funzionanti nella pagina iniziale.
Il limite principale riguarda il luogo in cui è stato eseguito il test. In molti progetti, la pagina iniziale è un sito informativo e l’applicazione con il pulsante per connettere un wallet si trova a un altro indirizzo. Per questo, la stessa analisi presenta i risultati come un’indicazione da approfondire, non come la prova che le persone che usano quei progetti siano in pericolo.
Un’interfaccia può fare parte della superficie di attacco
Il rapporto mette a confronto le misure dedicate alla protezione degli smart contract con l’attenzione riservata ai siti web che gli utenti utilizzano per interagire con essi. Come precedenti, cita l’incidente di BadgerDAO del dicembre 2021, che ha causato perdite per circa 120 milioni di dollari, in cui uno script iniettato nell’interfaccia ha richiesto approvazioni di token. Menziona anche l’incidente di Ledger Connect Kit del dicembre 2023: una versione compromessa di una libreria di interfaccia molto diffusa ha trasformato le dApp in strumenti per svuotare i wallet.
La CSP, o Content Security Policy, consente al sito di limitare le risorse che il browser può caricare e le destinazioni a cui può inviare dati. Secondo l’analisi, funge da seconda barriera nel caso in cui sia già stato possibile iniettare uno script: può limitare l’origine da cui viene eseguito il codice e le destinazioni a cui vengono trasmessi i dati. Non impedisce da sola ogni iniezione, ma una policy esplicita riduce ciò che quel codice potrebbe fare.
Il framing comporta un altro rischio. La guida ai test di OWASP descrive il clickjacking come un inganno in cui una pagina nasconde l’applicazione bersaglio all’interno di un iframe e induce la persona a fare clic su elementi diversi da quelli che crede di usare. Per un’interfaccia che richiede firme, il team di DEV Community ipotizza che un aggressore possa allineare un pulsante di approvazione sotto un altro che promette, per esempio, di riscattare una ricompensa.
La pagina caricata rimane quella autentica, ma la persona può interagire con essa senza rendersi conto dell’azione che sta compiendo. OWASP avverte anche che in questo scenario alcune difese contro CSRF possono essere aggirate. Perciò, non basta che lo smart contract sia corretto se l’interfaccia che conduce a una firma può essere presentata in modo ingannevole.
Il confronto non mostra un vantaggio nelle due difese fondamentali
Per fare un confronto, il team ha esaminato anche 1.000 siti web comuni; 571 hanno risposto. Su tre misure, i siti DeFi hanno ottenuto risultati migliori: HSTS mancava nel 35% dei casi, contro il 61%; i cookie erano privi di Secure o HttpOnly nel 6% dei casi, contro il 26%; e il 27% aveva script di terze parti senza SRI, contro il 64%.
Il confronto cambia però per le protezioni più direttamente legate alle interfacce che richiedono firme. Il 64% dei siti DeFi poteva essere inserito in un frame da un altro sito, contro il 58% dei siti comuni. Inoltre, il 76% era privo di CSP, contro il 79% dell’altro campione. In altre parole, la revisione non ha rilevato un vantaggio dei siti DeFi per questi due controlli; non dimostra nemmeno che i siti confrontati offrano lo stesso tipo di interazione o comportino lo stesso rischio.
Configurazione semplice, ma con scelte di compatibilità
Il team propone tre misure: una CSP con un elenco esplicito di script consentiti e la direttiva frame-ancestors 'none'; SRI per ogni script di terze parti — oppure ospitarli sulla propria infrastruttura — e HSTS. Secondo il team, si tratta di correzioni di configurazione, non di codice, e tutte e tre possono essere implementate in un pomeriggio.
La direttiva frame-ancestors consente di specificare quali siti possono incorporare una pagina tramite elementi come iframe. OWASP raccomanda di usarla come difesa lato server contro il clickjacking. Il valore 'none' impedisce agli altri siti di inserirla in un frame; per un prodotto che deve consentire frame legittimi, la policy dovrà tenere conto di questa esigenza anziché bloccarli indiscriminatamente.
Anche la CSP richiede di decidere quali risorse siano effettivamente necessarie all’applicazione. Un elenco esplicito di script consentiti può limitare l’esecuzione di codice non autorizzato, ma deve includere le origini legittime utilizzate dal sito. La revisione stessa segnala una precisazione su SRI: permette al browser di rifiutare uno script il cui contenuto è cambiato, ma non è applicabile agli script che cambiano per progettazione, come la maggior parte dei tag di analisi. Per questi casi, il rapporto indica la CSP come protezione.
Il contrasto tra rapidità di correzione e compatibilità è particolarmente rilevante per i team che dipendono da fornitori esterni: la raccomandazione non è aggiungere controlli senza verificarne l’effetto, ma decidere quali script servono alla pagina e quali possono essere ospitati sul sito stesso. L’analisi non fornisce dati sul lavoro richiesto da ciascuna correzione né verifica le policy proposte per ogni progetto; la stima dei tempi di implementazione è un’indicazione del team.
Cosa dovrebbe verificare un team
Il risultato più utile non è presumere che una specifica applicazione sia vulnerabile, ma controllare le pagine in cui avvengono le azioni sensibili, non solo la pagina iniziale. La metodologia pubblicata si è concentrata sulle pagine iniziali e riconosce che l’applicazione con la connessione al wallet potrebbe trovarsi su un altro dominio. Inoltre, OWASP raccomanda di verificare le varianti per dispositivi mobili e quelle per l’accessibilità: potrebbero avere protezioni diverse da quelle desktop.
È inoltre opportuno verificare le intestazioni ricevute dal browser su ogni pagina rilevante. OWASP avverte che i proxy possono rimuovere o modificare le intestazioni e che una protezione applicata solo ad alcune pagine ne lascia altre scoperte. CSP, policy di framing e HSTS devono essere valutati nelle risposte effettive, non soltanto nella configurazione che il team ritiene di aver implementato.
La revisione offre un’istantanea circoscritta al novembre 2026, basata sull’elenco dei protocolli di DefiLlama e sul caricamento delle pagine iniziali. Non permette di sapere quante applicazioni complete presentino le stesse carenze. Lascia però a ogni team DeFi una domanda concreta: la pagina che mostra il pulsante di connessione e la richiesta di firma ha le stesse difese della pagina iniziale?
Fonti: DEV Community, OWASP Foundation
