Una squadra di hacker contro la tua app

Cos'è e perché conta

Prima di lanciare un'app fatta con l'AI, la domanda è sempre la stessa: c'è un buco che non vedo? Tu l'app la usi da dentro, con il tuo account, e funziona. Chi la vuole rompere la guarda da fuori.

Claude Security è un plugin ufficiale di Claude Code, e non è un controllo singolo: è una squadra di agenti. Uno disegna la mappa della tua architettura, uno costruisce il modello delle minacce, cioè chi attaccherebbe la tua app, da dove e per prendere cosa, altri cercano le vulnerabilità. Ogni falla trovata la analizzano agenti verificatori indipendenti prima che entri nel report, così il report resta corto e senza falsi allarmi. Alla fine ti prepara le correzioni come patch, e le applichi tu.

Gli hacker sono finti nel senso buono: il plugin legge il tuo codice, nella tua sessione, e non attacca l'app online né il database vero. Serve a chi sta per lanciare un'app con dentro dati di persone.

Lo stato, controllato sulla documentazione ufficiale di Claude Code il 22 ottobre 2026: la pagina del plugin non lo indica come anteprima o beta, e si installa dal marketplace ufficiale di Anthropic. Non confonderlo con il servizio gestito con lo stesso nome, che controlla i repository in continuo: quello è un prodotto a parte, per il piano Enterprise.

1. Cosa ti serve

• Un piano a pagamento di Claude, le API di Anthropic o un provider come Amazon Bedrock, Google Cloud o Microsoft Foundry. La scansione usa i workflow dinamici di Claude Code, uno script che coordina tanti agenti insieme. Sul piano Pro li accendi da /config, alla riga Dynamic workflows.
• Python 3 raggiungibile come python3 (prova con python3 --version). Il plugin usa solo la libreria standard, non installa niente, e se la tua versione è troppo vecchia il suo menu te lo dice.
• Git, per scansionare solo le modifiche e per le patch. La scansione completa funziona anche senza. Va bene Mac, Linux o Windows.

Non c'è una chiave a parte: il plugin non chiama modelli per conto suo, usa la tua sessione, e gli agenti girano sul modello che hai scelto con /model. Ogni scansione conta nel tuo consumo, può usare molti token e vuole Claude Code aperto finché non finisce.

2. Installa il plugin

Nella cartella del progetto avvia Claude Code con claude e scrivi:

/plugin install claude-security@claude-plugins-official

Si apre la scheda del plugin, dove scegli per chi installarlo: per te in tutti i progetti, per tutti quelli del repository o solo per te in questo repository. Se il riepilogo dice «Run /reload-plugins to apply.», scrivi /reload-plugins. Se invece ti dice che il plugin non c'è nel marketplace, aggiorna il catalogo con /plugin marketplace update claude-plugins-official e riprova.

3. Lancia la scansione

1. Scrivi /claude-security e scegli Scan codebase.
2. Il plugin legge il repository e ti propone tutto o una parte, per esempio le API o il login, con il numero di file e il costo relativo di ogni opzione. Se non sai, rispondi «I don't know» e sceglie lui.
3. Conferma: prima non parte niente. Poi lascia Claude Code aperto. Il dettaglio, agente per agente e con i token di ciascuno, lo vedi con /workflows, e da lì puoi anche fermare tutto.

Rende meglio in modalità auto, dove un secondo modello controlla le azioni al posto tuo e gli agenti non ti chiedono il permesso a ogni passo. Su un progetto grande vai una zona alla volta: login, pagamenti, API.

Solo le modifiche, prima di unire

Se lavori su un ramo, il menu ti propone di scansionare solo quello che cambia rispetto alla base; puoi chiedere anche un singolo commit o una tua pull request aperta. Conta solo quello che è già in un commit. Si può chiedere anche a parole:

/claude-security scansiona solo le modifiche del mio ramo

4. Leggi il report

Ogni scansione scrive nel repository una cartella CLAUDE-SECURITY-<data e ora>. È l'unica cosa che cambia nel progetto, e ha il suo .gitignore, così non finisce in un commit per sbaglio. Dentro:

• CLAUDE-SECURITY-RESULTS.md, il report da leggere: ogni falla ha un codice (F1, F2…), l'impatto, uno scenario di attacco, la gravità, quanto è sicura e cosa fare.
• Le stesse falle in .jsonl per i programmi e in .sarif, il formato standard che leggono GitHub code scanning e gli altri strumenti di sicurezza, con la categoria CWE di ogni falla.
• Un timbro, CLAUDE-SECURITY-REVISION-<commit>.json, che dice quale commit è stato scansionato e con che sforzo, così ogni report resta legato al codice che descrive.

Parti dalle falle più gravi e con confidenza alta, e prima di correggere fatti spiegare lo scenario:

Apri il report di Claude Security e spiegami la falla F1 come se non sapessi niente di sicurezza: chi la può sfruttare, cosa ottiene, da quale schermata o indirizzo dell'app passa e quanto è probabile. Dimmi se tocca dati di utenti veri. Non modificare niente.

5. Le correzioni le applichi tu

Scrivi di nuovo /claude-security, scegli Suggest patches e poi le falle. Ogni patch nasce in una copia a parte del repository e la rivede un altro agente, che lancia i test, se ci sono. Arriva solo se chiude quella falla, non ne apre altre e non cambia il resto; se no, ricevi una nota che spiega perché.

Le patch finiscono in patches/ dentro il report, una per falla (F1.patch, F2.patch…), e non vengono mai applicate da sole. Una la applichi dal terminale così:

git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patch

Una patch per pull request, così ognuna si rivede e si prova da sola. Oppure fallo fare a Claude:

Applica la patch F1 del report di Claude Security su un ramo nuovo, lancia i test e apri una pull request solo con quella modifica. Nella descrizione scrivi la falla, la correzione e come l'hai provata.

Se il codice toccato non ha test, la nota della patch lo dice: provala a mano prima di unire. E se nel frattempo quel codice è cambiato, la falla viene saltata e il plugin ti propone una scansione nuova.

6. Le quattro falle tipiche delle app fatte con l'AI

• Il database aperto. Supabase vuole la Row Level Security su ogni tabella esposta: senza, la chiave pubblica che sta nell'app può bastare per leggere e scrivere. Su Firebase cerca allow read, write: if true, che la documentazione dice di non usare mai in produzione. Il test dal vivo: guida PORTA (strikt.fit/porta).
• La chiave segreta nel codice dell'app. Quella di Supabase (secret, o service_role) mai nel browser, in un'app pubblicata o su GitHub. E le variabili VITE_, NEXT_PUBLIC_ ed EXPO_PUBLIC_ finiscono nel codice che arriva al browser o all'app: lì niente chiavi. Guida CHIAVI (strikt.fit/chiavi).
• L'endpoint che non controlla chi chiede. Un endpoint è un indirizzo del server, tipo /api/ordini/123. Il caso classico: controlla il login, ma non che l'ordine 123 sia tuo, così cambi il numero e leggi quello di un altro. È il primo rischio della OWASP API Security Top 10 del 2023. Il controllo va sul server, non nel pulsante nascosto.
• Nessun limite alle richieste. Se un endpoint chiama un'AI o manda email o SMS, chiunque lo chiama mille volte e il conto arriva a te: è il quarto rischio della stessa lista. Guida LIMITE (strikt.fit/limite).

Per una prima occhiata veloce, prima della scansione vera:

Controlla nel codice di questa app le quattro falle classiche delle app fatte con l'AI e per ognuna dimmi file, riga e gravità: 1) tabelle del database senza regole di accesso (Row Level Security su Supabase, regole di sicurezza su Firebase) o con regole che lasciano leggere tutto a chiunque abbia fatto login; 2) chiavi segrete nel codice che arriva al browser o all'app, comprese le variabili NEXT_PUBLIC_, VITE_ ed EXPO_PUBLIC_; 3) endpoint che non controllano chi fa la richiesta e se l'oggetto chiesto è suo; 4) endpoint senza limite di richieste, soprattutto quelli che costano (AI, email, SMS). Non modificare niente e non stampare mai il valore delle chiavi.

È una passata sola, senza i verificatori del plugin. E le regole del database create dal pannello, e non nel codice, non le vedono né questo controllo né il plugin: lì serve il test dal vivo.

Gli errori più comuni

• Partire con tutto un repository grande. La prima volta scegli una zona, tipo login o API, e guarda quanto consuma in /workflows.
• Chiedere la scansione delle modifiche con il lavoro non ancora in un commit. Quella guarda solo i commit.
• Applicare tutte le patch insieme. Una per pull request, ognuna rivista e provata.
• Prendere una scansione pulita per un'app sicura. Le scansioni cambiano da un giro all'altro e leggono il codice, non le impostazioni online: rifalle e fai anche i test dal vivo.
• Togliere dal codice una chiave segreta trovata e fermarsi lì. Va revocata e sostituita, perché resta nella cronologia.

Checklist

• Piano a pagamento o API, workflow dinamici accesi (su Pro da /config).
• python3 e git funzionanti, plugin installato.
• Prima scansione su una zona con dati di persone: login, pagamenti, API.
• Report letto partendo dalle falle più gravi.
• Patch applicate una per pull request, provate a mano quelle senza test.
• Le quattro falle tipiche controllate anche dal vivo.
• Scansione rifatta prima di ogni lancio importante.

Domande frequenti