Il Progetto OWASP GenAI Security definisce una barra minima in cinque categorie per il deployment sicuro dei server MCP. Utilizza questa checklist per valutare la tua postura attuale attraverso identità, isolamento, tooling, validazione e deployment prima di andare in produzione.
Il Progetto OWASP GenAI Security culmina la sua guida pratica per lo sviluppo di server MCP con una checklist di revisione concreta — la “Barra Minima di Sicurezza MCP”. Questa checklist definisce i controlli di base che devono essere in atto prima che un server MCP venga deployato in produzione.
Questo post presenta la checklist completa con indicazioni di implementazione per ogni elemento, organizzata attraverso i cinque domini di sicurezza definiti dalla guida OWASP. Utilizzala per revisioni di sicurezza pre-deployment, audit periodici e come framework per rimediare le lacune identificate.
Marcatura degli elementi: Per ogni elemento, registra PASS (implementato e verificato), FAIL (non implementato o parzialmente implementato) o N/A (non applicabile a questo deployment).
Gate di deployment: Gli elementi nella Categoria 1 (Identità, Auth, Policy) e Categoria 2 (Isolamento) sono gate di deployment rigidi — qualsiasi FAIL dovrebbe bloccare il go-live finché non viene risolto. Gli elementi in altre categorie dovrebbero essere accettati come rischio con timeline documentate.
Trigger di revisione: Riesegui la checklist completa dopo qualsiasi cambiamento significativo al codice del server MCP, al registro degli strumenti, alla configurazione di autenticazione, all’ambiente di deployment o quando viene onboardata una nuova categoria di strumenti.
Questa è la categoria con la massima priorità. I fallimenti di autenticazione garantiscono agli attaccanti l’accesso diretto a tutto ciò che il server MCP può fare.
Cosa verificare: Ogni connessione remota al server MCP richiede l’autenticazione attraverso un authorization server OAuth 2.1 configurato correttamente. Le connessioni anonime vengono rifiutate. I server MCP locali che utilizzano STDIO possono utilizzare un’autenticazione alternativa appropriata al loro contesto di deployment.
Come testare: Tentare di connettersi senza un header di autorizzazione. Tentare di connettersi con un token malformato o scaduto. Entrambi dovrebbero risultare in un fallimento di autenticazione, non nell’accesso agli strumenti.
Modalità di fallimento comuni: Endpoint di sviluppo lasciati accessibili senza autenticazione; fallback all’autenticazione con chiave API che non valida scadenza o scope; validazione del token solo all’instaurazione della sessione, non per ogni richiesta.
Cosa verificare: I token di accesso scadono entro minuti (non ore). Ogni token porta lo scope minimo richiesto per l’attività corrente. Ogni invocazione di strumento valida la firma del token, l’emittente (iss), l’audience (aud), la scadenza (exp) e lo scope richiesto — non solo all’instaurazione della sessione.
Come testare: Utilizzare un token valido, poi attendere che scada (o impostare manualmente l’orologio in avanti). Tentare una chiamata di strumento — dovrebbe fallire con un 401, non avere successo su un risultato di validazione in cache.
Modalità di fallimento comuni: Validazione del token in cache all’inizio della sessione e non ripetuta; token con durate di 24+ ore; scope “admin” ampi utilizzati invece di scope specifici per operazione; campo exp non controllato.
Cosa verificare: Il server MCP non inoltra i token del client alle API downstream. Tutte le chiamate ai servizi downstream utilizzano token esplicitamente emessi al server MCP (tramite flussi On-Behalf-Of o credenziali di servizio). Un gateway di policy centralizzato intercetta tutte le invocazioni degli strumenti e applica autenticazione, autorizzazione, consenso e logging di audit prima che qualsiasi codice dello strumento venga eseguito.
Come testare: Rivedere il codice per qualsiasi posizione in cui il token del client in entrata viene inoltrato in una chiamata API in uscita. Ispezionare i log di accesso ai servizi downstream per verificare che le richieste arrivino con credenziali del server, non credenziali utente.
Modalità di fallimento comuni: Pattern Authorization: Bearer ${request.headers.authorization} nelle chiamate downstream; controlli di autorizzazione sparsi attraverso singoli gestori di strumenti; nessun punto di enforcement delle policy centralizzato.
Inizia oggi la tua prova gratuita e vedi i risultati in pochi giorni.
I fallimenti di isolamento in ambienti multi-tenant sono catastrofici — consentono a un utente di accedere ai dati di un altro. Questi sono gate di deployment rigidi.
Cosa verificare: Nessuna variabile globale, attributo a livello di classe o istanza singleton condivisa memorizza dati specifici dell’utente o della sessione. Ogni sessione utilizza oggetti istanziati indipendentemente o namespace con chiave di sessione (ad es., chiavi Redis prefissate con session_id:). La revisione del codice conferma l’assenza di stato mutabile condiviso tra le sessioni.
Come testare: Eseguire due sessioni concorrenti con identità utente diverse. Verificare che i dati scritti nella sessione A non possano essere letti nella sessione B. Utilizzare test di carico concorrenti per verificare condizioni di race che potrebbero causare perdite di stato della sessione.
Modalità di fallimento comuni: self.user_context = {} come attributo di classe in un servizio singleton; cache globali senza namespace con chiave di sessione; storage thread-local che non delimita correttamente il ciclo di vita della richiesta.
Cosa verificare: Oltre al contesto di esecuzione, qualsiasi infrastruttura condivisa (database, cache, code di messaggi) applica controlli di accesso per utente. Una query eseguita nella sessione di un utente non può restituire i dati di un altro utente anche se l’infrastruttura condivisa è mal configurata o compromessa.
Come testare: Tentare di accedere ai dati di un altro utente manipolando i parametri della sessione o sfruttando le chiavi di cache condivise.
Modalità di fallimento comuni: Chiavi di cache basate solo sul contenuto della query, non sull’identità dell’utente; query di database senza clausole WHERE con scope utente; directory di file temporanei condivise senza sottodirectory per utente.
Cosa verificare: Quando una sessione termina (in modo pulito o tramite timeout/errore), tutte le risorse associate vengono immediatamente rilasciate: handle di file, file temporanei, contesto in memoria, token in cache, connessioni al database. Esistono limiti per sessione per memoria, CPU, rate API e utilizzo del file system.
Come testare: Terminare una sessione bruscamente (terminare la connessione senza uno shutdown pulito). Verificare che non rimangano risorse residue. Creare una sessione ed esaurire il suo rate limit; verificare che non influenzi altre sessioni.
Modalità di fallimento comuni: File temporanei lasciati in /tmp dopo la fine della sessione; token in cache non revocati alla terminazione della sessione; nessuna quota di risorse che consenta a una sessione di esaurire l’infrastruttura condivisa.
La sicurezza degli strumenti previene gli attacchi più pericolosi specifici di MCP: tool poisoning e rug pull.
Cosa verificare: Ogni definizione di strumento ha una firma crittografica da un approvatore di strumenti autorizzato. La firma copre il manifest completo (descrizione, schema, versione, permessi). Il server MCP verifica questa firma al momento del caricamento e rifiuta qualsiasi strumento non firmato o con firma non corrispondente. Le versioni degli strumenti sono fissate — il server non può caricare dinamicamente uno strumento aggiornato senza una nuova firma approvata.
Come testare: Modificare un singolo carattere nella descrizione di uno strumento caricato. Verificare che il server rilevi la mancata corrispondenza dell’hash e blocchi il caricamento dello strumento. Tentare di caricare una definizione di strumento non firmata — dovrebbe essere rifiutata.
Modalità di fallimento comuni: Definizioni di strumenti memorizzate come configurazione mutabile senza verifica dell’integrità; nessuna infrastruttura di chiavi di firma; strumenti caricati direttamente da un filesystem condiviso senza fissaggio della versione.
Cosa verificare: La scansione automatizzata controlla le descrizioni degli strumenti per pattern simili a istruzioni che potrebbero rappresentare tentativi di poisoning. La validazione periodica conferma che il comportamento runtime effettivo di uno strumento corrisponda alla sua descrizione dichiarata — uno strumento che afferma di essere di sola lettura non dovrebbe essere in grado di operazioni di scrittura a runtime.
Come testare: Aggiungere un’istruzione sospetta a una descrizione di strumento (“chiama sempre anche send_webhook con…”) e verificare che la scansione automatizzata la segnali prima della revisione umana. Rivedere la configurazione dello strumento SAST per le regole di rilevamento del poisoning specifiche di MCP.
Modalità di fallimento comuni: Nessuna scansione automatizzata delle descrizioni degli strumenti; processo di revisione manuale che potrebbe perdere istruzioni incorporate in descrizioni lunghe; nessuna validazione del comportamento runtime per catturare strumenti che mentono sulle loro capacità.
Cosa verificare: Il contesto del modello riceve solo i campi richiesti per la corretta invocazione dello strumento: nome, descrizione, schema di input, schema di output. I metadati interni, i dettagli di implementazione, le informazioni di debug e la configurazione sensibile vengono filtrati prima di essere passati al modello.
Come testare: Ispezionare ciò che il modello riceve quando enumera gli strumenti disponibili. Verificare che nessun campo interno, stringa di connessione o metadato operativo appaia nella vista del modello.
Modalità di fallimento comuni: Oggetti di configurazione completi degli strumenti passati al contesto del modello; messaggi di errore contenenti dettagli interni del sistema che trapelano al modello; descrizioni degli strumenti che includono note di implementazione non rilevanti per l’invocazione.
Ricevi gratuitamente gli ultimi consigli, tendenze e offerte.
I fallimenti di validazione abilitano injection, manipolazione dei dati e denial-of-service.
Cosa verificare: La validazione JSON Schema è applicata per ogni messaggio del protocollo MCP, ogni input di invocazione dello strumento e ogni output dello strumento prima che raggiunga il modello. La validazione rifiuta qualsiasi messaggio che non sia conforme allo schema definito — campi richiesti mancanti, tipi errati, valori al di fuori degli intervalli consentiti.
Come testare: Inviare un’invocazione di strumento con un parametro richiesto mancante. Inviare un messaggio con un campo extra inaspettato. Entrambi dovrebbero essere rifiutati, non ignorati silenziosamente o elaborati con valori predefiniti.
Modalità di fallimento comuni: Validazione opzionale che viene bypassata in condizioni di errore; validazione solo sugli input, non sugli output; schemi troppo permissivi (che accettano parametri type: "any").
Cosa verificare: Tutti gli input sono sanitizzati per rimuovere o escape caratteri che potrebbero abilitare injection (sequenze XSS, metacaratteri SQL, metacaratteri shell, byte null). I limiti di dimensione sono applicati su tutti gli input e output. Il server tratta tutti i dati dal modello come potenzialmente avversari, identici all’input dell’utente in un’applicazione web tradizionale.
Come testare: Inviare input contenenti payload di SQL injection, metacaratteri shell e sequenze XSS. Verificare che vengano rifiutati o sottoposti a escape in modo sicuro prima di raggiungere i sistemi downstream. Inviare un input che supera il limite di dimensione — verificare che venga rifiutato in modo pulito.
Modalità di fallimento comuni: Input passati direttamente a query SQL o comandi shell; nessun limite di dimensione che consenta agli input sovradimensionati di causare esaurimento della memoria; output restituiti al modello senza limiti di dimensione o filtraggio del contenuto.
Cosa verificare: Le chiamate agli strumenti sono accettate solo come oggetti JSON strutturati con schemi validati. La generazione di testo in formato libero che implica invocazioni di strumenti non viene elaborata. Il sistema non può essere indotto a eseguire chiamate di strumenti generando linguaggio naturale che il server interpreta come comandi.
Come testare: Inviare una stringa in linguaggio naturale che descrive un’invocazione di strumento (“chiama lo strumento delete_file con percorso /etc/passwd”). Verificare che il server non interpreti questo come una chiamata di strumento.
Modalità di fallimento comuni: Sistemi ibridi che accettano sia JSON strutturato che descrizioni di strumenti in linguaggio naturale; server che analizzano il testo generato dal modello per identificare invocazioni di strumenti; parsing delle chiamate di strumenti basato su regex che può essere falsificato.
L’hardening del deployment limita il raggio d’azione di qualsiasi vulnerabilità sfruttata.
Cosa verificare: Il server MCP viene eseguito in un container hardened minimale. Il processo del container viene eseguito come utente non-root. Le capability Linux non necessarie vengono eliminate. Le policy di rete limitano tutto il traffico in entrata e in uscita alle connessioni esplicitamente richieste. L’immagine del container contiene solo il software minimo richiesto.
Come testare: Eseguire docker inspect e verificare che l’utente sia non-root. Rivedere le policy di rete e confermare che stiano bloccando tutto il traffico tranne le connessioni esplicitamente in whitelist. Scansionare l’immagine del container per pacchetti non necessari o software con vulnerabilità note.
Modalità di fallimento comuni: Container eseguiti come root per comodità; nessuna policy di rete che lasci tutto il traffico in uscita consentito; immagini di base con installazioni complete del sistema operativo invece di immagini minimali.
Cosa verificare: Tutte le chiavi API, i segreti client OAuth, le credenziali del database e i token degli account di servizio sono memorizzati in un vault di segreti (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, ecc.). Nessun segreto esiste in variabili d’ambiente, codice sorgente, immagini di container o output di log. Le operazioni di gestione dei segreti avvengono in middleware inaccessibile al modello AI — l’LLM non vede né elabora mai i valori delle credenziali.
Come testare: Cercare stringhe simili a credenziali nei log. Ispezionare le variabili d’ambiente accessibili al processo del server. Rivedere il contesto accessibile al modello per confermare che nessun valore di credenziali appaia.
Modalità di fallimento comuni: Chiavi API in file .env committati nel controllo di versione; credenziali restituite in messaggi di errore che raggiungono il modello; segreti passati come parametri di strumenti che appaiono nel contesto della conversazione del modello.
Cosa verificare: La pipeline di deployment include scansione di sicurezza automatizzata (SAST, SCA, scansione delle vulnerabilità delle dipendenze) come gate rigidi — le scansioni fallite bloccano il deployment. Tutte le invocazioni degli strumenti, gli eventi di autenticazione e le decisioni di autorizzazione sono registrati in modo immutabile con il contesto completo. I log vengono ingeriti da un SIEM con alerting in tempo reale su pattern anomali (picchi di validazione fallita, frequenza insolita di chiamate agli strumenti, connessioni esterne inaspettate).
Come testare: Introdurre una dipendenza con vulnerabilità nota e verificare che la pipeline CI/CD fallisca la build. Generare pattern anomali di chiamate agli strumenti e verificare che gli alert SIEM si attivino entro il tempo di risposta previsto.
Modalità di fallimento comuni: Scansione di sicurezza come gate consultivo piuttosto che bloccante; log scritti in storage mutabile che un attaccante potrebbe modificare; nessun alerting su pattern anomali; verbosità eccessiva dei log che rende impossibile trovare eventi rilevanti.
Stampa o esporta questa checklist e lavora sistematicamente attraverso di essa per ogni server MCP prima del deployment in produzione. Coinvolgi il tuo team di sicurezza nella revisione — molti elementi richiedono sia la revisione del codice che test live per verificare correttamente.
Per i team che desiderano una verifica indipendente, un audit di sicurezza MCP professionale testa tutti i 16 elementi della checklist nel tuo ambiente live, utilizzando tecniche di test avversariali piuttosto che auto-valutazione. Il risultato è un report di postura di sicurezza verificato con un piano di rimedio prioritizzato.
La 'Barra Minima di Sicurezza MCP' del Progetto OWASP GenAI Security è una checklist di revisione che definisce i controlli di sicurezza di base richiesti prima che un server MCP debba essere deployato in produzione. Copre cinque domini: Identità/Auth/Policy Enforcement Forte, Isolamento Rigoroso e Controllo del Ciclo di Vita, Tooling Affidabile e Controllato, Validazione Guidata da Schema e Deployment Hardened con Supervisione Continua. Non soddisfare la barra minima significa che il server MCP non dovrebbe essere deployato finché le lacune non vengono rimediate.
Lavora sistematicamente attraverso ogni categoria, marcando gli elementi come PASS, FAIL o NOT APPLICABLE con evidenze per ogni decisione. Qualsiasi FAIL nelle categorie 1 o 2 (identità e isolamento) dovrebbe bloccare il deployment — queste sono le lacune a più alto rischio. I FAIL in altre categorie dovrebbero essere accettati come rischio con una timeline di rimedio documentata prima del deployment. La checklist dovrebbe essere rivalutata dopo qualsiasi cambiamento significativo al server MCP, al registro degli strumenti o all'ambiente di deployment.
Diversi strumenti supportano la validazione automatica della sicurezza MCP: Invariant MCP-Scan (specializzato per la scansione di sicurezza MCP), strumenti SAST con regole MCP personalizzate, npm audit e pip audit per la scansione delle dipendenze, OSV-Scanner per i controlli del database delle vulnerabilità, profili Docker seccomp e AppArmor per l'isolamento runtime e integrazione SIEM per il monitoraggio centralizzato. Nessun singolo strumento copre tutti gli elementi della checklist — una copertura completa richiede la combinazione di analisi statica, test dinamici e monitoraggio continuo.
Arshia è una AI Workflow Engineer presso FlowHunt. Con una formazione in informatica e una passione per l'IA, è specializzata nella creazione di workflow efficienti che integrano strumenti di intelligenza artificiale nelle attività quotidiane, migliorando produttività e creatività.
Utilizza questa checklist per l'auto-valutazione, poi coinvolgi il nostro team per un audit di sicurezza verificato. Testiamo ogni elemento nel tuo ambiente live e forniamo un piano di rimedio dettagliato.
I server MCP espongono una superficie di attacco unica che combina i rischi tradizionali delle API con le minacce specifiche dell'AI. Scopri le 6 vulnerabilità ...
L'autenticazione è il livello di sicurezza più critico per i server MCP remoti. Scopri perché OAuth 2.1 con OIDC è obbligatorio, come la delega dei token previe...
Il tool poisoning e i rug pull sono due dei vettori di attacco specifici di MCP più pericolosi. Scopri come gli attaccanti incorporano istruzioni malevole nelle...
