Checklist di sicurezza Claude Code per controlli rapidi su web app

Cos'è uno spot-check di sicurezza leggero

Uno spot-check di sicurezza leggero è una revisione rapida (spesso 30–60 minuti) pensata per individuare problemi evidenti e ad alto impatto prima di spedire. Non è un audit completo. Pensalo come un giro di controllo sulla sicurezza: si scansionano i percorsi che falliscono più spesso nelle app reali e si cerca prova concreta, non supposizioni.

Questa checklist Claude Code si concentra sulle aree che si rompono più spesso nelle web app di tutti i giorni:

• Assunzioni sull'autenticazione (come si sa chi è l'utente)
• Lacune di autorizzazione (cosa è consentito fare)
• Validazione degli input
• Gestione dei segreti
• Superfici comuni di injection (SQL, esecuzione di comandi, rendering di template, redirect, upload)

Non cerca di dimostrare l'assenza di bug, modellare attori di minaccia complessi o sostituire i test di penetrazione.

“Risultati concreti” significa che ogni problema che registri ha prove che uno sviluppatore può usare immediatamente. Per ogni finding cattura:

• I file esatti e il nome della funzione/handler
• Il comportamento rischioso in una frase
• Un passo di riproduzione minimo (request, payload o percorso di click)
• Perché è importante (impatto) e chi può innescarlo
• Una direzione per una correzione sicura (non una riscrittura completa)

L'AI è un aiuto, non un’autorità. Usala per cercare, riassumere e proporre test. Poi verifica leggendo il codice e, quando possibile, riproducendo con una richiesta reale. Se il modello non riesce a indicare posizioni e passi specifici, tratta l'affermazione come non provata.

Definisci lo scope in 10 minuti

Una revisione rapida funziona solo se restringi l'obiettivo. Prima di chiedere a Claude Code di esaminare qualcosa, decidi cosa vuoi dimostrare oggi e cosa non stai controllando.

Inizia con 1–3 percorsi utente reali in cui gli errori costano denaro, espongono dati o concedono poteri. Buoni candidati sono login, reset password, checkout e schermate di modifica admin.

Poi nomina gli asset che devi proteggere. Sii specifico: account utente, azioni di pagamento, dati personali, operazioni riservate agli admin.

Scrivi anche le tue assunzioni di minaccia in parole semplici. Ti stai difendendo da un utente curioso che clicca, un attaccante esterno con script, o un insider con qualche accesso? La risposta cambia cosa significa “abbastanza buono”.

Infine, definisci pass e fail in modo che lo spot-check finisca con finding concreti, non sensazioni. Regole semplici funzionano bene:

• Pass: ogni azione sensibile mostra un controllo esplicito di authn e authz.
• Fail: qualsiasi endpoint si fida del client per user ID o ruolo.
• Pass: gli input sono validati server-side, non solo nell'interfaccia.
• Fail: segreti appaiono nei log, nelle configurazioni o nel codice client.

Se non riesci a descrivere cosa significa fallire, lo scope è ancora troppo vago.

Prepara il contesto che dai a Claude Code

Uno spot-check funziona solo se il modello guarda nei posti giusti. Raccogli un piccolo bundle di codice e note così che la revisione produca prove, non congetture.

Inizia condividendo il percorso critico per la sicurezza: punti di ingresso delle request e il codice che decide chi è l'utente e cosa può fare. Includi solo abbastanza codice circostante per mostrare come fluisce il dato.

Un bundle pratico di solito include:

• Entry auth: parsing session/JWT, impostazioni cookie, callback di login, middleware di auth
• Routes + handler: controller, metodi RPC, resolver GraphQL, handler di job in background
• Layer dati: query ORM, helper SQL raw, builder di query, migrazioni per tabelle sensibili
• Controlli di policy: controlli ruolo, controlli di proprietà, feature flag, endpoint riservati admin
• Validazione: validator di schema di richiesta, handler di upload file, codice di deserializzazione

Aggiungi qualche riga di note sull'ambiente così le assunzioni sono esplicite: session vs JWT, dove vivono i token (cookie o header), comportamento di reverse proxy o API gateway, worker/cron queue, e qualsiasi endpoint “solo interno”.

Prima di inseguire bug, chiedi un inventario: punti di ingresso, endpoint privilegiati e store dati toccati. Questo evita superfici mancate.

Concorda anche un formato di output che obbliga a risultati concreti. Una semplice tabella funziona bene: Finding, Severità, Endpoint/file interessato, Evidenza (snippet o range di linee), Scenario di sfruttamento, Suggerimento di fix.

Flusso di lavoro passo-passo per una revisione da 30–60 minuti

Timebox:

• 10 minuti per orientarsi
• 15–30 minuti per tracciare i flussi
• 10 minuti per scrivere il rapporto

L'obiettivo non è la copertura perfetta. È un piccolo set di finding testabili.

Tieni l'app aperta mentre leggi. Naviga l'interfaccia e osserva quali request vengono inviate. Le note devono puntare a endpoint specifici, parametri e sorgenti dati.

Un workflow che entra in una sola sessione:

1. Schizza i punti di ingresso e i confini di fiducia. Nota rotte pubbliche, rotte loggate, rotte admin, webhook, upload e callback di terze parti. Segna dove i dati passano da controllati dall'utente a attendibili dal server.
2. Per ogni endpoint importante, scrivi cosa prova l'identità e dove avviene. Se il controllo è un “middleware”, conferma che ogni route lo usa davvero.
3. Fai lo stesso per l'autorizzazione. Scegli un'azione rischiosa (vedere dati di altri utenti, modificare ruoli, esportare, cancellare) e traccia la decisione di permesso fino alla query sul database.
4. Traccia l'input utente fino ai sink. Segui un parametro dalla request a query SQL/ORM, rendering di template, esecuzione di comandi, fetch di URL (SSRF), redirect e percorsi di file.
5. Scansiona i flussi di segreti mentre tracci. Cerca token nei log, nel codice client, nei messaggi di errore, nei dump di ambiente e nelle esportazioni.

Un’abitudine utile: per ogni “sembra a posto”, scrivi cosa faresti per romperlo. Se non riesci a descrivere un tentativo di rottura, probabilmente non l'hai verificato.

Spot-checks di Authn: dimostra chi è l'utente

L'autenticazione è dove l'app decide: “questa richiesta appartiene a questa persona.” Un rapido spot-check non serve a leggere ogni linea. Serve a trovare il punto in cui l'identità viene stabilita, poi controllare scorciatoie e percorsi di failure.

Individua il confine di fiducia: dove l'identità viene creata o accettata? Può essere un cookie di sessione, un token JWT bearer, una API key o mTLS al bordo. Chiedi a Claude Code di indicare il file e la funzione esatti che trasformano “anonimo” in un user id, e di elencare ogni altro percorso che può fare lo stesso.

Controlli Authn da esaminare:

• Identifica tutti i punti di ingresso auth (web login, token API, auth mobile, auth tra servizi) e conferma che convergano in un modello di identità coerente.
• Controlla login e reset password per rate limit, lockout e enumerazione utenti (messaggi di errore o tempi diversi per account esistenti vs inesistenti).
• Ispeziona session e cookie: HttpOnly, Secure, SameSite, scadenza, rotazione al login e al cambio di privilegi, e invalidazione logout (server-side, non solo “elimina cookie”).
• Revisiona MFA e recovery così che il percorso di recupero non sia più debole dell'MFA (per esempio reset via email che aggira MFA).
• Controlla i log degli errori di auth: utili per ops, ma non devono perdere dettagli che aiutano gli attaccanti (no hint “utente esiste”, no dump di token).

Un esempio pratico: se le email di reset restituiscono “account non trovato”, questo è un problema rapido di enumerazione. Anche con un messaggio generico, differenze di timing possono rivelare lo stesso fatto, quindi verifica anche i tempi di risposta.

Spot-checks di Authz: dimostra che l'utente è autorizzato

L'autorizzazione è la domanda che causa più danni quando è sbagliata: “Questo utente può fare questa azione su questa risorsa esatta?” Uno spot-check rapido deve cercare intenzionalmente di infrangere quell'assunto.

Scrivi ruoli e permessi in linguaggio semplice. Mantienilo umano:

• Owner può invitare membri
• Member può modificare il proprio profilo
• Support può vedere dettagli di fatturazione ma non cambiare piano
• Admin può cancellare progetti

Poi verifica che ogni azione sensibile applichi authz sul server, non solo nell'interfaccia. I pulsanti possono essere nascosti, le rotte bloccate nel client, ma un attaccante può comunque chiamare l'API direttamente.

Una scansione rapida che solitamente trova problemi reali:

• Trova endpoint/mutation che creano, cancellano, esportano, cambiano ruoli o accedono a fatturazione
• Per ciascuno, individua il controllo di permesso server-side (non il frontend)
• Cerca ID controllati dall'utente (projectId, userId, orgId) e conferma i controlli di proprietà
• Conferma che i percorsi admin-only falliscano chiusi quando manca il ruolo
• Controlla i confini tenant: orgId/accountId dovrebbero provenire dal contesto di sessione, non solo dall'input della request

L'odore classico di IDOR è semplice: una request come GET /projects/{id} dove {id} è controllato dall'utente, e il server lo carica senza verificare che appartenga all'utente o al tenant corrente.

Un prompt che costringe a una risposta reale:

“Per questo endpoint, mostra il codice esatto che decide l'accesso, e elenca le condizioni specifiche che permetterebbero a un utente di un diverso orgId di accedervi. Se non ce ne sono, spiega perché indicando file e nomi di funzione.”

Validazione degli input: tieni fuori i dati sbagliati

La maggior parte dei problemi rapidi in web app nasce da una lacuna: l'app accetta input che lo sviluppatore non si aspettava. Tratta “input” come qualsiasi cosa che un utente o un altro sistema può influenzare, anche se sembra innocua.

Inizia nominando gli input per l'endpoint che stai controllando:

• Valori di query e path nell'URL
• Campi del body della richiesta (incluso JSON annidato)
• Header (header auth, content-type, forwarded IP)
• Cookie
• Upload di file (nome, dimensione, tipo, metadata)

La validazione dovrebbe avvenire vicino al punto di ingresso dei dati, non in profondità nella business logic. Controlla le basi: tipo (stringa vs numero), lunghezza massima, obbligatorio vs opzionale e formato (email, UUID, data).

Per valori noti come ruoli, stati o direzioni di ordinamento, preferisci una allowlist. È più difficile da bypassare rispetto a “bloccare pochi valori cattivi”.

Controlla anche la gestione degli errori. Se l'app rifiuta input, non rispedire il valore grezzo nella risposta, nei log o nell'interfaccia. È così che piccoli bug di validazione diventano fughe di dati o aiutano l'injection.

Un mini-piano “input malformato” per endpoint rischiosi (login, ricerca, upload, azioni admin):

• Stringhe troppo lunghe (10.000+ caratteri)
• Tipi sbagliati (array invece di stringa)
• Valori enum inattesi
• Caratteri speciali che possono cambiare il significato
• Valori vuoti per campi obbligatori

Esempio: un parametro di sort che accetta qualsiasi stringa può diventare un frammento SQL. Una allowlist come "date" o "price" previene quella classe di errori.

Superfici comuni di injection da esaminare rapidamente

La maggior parte delle revisioni rapide trova problemi negli stessi posti: ovunque l'input utente venga interpretato come codice, query, percorso o URL. Qui si cercano i momenti in cui “l'input attraversa un confine di fiducia”.

Traccia i dati dai punti di ingresso (query params, header, cookie, upload, form admin) a dove finiscono.

Bersagli per una scansione veloce

Cerca questi pattern e richiedi un sito d'uso e un esempio di payload per ciascuno:

• SQL injection: query costruite tramite stringa, ORDER BY dinamici e builder IN (...) che uniscono valori utente
• XSS: rendering HTML, template, anteprime markdown, editor rich text dove si assume “sanitize dopo”
• Command injection: chiamate shell per image processing, strumenti PDF, backup o passi “convert” che passano flag controllati dall'utente
• SSRF: fetch di URL per webhook, preview link, import-from-URL e controlli interni che accettano un URL utente
• Path traversal: endpoint di download file, estrazione di zip e pipeline di upload che poi leggono file per nome

Fai attenzione anche a deserializzazione e template injection. Qualsiasi cosa che parsifica JSON, YAML o stringhe template fornite dall'utente può nascondere comportamento rischioso, specialmente se supporta tipi custom, espressioni o rendering server-side.

Se una funzionalità accetta un URL, un filename o testo formattato, assumi che possa essere abusata finché non dimostri il contrario con percorsi di codice e test.

Gestione dei segreti: trova perdite e storage deboli

I problemi coi segreti sono spesso rumorosi una volta che sai dove guardare. Concentrati su dove i segreti vivono e dove possono essere copiati accidentalmente.

Posti comuni dove i segreti compaiono:

• Variabili d'ambiente e file di configurazione dell'app
• Output CI e log di build (inclusi i log di deploy falliti)
• Bundle client e build mobile (qualsiasi cosa spedita agli utenti)
• Endpoint di debug, pagine di health e strumenti admin
• Pagine di errore, stack trace ed eventi di analytics

Poi forza una risposta concreta: se un segreto è esposto oggi, cosa succede dopo? Un buon sistema ha una strada di rotazione (nuova chiave emessa), revoca (vecchia chiave disabilitata) e modo per ridistribuire velocemente. Se la risposta è “lo cambieremmo più tardi”, trattalo come finding.

Least privilege è un altro risparmio veloce. Gli incidenti peggiorano perché le chiavi hanno permessi troppo ampi. Cerca utenti DB che possono droppare tabelle, token di terze parti che gestiscono account o API key condivise tra ambienti. Preferisci una chiave per servizio, per ambiente, con il minimo set di permessi.

Prompt rapidi per spot-check da incollare in Claude Code:

• “Cerca token hard-coded, password e chiavi private. Elenca i percorsi file esatti e i pattern di stringa che hai trovato.”
• “Trova qualsiasi codice che logga header di request, cookie, env var o oggetti di errore completi. Mostra le linee di log e quali campi sensibili potrebbero apparire.”
• “Controlla se i segreti possono finire in snapshot, export o artefatti di build. Identifica cosa viene catturato e dove è memorizzato.”

Infine, conferma i guardrail: blocca i segreti dal versionamento (pre-commit/CI), e assicurati che backup o snapshot non includano credenziali in chiaro. Se la piattaforma supporta snapshot e rollback, verifica che i segreti siano iniettati a runtime, non bake-ati nelle immagini salvate.

Prompt che costringono a finding concreti (pattern da copiare)

I prompt vaghi ottengono risposte vaghe. Costringi il modello a impegnarsi con prove: posizioni esatte, un tracciamento che puoi seguire, un repro che puoi eseguire e cosa renderebbe falsa l'affermazione.

Usa un pattern alla volta, poi chiedi una revisione dopo che confermi o rifiuti un dettaglio.

• Evidenza a livello di file: “Cerca nel repo auth, sessioni, token e middleware. Nomina i file esatti, le funzioni e gli intervalli di linee coinvolti. Cita gli snippet rilevanti. Se non puoi indicare il codice, scrivi ‘no evidence found’.”
• Traccia dall'input al sink: “Scegli un input controllato dall'utente (header, query, body, cookie). Mostra il flusso di dati passo-passo dall'ingresso a dove viene usato (SQL, HTML, shell, template, redirect, percorso file). Elenca ogni funzione nella catena.”
• Passi di riproduzione: “Fornisci un repro minimo con curl (metodo, forma URL, header, body). Includi il codice di stato atteso e un esempio di risposta di successo/fallimento. Dichiara le assunzioni (ruoli, stato auth).”
• Controllo dei falsi positivi: “Cosa potrebbe smentire questo finding? Elenca 2–3 check: flag di configurazione, ordine dei middleware, validazione allowlist, query parametrizzate, escaping fornito dal framework. Se presenti, spiega perché il rischio cambia.”
• Piccola correzione sicura + test: “Proponi la minima modifica che blocca il problema senza rompere i casi validi. Poi scrivi un test da aggiungere (nome, intento, input, risultato atteso). Se ci sono compromessi, elencali.”

Se l'output è ancora vago, stringi:

“Rispondi solo con: percorso file, nome funzione, linea rischiosa e impatto in una frase.”

Un esempio realistico: trasformare un sospetto in un problema verificato

Gli endpoint di aggiornamento profilo spesso nascondono bug di controllo accessi. Ecco un caso piccolo che puoi percorrere con questa checklist.

Scenario: un endpoint API aggiorna un profilo utente:

PATCH /api/profile?accountId=123 con JSON come { "displayName": "Sam" }.

Chiedi a Claude Code di trovare l'handler, tracciare come viene usato accountId e dimostrare se il server applica il controllo di proprietà.

Quello che emerge spesso:

• Authn: la request richiede sessione o token, quindi sembra protetta.
• Authz: l'handler si fida di accountId dalla query string e aggiorna quell'account senza verificare che corrisponda all'utente loggato.
• Validazione input: displayName viene trimmato, ma accountId non è validato come intero.
• Superficie di injection: la SQL è costruita con concatenazione di stringhe come "... WHERE account_id=" + accountId.

Una buona segnalazione è concreta:

• Severità: Alta (IDOR + possibile SQL injection)
• Evidenza: una richiesta con login valido modifica un altro utente cambiando accountId; la SQL è costruita da input non attendibile
• Fix: ignora accountId dal client, usa l'id dell'utente autenticato sul server; parametrizza la query
• Test: tentare di aggiornare un altro account e aspettarsi 403; rifiutare accountId non numerici

Dopo la patch, ricontrolla velocemente:

• Ritenta la stessa request con un diverso accountId e conferma che fallisce.
• Controlla i log per verificare che il server usi l'id autenticato, non il parametro di query.
• Conferma che la query usa placeholder/parametri, non concatenazione di stringhe.
• Esegui un test negativo per input malformati (lettere, numeri molto grandi).

Trappole comuni che fanno fallire gli spot-check

Il modo più veloce per perdere una vulnerabilità è fidarsi di ciò che l'interfaccia sembra imporre. Un pulsante nascosto o disabilitato non è un controllo di permesso. Se il server accetta comunque la richiesta, chiunque può riprodurla cambiando user ID, ruolo o facendo una chiamata API diretta.

Un altro errore comune è una richiesta vaga. “Fai una revisione di sicurezza” di solito produrrà un rapporto generico. Uno spot-check ha bisogno di scope stringenti (quali endpoint, quali ruoli, quali dati) e di un formato di output rigoroso (nome file, funzione, linea rischiosa, repro minimo).

La stessa regola vale per l'output AI: non accettare affermazioni senza riferimenti. Se un finding non include una posizione di codice concreta e un modo passo-passo per scatenarlo, trattalo come non provato.

Modi rapidi in cui gli spot-check deragliano

Queste trappole ricorrono spesso:

• Assumere “solo admin” perché è una pagina admin, non perché il server lo applica
• Chiedere risultati generali invece di “mostrami la richiesta esatta che bypassa X”
• Accettare “possibile SQL injection” senza il punto di costruzione della query e il percorso di input
• Trascurare punti di ingresso meno ovvi come webhook, job schedulati, strumenti di importazione e azioni admin interne
• Riparare sintomi (aggiungere filtri o regex) mentre manca la validazione o l'autorizzazione alla radice

Se ti ritrovi ad aggiungere filtri per ogni nuovo edge case, fermati. La correzione sta quasi sempre prima e più semplice: valida gli input al confine e rendi i controlli di autorizzazione espliciti e centralizzati così che ogni percorso li usi.

Controlli rapidi da eseguire prima di spedire

Non sostituiscono una revisione completa, ma catturano errori che sfuggono quando tutti sono stanchi. Mantienili focalizzati su quello che puoi provare in fretta: una request che puoi inviare, una pagina che puoi caricare, una riga di log che puoi trovare.

Cinque spot-check rapidi che pagano spesso:

• Attrito Authn: prova 10 login sbagliati di fila. Vedi rate limit, lockout o almeno un rallentamento? Si capisce se un'email esiste da messaggi di errore o timing?
• Authz con swap di ID: scegli una risorsa reale (ordine, fattura, profilo). Cambia l'ID nell'URL, nel body JSON o nelle variabili GraphQL. Ottieni dati che non sono tuoi, anche solo metadata?
• Guardrail sugli input: per campi chiave (email, nome, ricerca, upload) prova stringhe molto lunghe, unicode strani e tipi inaspettati (numero invece di stringa). Applichi limiti di lunghezza e allowlist dove conta?
• Esposizione segreti: cerca nei log recenti e nei bundle client token, API key, JWT o header “Authorization: Bearer”. Controlla anche le pagine di errore. “Era solo in staging” spesso diventa “è stato spedito”.
• Superfici di injection: cerca concatenazioni di stringhe in SQL, filtri, rendering di template, comandi shell o URL di redirect. Se l'input raggiunge uno di questi senza forte validazione, assumi rischio finché non provi il contrario.

Scrivi le prime 3 correzioni che puoi spedire questa settimana, non una wishlist. Esempio: (1) aggiungere rate limiting a login e reset password, (2) imporre controlli di proprietà server-side sull'endpoint "get by id", (3) limitare la lunghezza degli input e rifiutare caratteri inaspettati per il campo di ricerca.

Prossimi passi: integra questa checklist nel tuo flusso di build

Uno spot-check paga solo se i risultati cambiano ciò che spedisci. Tratta questa checklist come un piccolo step ripetibile di build, non una missione di salvataggio una tantum.

Trasforma ogni finding in una voce di backlog difficile da fraintendere:

• Fix: cosa cambierà nel codice o nella configurazione
• Test: come proverai che è risolto (una request, un unit test, un passo QA)
• Owner: una persona responsabile
• Data target: prossima release o una data specifica
• Evidenza: file/endpoint e la request o payload esatti che hanno mostrato il problema

Scegli una cadenza che si adatti al rischio e alla dimensione del team. Per molti team, ogni release è l'ideale. Se le release sono frequenti, fai una revisione da 30–60 minuti mensile e un controllo più breve prima di spedire.

Rendi più semplice la ripetizione creando un pacchetto di prompt riutilizzabile e un template di checklist. Mantieni i prompt focalizzati su output concreti: mostra la route, la guardia, la request che fallisce e il comportamento atteso. Conserva il pacchetto dove il team lavora già per non farlo saltare.

Se costruisci app tramite chat, integra la checklist nella pianificazione. Aggiungi una breve nota sulle “assunzioni di sicurezza” per authn/authz, input e segreti, poi esegui lo spot-check subito dopo la prima versione funzionante.

Piattaforme come Koder.ai (koder.ai) possono adattarsi bene a questa abitudine perché permettono iterazioni veloci mantenendo checkpoint di revisione. Usare snapshot e rollback intorno a cambi rischiosi rende più facile spedire fix di sicurezza senza restare bloccati quando una modifica rompe il comportamento.