top of page
Immagine del redattoreAndrea Viliotti

OWASP Top 10 LLM: dieci vulnerabilità per applicazioni basate su LLM

La sicurezza delle applicazioni basate su modelli di linguaggio di grandi dimensioni (LLM) è una tematica sempre più rilevante man mano che l'integrazione di tali tecnologie nei sistemi aziendali e nei servizi al pubblico si diffonde. La nuova versione 2025 della classifica OWASP Top 10 LLM per le vulnerabilità nelle applicazioni basate su LLM descrive i rischi più critici a cui queste applicazioni sono esposte. Questo articolo è una sintesi dei risultati del lavoro svolto dal team OWASP e dalle istituzioni coinvolte, basato sui contributi di esperti di sicurezza, sviluppatori e data scientist provenienti da diversi settori. In questo articolo esploreremo ciascuna delle vulnerabilità identificate, fornendo esempi concreti e possibili strategie di mitigazione.

OWASP Top 10 LLM: dieci vulnerabilità per applicazioni basate su LLM
OWASP Top 10 LLM: dieci vulnerabilità per applicazioni basate su LLM

Prompt Injection (OWASP Top 10 LLM)

Il problema del Prompt Injection si verifica quando l'input di un utente riesce a manipolare il comportamento di un modello linguistico, modificando l'output o le azioni del modello in modi indesiderati. Questa vulnerabilità può essere sfruttata sia intenzionalmente, da parte di attori malevoli che forniscono input progettati per ingannare il modello, sia accidentalmente, quando input imprevisti portano a un comportamento errato del sistema. Un aspetto particolarmente complesso è che gli attacchi di prompt injection possono non essere visibili o leggibili dagli esseri umani: qualsiasi contenuto che il modello riesca a interpretare può potenzialmente influenzare il suo comportamento.


Esistono due principali tipologie di attacchi di Prompt Injection: diretti e indiretti. Gli attacchi diretti si verificano quando l'attaccante introduce direttamente un comando o un input che induce il modello a eseguire azioni indesiderate, come ignorare linee guida di sicurezza, rivelare informazioni sensibili, o addirittura effettuare azioni pericolose come l'accesso a risorse non autorizzate. Gli attacchi indiretti, invece, avvengono attraverso input provenienti da fonti esterne, come file o siti web, che contengono istruzioni che il modello può interpretare e che alterano il suo comportamento.


Una nuova sfida emergente è legata ai modelli multimodali, che sono progettati per gestire input di diverse tipologie, come testo e immagini contemporaneamente. Gli attaccanti potrebbero, ad esempio, nascondere istruzioni all'interno di immagini che accompagnano del testo. Questi attacchi "cross-modal" aumentano significativamente la superficie di attacco, rendendo molto più complessa la difesa contro il prompt injection.


L'impatto di un attacco di prompt injection può essere devastante: dalla divulgazione di informazioni sensibili, al bypass delle misure di sicurezza del sistema, fino alla manipolazione delle decisioni critiche del modello. Ad esempio, un attaccante potrebbe utilizzare prompt nascosti per far sì che un chatbot di assistenza clienti ignori tutte le regole di sicurezza interne, consentendo l'accesso a dati personali riservati.


Per mitigare il rischio di prompt injection, è essenziale adottare diverse strategie di protezione. Prima di tutto, limitare il comportamento del modello attraverso la definizione precisa dei suoi ruoli e delle sue capacità è un passo cruciale. Fornire istruzioni chiare al modello su ciò che è consentito e ciò che non lo è aiuta a prevenire deviazioni indesiderate. Inoltre, è importante filtrare gli input e gli output, utilizzando strumenti semantici che possano identificare contenuti potenzialmente dannosi. Ad esempio, implementare controlli di "input validation" e regole per il filtraggio del contenuto può aiutare a ridurre il rischio di input malevoli.


Anche l'adozione di un approccio chiamato "human-in-the-loop" può contribuire alla sicurezza. Questo approccio prevede che alcune azioni ad alto rischio richiedano la conferma di un operatore umano prima di essere eseguite, limitando così la possibilità che un prompt malevolo porti a conseguenze gravi. In aggiunta, la segregazione dei contenuti esterni e l'identificazione chiara di quali dati provengano da fonti non fidate riducono ulteriormente l'impatto potenziale di un attacco di prompt injection.


Infine, testare il modello in maniera regolare attraverso simulazioni di attacco e tecniche di penetrazione può aiutare a individuare falle nei controlli di sicurezza prima che vengano sfruttate. Questi test dovrebbero trattare il modello come un utente non affidabile, al fine di valutare l'efficacia dei confini di fiducia e dei controlli di accesso.

 

Sensitive Information Disclosure (OWASP Top 10 LLM)

La vulnerabilità di Divulgazione di Informazioni Sensibili si verifica quando un modello linguistico gestisce dati personali o riservati senza adeguati controlli di sicurezza. Questo problema può avere gravi conseguenze, soprattutto quando le informazioni vengono inavvertitamente divulgate durante l'interazione con il modello o a causa di cattive pratiche di gestione dei dati di addestramento. La natura di questi modelli, addestrati su vaste quantità di dati, può portare a situazioni in cui dettagli privati vengono inaspettatamente rivelati se i dati non sono stati adeguatamente filtrati.


Uno dei casi più comuni di divulgazione di informazioni sensibili riguarda la fuga di informazioni personali identificabili (PII), come nomi, indirizzi, numeri di telefono e altri dettagli sensibili. Per esempio, in contesti in cui un LLM viene utilizzato per assistenza clienti, potrebbe inavvertitamente rivelare dati personali di un altro utente se non sono presenti adeguati controlli di accesso. Questa situazione può verificarsi quando il modello è stato addestrato utilizzando dati non completamente anonimizzati o quando le informazioni vengono memorizzate senza le adeguate misure di protezione.


Un altro rischio significativo è l'esposizione di algoritmi proprietari o dettagli interni di un'organizzazione. Ad esempio, un modello utilizzato per risolvere problematiche aziendali potrebbe accidentalmente rivelare informazioni riservate su algoritmi o metodologie proprietarie, esponendo l'azienda a potenziali rischi di sicurezza e perdita di vantaggio competitivo. Questo tipo di divulgazione può verificarsi non solo per errori nella gestione degli output, ma anche a causa di attacchi mirati che sfruttano vulnerabilità nei prompt o nei dati di addestramento.


Per mitigare questi rischi, è fondamentale adottare tecniche di sanitizzazione dei dati durante il processo di addestramento, garantendo che qualsiasi dato personale o sensibile venga rimosso o mascherato. La sanitizzazione deve essere eseguita non solo sui dati utilizzati per l'addestramento, ma anche sugli input forniti dagli utenti in tempo reale. Inoltre, l'adozione di tecniche di apprendimento federato può ridurre la necessità di trasferire dati sensibili a un singolo luogo centralizzato, diminuendo così il rischio di esposizione.


L'implementazione di controlli di accesso basati sul principio del minimo privilegio è un'altra misura chiave per prevenire la divulgazione di informazioni sensibili. Questo approccio implica che il modello abbia accesso solo alle informazioni strettamente necessarie per svolgere il suo compito, limitando così la possibilità che informazioni riservate vengano elaborate o divulgate erroneamente. Un'altra tecnica utile è l'uso della differential privacy, che aggiunge "rumore" ai dati per garantire che le informazioni specifiche dell'utente non possano essere ricostruite dai risultati generati dal modello.


Educare gli utenti sull'uso sicuro degli LLM è altrettanto importante. Gli utenti devono essere consapevoli dei rischi legati all'inserimento di dati sensibili e devono ricevere linee guida su come interagire con il modello in modo sicuro. Ad esempio, i termini di utilizzo del servizio dovrebbero chiarire che i dati inseriti potrebbero essere utilizzati per migliorare il modello, e dovrebbe essere fornita la possibilità di escludere i propri dati dall'addestramento.


Infine, è essenziale configurare correttamente il sistema per evitare che informazioni riservate siano inserite nei prompt di sistema o negli output generati dal modello. La sicurezza dell'infrastruttura deve essere garantita seguendo best practice come quelle definite dall'OWASP, tra cui la configurazione sicura delle API e il mascheramento dei messaggi di errore per evitare fughe di informazioni critiche.

 

Supply Chain Vulnerabilities (OWASP Top 10 LLM)

Le vulnerabilità nella catena di fornitura delle applicazioni basate su LLM rappresentano un rischio significativo, poiché possono compromettere l'integrità dei modelli, dei dati di addestramento e delle piattaforme di distribuzione. Queste vulnerabilità possono insorgere da una varietà di elementi esterni, come modelli pre-addestrati o componenti software di terze parti. L'utilizzo di modelli pre-addestrati disponibili pubblicamente, per esempio, comporta un rischio intrinseco poiché tali modelli potrebbero contenere bias o addirittura backdoor malevoli, introducendo debolezze difficili da individuare.


Un aspetto critico è l'uso di modelli obsoleti che non sono più aggiornati o mantenuti. L'adozione di modelli o componenti software non supportati rappresenta una falla di sicurezza comune, simile a quelle descritte in altre aree della sicurezza informatica (come la gestione di software non aggiornati), ma con un impatto potenzialmente molto maggiore, dato l'uso pervasivo degli LLM in contesti critici. Se un modello non viene aggiornato, le vulnerabilità scoperte possono essere sfruttate da attori malevoli, portando a possibili violazioni dei dati o attacchi di sistema.


Un altro rischio riguarda i metodi di "fine-tuning" basati su tecniche come il Low-Rank Adaptation (LoRA). Sebbene queste tecniche consentano un'adattabilità più efficiente e il miglioramento delle performance dei modelli, esse introducono anche nuovi rischi. Un attaccante potrebbe sfruttare vulnerabilità in questi adattamenti per comprometterne l'integrità, manipolando il modello di base a livello di singolo componente e inserendo comportamenti indesiderati. Ad esempio, un LoRA adapter malevolo potrebbe essere caricato da una fonte non verificata, compromettendo l'intero sistema.


Inoltre, i processi di sviluppo collaborativo e di fusione dei modelli, come quelli ampiamente adottati su piattaforme come Hugging Face, rappresentano una superficie di attacco notevole. Le piattaforme di condivisione di modelli sono spesso vulnerabili a compromissioni dovute a errori di configurazione o controlli di sicurezza non adeguati. Attacchi di tipo model tampering potrebbero includere la modifica diretta dei parametri di un modello per inserire backdoor o bias non rilevabili durante l'utilizzo comune.


Per mitigare questi rischi, è fondamentale mantenere un inventario accurato e aggiornato di tutti i componenti utilizzati nella catena di fornitura, utilizzando strumenti come il Software Bill of Materials (SBOM), che consente di verificare la provenienza e la sicurezza dei componenti software e dei modelli pre-addestrati. Questo permette di individuare rapidamente eventuali vulnerabilità note e di valutare la sicurezza complessiva del sistema.


L'implementazione di pratiche di AI Red Teaming, ovvero l'impiego di team specializzati che simulano attacchi per individuare vulnerabilità, può rivelarsi estremamente efficace per testare la resistenza di modelli e componenti alle minacce reali. È altrettanto importante monitorare e verificare costantemente la sicurezza degli ambienti di sviluppo collaborativo, introducendo meccanismi di auditing che permettano di rilevare tempestivamente eventuali anomalie o abusi.


Infine, la creazione di una politica di aggiornamento e patching costante per i componenti utilizzati nei modelli è cruciale per garantire che ogni vulnerabilità venga risolta nel minor tempo possibile, limitando così il rischio di esposizione a possibili exploit. L'uso di tecniche di cifratura dei modelli, soprattutto per quelli distribuiti su dispositivi locali, e l'integrazione di controlli di integrità, può prevenire la manomissione dei modelli e limitare l'accesso non autorizzato.

 

Data and Model Poisoning (OWASP Top 10 LLM)

Il Data e Model Poisoning si verifica quando i dati utilizzati per l'addestramento del modello vengono manipolati per introdurre vulnerabilità, bias, o addirittura per compromettere deliberatamente il modello. Questo tipo di attacco può influire negativamente sulle prestazioni del modello, portando a decisioni errate o comportamenti inattesi. Uno dei principali rischi è che i dati di addestramento, soprattutto quelli provenienti da fonti esterne, possano contenere informazioni maligne che alterano la capacità del modello di fare previsioni accurate. Questo è particolarmente vero quando i modelli vengono addestrati su dataset non verificati o su dati raccolti da ambienti pubblici, dove gli attaccanti possono facilmente iniettare contenuti avversariali.


Ad esempio, un attaccante potrebbe manipolare il dataset inserendo esempi specifici progettati per insegnare al modello a comportarsi in modo errato in determinate situazioni. Questo tipo di attacco, noto come inserimento di backdoor, può lasciare il modello apparentemente normale fino a quando non si attiva uno specifico trigger che ne altera il comportamento. Un attacco del genere potrebbe consentire all'attaccante di bypassare misure di sicurezza o manipolare direttamente le risposte del modello.


Per mitigare questi rischi, è fondamentale implementare misure di tracciabilità dei dati. Utilizzare strumenti come il Machine Learning Bill of Materials (ML-BOM) aiuta a tenere traccia dell'origine e delle trasformazioni dei dati lungo tutto il ciclo di vita del modello. La validazione dei dati è altrettanto importante: ogni dato dovrebbe essere sottoposto a un processo rigoroso di verifica prima di essere utilizzato per l'addestramento, soprattutto se proviene da fonti esterne o collaborative.


Un'altra strategia efficace è l'utilizzo del data version control (DVC) per monitorare ogni cambiamento nei dataset. Questo aiuta a rilevare eventuali manipolazioni dei dati e a mantenere l'integrità dell'intero processo di sviluppo del modello. Inoltre, l'implementazione di tecniche di apprendimento avversariale consente di preparare il modello a resistere agli attacchi, migliorandone la robustezza rispetto a perturbazioni malevole.


Un ulteriore passo per prevenire l'avvelenamento del modello consiste nell'adottare il sandboxing per limitare l'esposizione del modello a dati non verificati. Creare un ambiente isolato in cui testare i nuovi dati prima di utilizzarli effettivamente nell'addestramento riduce il rischio di compromettere il modello. Infine, l'utilizzo di tecniche di monitoraggio e rilevamento delle anomalie durante il processo di addestramento permette di identificare comportamenti inattesi del modello che potrebbero indicare la presenza di dati avvelenati.

 

Improper Output Handling (OWASP Top 10 LLM)

La gestione impropria degli output generati dai modelli LLM può esporre le applicazioni a una vasta gamma di vulnerabilità, inclusi attacchi di tipo esecuzione di codice remoto (RCE), cross-site scripting (XSS) e SQL injection. Questo problema si verifica quando l'output prodotto dal modello viene utilizzato senza adeguata validazione o sanitizzazione. Essendo gli LLM sistemi che generano testo basato su input potenzialmente non verificati, essi possono essere sfruttati per introdurre comandi malevoli che vengono poi eseguiti da componenti successivi della catena applicativa.


Per esempio, un output del modello che viene inserito in un sistema shell senza essere verificato potrebbe permettere a un attaccante di eseguire comandi arbitrari, compromettendo l'intero sistema. Analogamente, query SQL generate dall'LLM e utilizzate per accedere a database senza una corretta parametrizzazione potrebbero portare a vulnerabilità di tipo SQL injection, consentendo l'accesso non autorizzato ai dati. Nei contesti web, l'output non sanificato che viene mostrato in un browser può risultare in attacchi di cross-site scripting (XSS), dove l'attaccante introduce script malevoli che vengono eseguiti dal browser dell'utente.


Per mitigare questi rischi, è fondamentale trattare ogni output generato dal modello come potenzialmente pericoloso, applicando rigorose pratiche di validazione e sanitizzazione. L'adozione di controlli di contesto, come l'encoding dell'output in base all'ambiente di destinazione (HTML, SQL, JavaScript), è una misura essenziale per garantire che i contenuti generati non possano essere utilizzati in modo dannoso. L'uso di query parametrizzate per tutte le operazioni di database riduce il rischio che input non verificati possano alterare le operazioni previste. Inoltre, l'implementazione di Content Security Policy (CSP) può limitare l'impatto degli attacchi XSS impedendo l'esecuzione di script non autorizzati.


L'utilizzo di sistemi di logging e monitoraggio avanzati può aiutare a rilevare comportamenti anomali negli output generati dai modelli. Ad esempio, monitorare costantemente il contenuto generato dall'LLM e identificare pattern sospetti può fornire un ulteriore livello di sicurezza, consentendo interventi rapidi in caso di rilevazione di attività malevole. È altresì importante definire limiti di frequenza e quote di utilizzo per prevenire abusi, specialmente in contesti dove il modello ha accesso a funzionalità critiche o risorse sensibili.


In definitiva, garantire una corretta gestione degli output significa adottare un approccio di "zero trust" nei confronti dei contenuti generati, trattando il modello come un possibile vettore di attacco e implementando tutte le salvaguardie necessarie per proteggere i sistemi downstream da possibili compromissioni.


Excessive Agency (OWASP Top 10 LLM)

Il concetto di Excessive Agency fa riferimento all'autonomia eccessiva concessa a un modello linguistico di grandi dimensioni (LLM), che può portare il modello stesso a compiere azioni critiche senza un'adeguata supervisione umana. LLM con eccessiva autonomia possono prendere decisioni o eseguire operazioni che sono al di fuori del loro ambito previsto, potenzialmente causando danni o violazioni della sicurezza. Questo rischio è reso più critico dalla crescente diffusione di architetture basate su agenti, dove un LLM è utilizzato come punto decisionale per svolgere varie azioni.


Nel contesto di un'applicazione LLM, l'autonomia può includere la capacità del modello di invocare funzionalità di sistema, di accedere a risorse esterne o di comunicare con altre parti di un sistema senza conferma umana. Questa capacità può essere utile per automatizzare attività, ma allo stesso tempo introduce vulnerabilità quando il controllo delle azioni non è sufficientemente limitato.


Un esempio comune di eccessiva autonomia riguarda un LLM utilizzato come assistente per la gestione delle e-mail, che potrebbe avere accesso non solo alla lettura delle e-mail ma anche all'invio e alla cancellazione delle stesse. Questo tipo di accesso espone il sistema a un rischio significativo, soprattutto se un attaccante riesce a manipolare l'LLM attraverso prompt malevoli o dati esterni compromessi. Se il modello non è progettato per richiedere una conferma umana prima di eseguire determinate operazioni, un attacco potrebbe portare all'invio di e-mail non autorizzate o alla cancellazione di informazioni critiche.


Un altro esempio può essere rappresentato dall'utilizzo di plugin o estensioni non necessari che aumentano la gamma di funzionalità disponibili per un LLM. Se un modello è abilitato a interagire con un sistema di gestione file, e questa estensione permette sia la lettura che la modifica dei file, il rischio è che un comportamento non voluto o un attacco indirizzato possa portare alla modifica o alla cancellazione di dati sensibili. I plugin con funzionalità estese, non strettamente necessarie all'operazione prevista, rappresentano un vettore di rischio perché offrono ulteriori punti di accesso che possono essere sfruttati.


Un problema correlato è l'eccesso di permessi. Molto spesso, gli LLM sono configurati per operare con privilegi eccessivi, consentendo loro di accedere a funzionalità o risorse che non sono essenziali per le loro operazioni. Ad esempio, un'estensione che deve semplicemente leggere i dati di un database potrebbe essere configurata con permessi di scrittura, modifica o eliminazione, creando una superficie di attacco più ampia. Questo tipo di configurazione errata rende il sistema vulnerabile non solo a possibili attacchi, ma anche a errori che possono derivare da comportamenti imprevisti del modello.


Per mitigare il rischio di eccessiva autonomia, è essenziale adottare un approccio che minimizzi le estensioni e le funzionalità disponibili per l'LLM. Le estensioni dovrebbero essere limitate alle sole operazioni strettamente necessarie, riducendo così la capacità del modello di compiere azioni dannose. È fondamentale applicare il principio del minimo privilegio, garantendo che ogni estensione o plugin operi con i privilegi più bassi possibili, necessari solo per la specifica operazione prevista. In questo modo, anche se il modello dovesse essere compromesso, le azioni che potrebbe compiere sarebbero fortemente limitate.


Inoltre, l'implementazione di meccanismi di human-in-the-loop è cruciale per garantire che tutte le azioni ad alto impatto richiedano la conferma di un operatore umano prima di essere eseguite. Ad esempio, se un LLM è utilizzato per generare contenuti da pubblicare sui social media, la pubblicazione finale dovrebbe sempre essere approvata manualmente da un operatore umano per evitare errori o abusi.


Infine, è importante implementare un monitoraggio continuo delle attività del modello, registrando tutte le operazioni eseguite e identificando eventuali comportamenti anomali. Questo tipo di logging può aiutare a rilevare rapidamente attività sospette e a rispondere in modo efficace. Inoltre, l'adozione di limiti di rate e di restrizioni sul numero di azioni che un LLM può compiere in un dato intervallo di tempo aiuta a prevenire abusi e a limitare l'impatto di eventuali compromissioni.


Il rischio di Excessive Agency è quindi strettamente legato alla gestione delle capacità e dei permessi concessi agli LLM. Un'architettura ben progettata, che adotti misure di mitigazione come il principio del minimo privilegio, la supervisione umana per le azioni critiche, e un monitoraggio continuo delle attività, può ridurre significativamente l'esposizione a questo tipo di vulnerabilità, garantendo che l'LLM operi sempre entro limiti sicuri e controllati.

 

System Prompt Leakage (OWASP Top 10 LLM)

La vulnerabilità del System Prompt Leakage riguarda il rischio che i prompt di sistema, ossia le istruzioni utilizzate per guidare il comportamento del modello, possano contenere informazioni sensibili che non sono destinate a essere divulgate. I prompt di sistema sono progettati per fornire al modello le direttive necessarie per generare output adeguati, ma potrebbero involontariamente includere dati riservati o critici. Quando queste informazioni vengono scoperte, esse possono essere utilizzate per facilitare altri tipi di attacchi, creando così un pericolo significativo per la sicurezza del sistema.


Un esempio comune di System Prompt Leakage si verifica quando i prompt contengono credenziali di accesso, chiavi API, o dettagli di configurazione che dovrebbero rimanere segreti. Se un attaccante riesce a estrarre questi prompt, può sfruttarli per accedere non autorizzato alle risorse del sistema, con conseguenze potenzialmente molto gravi. Un caso specifico riportato nella ricerca OWASP del 2025 mostra come, in diversi contesti aziendali, siano state involontariamente esposte informazioni come la struttura dei permessi interni o i limiti delle transazioni finanziarie di un utente, aumentando così il rischio di attacchi di tipo privilege escalation o bypass dei limiti di sicurezza.


Inoltre, la vulnerabilità del System Prompt Leakage può rivelare criteri di filtraggio interni utilizzati per impedire al modello di fornire risposte sensibili. Ad esempio, un prompt di sistema potrebbe contenere istruzioni come: “Se un utente richiede informazioni su un altro utente, rispondi sempre con ‘Spiacente, non posso assisterti con questa richiesta’”. Se un attaccante riuscisse a visualizzare questo prompt, potrebbe sfruttarlo per aggirare le misure di sicurezza e manipolare il comportamento del modello in modi indesiderati.


Per mitigare il rischio di System Prompt Leakage, è fondamentale separare i dati sensibili dai prompt di sistema ed evitare di includere qualsiasi tipo di informazione critica direttamente in essi. È preferibile gestire le informazioni riservate attraverso sistemi esterni al modello, assicurandosi che il modello non abbia accesso diretto a tali dati. Un altro approccio efficace consiste nell'implementare guardrail esterni al modello: mentre il training per comportamenti specifici può essere utile, non garantisce che il modello seguirà sempre le istruzioni, soprattutto in situazioni di attacco. Un sistema indipendente che verifichi gli output per garantire la conformità alle aspettative è preferibile rispetto alle sole istruzioni del prompt di sistema.


Una strategia di mitigazione cruciale è garantire che i controlli di sicurezza siano applicati in modo indipendente dall'LLM. Ciò significa che i controlli critici, come la separazione dei privilegi e la verifica delle autorizzazioni, devono essere eseguiti in modo deterministico e verificabile, e non dovrebbero mai essere delegati al modello. Ad esempio, se un agente LLM svolge compiti che richiedono diversi livelli di accesso, dovrebbero essere utilizzati più agenti, ciascuno configurato con i privilegi minimi necessari per svolgere il proprio compito, riducendo così il rischio di esposizione accidentale di dati sensibili.


In sintesi, il rischio legato al System Prompt Leakage non riguarda semplicemente la divulgazione dei prompt stessi, ma piuttosto la presenza di dati sensibili o di autorizzazioni eccessive all'interno di questi. Implementare controlli esterni robusti e limitare il contenuto dei prompt a informazioni non sensibili sono passi essenziali per proteggere l'integrità e la sicurezza delle applicazioni basate su LLM.

 

Vector and Embedding Weaknesses (OWASP Top 10 LLM)

Le debolezze negli embedding e nei vettori rappresentano un altro importante rischio per la sicurezza degli LLM. Gli embedding sono rappresentazioni numeriche che catturano il significato del testo e sono fondamentali per il funzionamento degli LLM. Tuttavia, queste rappresentazioni possono essere sfruttate per manipolare il modello o estrarre informazioni sensibili, specialmente se non sono protette da adeguati controlli di sicurezza.


Una delle principali vulnerabilità riguarda l'inversione degli embedding, un tipo di attacco in cui un attaccante sfrutta i vettori di embedding per ricostruire informazioni sensibili originariamente incluse nei dati di addestramento. Questo processo di inversione può rivelare dettagli privati degli utenti o dati proprietari utilizzati per addestrare il modello, compromettendo così la privacy. Un esempio concreto riportato nella ricerca OWASP del 2025 mostra come un attaccante sia riuscito a recuperare informazioni personali, quali nomi o indirizzi, analizzando i vettori di embedding generati da un LLM non adeguatamente protetto.


Inoltre, gli embedding possono diventare vulnerabili a causa di controlli di accesso insufficienti. In sistemi che utilizzano tecniche di Retrieval-Augmented Generation (RAG), le informazioni contenute nei vettori possono essere richiamate e combinate con nuove query, creando il rischio di una fuga di dati sensibili tra diversi utenti o contesti di utilizzo. Ad esempio, in ambienti multi-tenant, un errore nella separazione logica delle richieste potrebbe far sì che un utente riceva informazioni relative a un altro utente, generando un problema di riservatezza.


Per mitigare questi rischi, è essenziale implementare controlli di accesso granulari che limitino l'utilizzo degli embedding a contesti sicuri e verificati. Gli embedding dovrebbero essere gestiti in modo che l'accesso sia strettamente controllato e autorizzato solo per specifici scopi. Inoltre, tecniche come la cifratura dei dati negli embedding possono contribuire a prevenire il rischio di inversione e fuga di informazioni. È altrettanto importante stabilire delle rigide politiche di validazione dei dati per garantire che le informazioni utilizzate per creare gli embedding siano pulite e provengano da fonti affidabili.

Un ulteriore passo verso la mitigazione consiste nel monitorare continuamente l'uso degli embedding e delle risorse di RAG, mantenendo un registro dettagliato delle attività di accesso. Questo permette di rilevare tempestivamente comportamenti anomali che potrebbero indicare tentativi di manipolazione o di accesso non autorizzato. Il monitoraggio può essere abbinato a tecniche di anomaly detection per identificare rapidamente possibili attacchi e mitigare il loro impatto.


In sintesi, le debolezze negli embedding e nei vettori rappresentano una sfida significativa per la sicurezza degli LLM. Implementare controlli di accesso rigorosi, cifrare i dati, e monitorare costantemente l'attività sono tutte misure fondamentali per proteggere questi elementi critici e garantire la sicurezza e la riservatezza delle applicazioni basate su LLM.

 

Misinformation (OWASP Top 10 LLM)

La disinformazione rappresenta uno dei rischi più critici nell'uso degli LLM, in quanto i modelli possono generare contenuti apparentemente accurati ma completamente errati o fuorvianti. Questo rischio è amplificato dalla capacità degli LLM di produrre risposte che suonano credibili ma sono basate su dati errati o interpretazioni sbagliate. La disinformazione può portare a violazioni della sicurezza, danni alla reputazione e persino conseguenze legali, soprattutto in contesti in cui l'affidabilità delle informazioni è cruciale, come la sanità, la finanza o il diritto.


Uno dei principali problemi alla base della disinformazione è il fenomeno delle allucinazioni, ovvero la capacità del modello di "inventare" risposte laddove mancano dati concreti. Quando l'LLM non ha informazioni precise su un determinato argomento, può riempire i vuoti con dati generati statisticamente, che sembrano accurati ma sono in realtà inventati. Ad esempio, nella ricerca OWASP del 2025 sono stati documentati casi in cui modelli LLM hanno fornito riferimenti legali inesistenti o dettagli sanitari che non avevano alcuna base scientifica. Questo tipo di disinformazione può indurre gli utenti a prendere decisioni sbagliate, con conseguenze potenzialmente dannose.


Un altro problema correlato è l'eccessiva fiducia che gli utenti possono riporre nei contenuti generati dagli LLM. Poiché le risposte appaiono spesso molto sicure e dettagliate, gli utenti tendono a non verificarne l'accuratezza, integrando informazioni errate nei processi decisionali senza un controllo adeguato. Questo può essere particolarmente rischioso in contesti sensibili. Ad esempio, un chatbot medico che fornisce informazioni scorrette potrebbe causare danni alla salute di un paziente, e un modello utilizzato in ambito finanziario potrebbe indurre a prendere decisioni economiche disastrose.


Per ridurre il rischio di disinformazione, una strategia efficace è l'uso del Retrieval-Augmented Generation (RAG), che consente al modello di accedere a fonti di informazioni aggiornate e verificate durante la generazione delle risposte. Questo approccio riduce il rischio di allucinazioni, poiché le risposte si basano su dati concreti piuttosto che sulla generazione statistica. Inoltre, è importante integrare la supervisione umana nei processi decisionali, soprattutto in ambiti critici: verificare manualmente le informazioni generate dal modello può migliorare l'accuratezza complessiva e ridurre la diffusione di contenuti errati.


Un'altra tecnica di mitigazione è l'affinamento del modello tramite il fine-tuning e l'uso di embedding che migliorano la qualità delle risposte. L'applicazione di tecniche come la parameter-efficient tuning (PET) e il chain-of-thought prompting può contribuire a ridurre significativamente l'incidenza della disinformazione, poiché permette al modello di eseguire ragionamenti più strutturati e di verificare la coerenza delle informazioni generate.

Infine, è fondamentale educare gli utenti sui limiti degli LLM e sull'importanza della verifica indipendente dei contenuti generati. Fornire formazione specifica agli utenti, soprattutto in contesti sensibili, aiuta a evitare un'eccessiva fiducia nei contenuti generati dal modello e a sviluppare un approccio più critico nell'utilizzo di queste tecnologie.


In conclusione, la disinformazione rappresenta una vulnerabilità centrale per gli LLM, ma può essere mitigata con un approccio multidimensionale che combina l'uso di fonti esterne, la supervisione umana, l'affinamento continuo del modello e l'educazione degli utenti. Solo attraverso un controllo rigoroso e una verifica costante è possibile ridurre al minimo i rischi associati alla diffusione di informazioni errate da parte di questi modelli.

 

Unbounded Consumption (OWASP Top 10 LLM)

La Unbounded Consumption si riferisce al rischio che un LLM utilizzi risorse computazionali in modo incontrollato, con possibili conseguenze di denial of service o costi operativi elevati. Gli LLM, soprattutto quelli ospitati in ambienti cloud con modelli di pagamento "pay-per-use", possono essere vulnerabili a utilizzi eccessivi e non autorizzati, portando a costi insostenibili per l'organizzazione che li gestisce.


Un esempio comune di questo rischio è il cosiddetto Denial of Wallet (DoW), in cui un attaccante sfrutta il sistema di pagamento a consumo per generare richieste continue e costose verso il modello, causando un aumento significativo dei costi per il servizio. Questo tipo di attacco non solo può danneggiare economicamente l'organizzazione, ma può anche avere conseguenze operative, limitando la disponibilità del servizio per gli utenti legittimi. Nella ricerca del 2025 sono riportati casi specifici in cui il costo operativo di un'azienda è cresciuto esponenzialmente a causa di un attacco di tipo DoW, evidenziando come questo possa rappresentare una minaccia finanziaria significativa.


Un'altra situazione tipica di Unbounded Consumption si verifica quando gli utenti inviano ripetutamente input molto complessi o sequenze lunghe, causando un utilizzo sproporzionato delle risorse del modello. In questi casi, il sistema può diventare lento o addirittura smettere di rispondere a causa dell'eccessiva pressione computazionale. Un esempio potrebbe essere l'utilizzo di richieste linguisticamente intricate che richiedono un'elaborazione significativa, risultando in un utilizzo inefficiente della CPU e della memoria.


Per mitigare questi rischi, è fondamentale implementare limiti di frequenza e quote di utilizzo che regolino il numero massimo di richieste che possono essere effettuate da un singolo utente in un determinato periodo di tempo. In questo modo si può prevenire l'abuso delle risorse e garantire una distribuzione equa delle capacità computazionali tra gli utenti. La ricerca OWASP sottolinea l'importanza di limitare l'esposizione dei logits e di altre informazioni sensibili durante le interazioni API, riducendo così le potenziali vie di attacco per sfruttare il modello.


Un altro approccio efficace è il monitoraggio continuo delle risorse, che consente di rilevare utilizzi anomali e rispondere rapidamente in caso di comportamenti sospetti. Sistemi di allarme e rate limiting possono essere configurati per intervenire in automatico qualora l'utilizzo del modello superi determinate soglie, garantendo così che le risorse rimangano sempre entro limiti gestibili.


Infine, è utile considerare l'implementazione di tecniche di degrado controllato del sistema. In presenza di carichi eccessivi, il sistema può essere progettato per mantenere una funzionalità parziale piuttosto che andare incontro a un arresto completo. Ciò garantisce che almeno alcuni servizi rimangano operativi anche durante attacchi o sovraccarichi significativi, riducendo così l'impatto negativo sull'esperienza dell'utente finale.


Questi approcci multidimensionali sono fondamentali per affrontare il rischio di Unbounded Consumption nelle applicazioni LLM e per garantire la continuità del servizio, la sostenibilità economica e la sicurezza operativa delle implementazioni basate su questi modelli.


Conclusioni

La crescente integrazione dei modelli linguistici di grandi dimensioni (LLM) nei processi aziendali e nei servizi al pubblico ha portato a una maggiore attenzione verso la loro sicurezza, evidenziando la necessità di affrontare nuove vulnerabilità. Questi rischi, pur essendo tecnici, hanno profonde implicazioni strategiche per le imprese, soprattutto in termini di fiducia, reputazione, compliance e sostenibilità economica. La comprensione delle vulnerabilità identificate nel report OWASP Top 10 LLM del 2025 consente di sviluppare prospettive uniche e di esplorare strategie innovative per mitigare i rischi, massimizzando il valore derivato da queste tecnologie avanzate.


Un elemento chiave emerso è che le vulnerabilità non si limitano alla tecnologia in sé, ma spesso derivano dall’interazione tra modelli, dati e processi aziendali. Ad esempio, il problema del “Prompt Injection” non è solo una sfida tecnica, ma mette in discussione l’affidabilità del modello come strumento decisionale. Quando un modello può essere manipolato attraverso input malintenzionati, le aziende devono ripensare la loro fiducia nei risultati generati e costruire ecosistemi più resilienti. Adottare approcci come il “human-in-the-loop” non è solo una misura di sicurezza, ma diventa una scelta strategica per bilanciare automazione e controllo umano, preservando la qualità delle decisioni in scenari critici.


La “Divulgazione di Informazioni Sensibili” sottolinea invece come il confine tra innovazione tecnologica e tutela della privacy sia fragile. Le imprese non possono più considerare la sicurezza dei dati come un requisito tecnico separato, ma devono integrarla nelle loro strategie di governance. Questo implica la costruzione di sistemi che vadano oltre la semplice anonimizzazione, abbracciando concetti come la privacy differenziale e l'apprendimento federato. Tali approcci non solo riducono i rischi, ma offrono un vantaggio competitivo in un contesto in cui la fiducia dei consumatori è un asset strategico.


Le vulnerabilità nella catena di fornitura evidenziano come la sicurezza dell’AI dipenda da reti complesse di fornitori e partner. L’affidamento a modelli pre-addestrati o componenti di terze parti introduce rischi sistemici che richiedono una gestione proattiva. Le imprese devono iniziare a considerare la sicurezza della supply chain di modelli come parte integrante della loro strategia di gestione dei rischi, adottando strumenti come il Software Bill of Materials (SBOM) per garantire trasparenza e controllo.


La “disinformazione” rappresenta una vulnerabilità dalle conseguenze strategiche più ampie, in quanto mina non solo la credibilità della tecnologia, ma anche quella delle imprese che la utilizzano. Le aziende devono affrontare questa sfida abbracciando un modello di accountability nei confronti degli utenti finali. Ciò significa non solo implementare sistemi di verifica e supervisione, ma anche educare il pubblico a comprendere i limiti della tecnologia. Questa consapevolezza può trasformare un rischio reputazionale in un’opportunità per rafforzare la fiducia.


Infine, il rischio di “Unbounded Consumption” sottolinea come l’adozione di modelli LLM non sia solo una questione di innovazione tecnologica, ma anche di sostenibilità economica. La gestione inefficiente delle risorse può trasformarsi rapidamente in un problema finanziario, rendendo essenziale per le aziende implementare meccanismi di monitoraggio e controllo. Inoltre, il concetto di “denial of wallet” introduce una nuova prospettiva sui costi dell’AI, spingendo le organizzazioni a considerare soluzioni architetturali che bilancino prestazioni e protezione.


Le aziende che vogliono sfruttare il potenziale degli LLM devono adottare una visione integrata che vada oltre la sicurezza tecnica, abbracciando un approccio strategico che consideri le implicazioni di fiducia, governance, resilienza e sostenibilità economica. Questo richiede di ripensare l’intero ciclo di vita dell’implementazione, dal design alla gestione operativa, per costruire sistemi che non siano solo sicuri, ma anche allineati agli obiettivi di business e capaci di rispondere alle sfide future.

 


7 visualizzazioni0 commenti

Post recenti

Mostra tutti

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page