Audit di sicurezza con IA: dimostrare le autorizzazioni in un progetto locale
Trasforma i sospetti dell’IA in prove, una correzione minima e sette test di autorizzazione. Progetto eseguibile e prompt in inglese inclusi.

Inizia qui: a cosa serve la guida
Un’app B2B contiene fatture di aziende diverse. Un utente autenticato cambia ID: può leggere una fattura altrui? Il login non basta. Trasformerai il rischio in regola, revisione IA con prove e test di regressione. Il risultato è una correzione piccola che blocca accessi vietati e mantiene quelli legittimi. Togliere il controllo azienda deve far fallire il test tra clienti; i test non certificano tutta l’app.
Un esempio concreto
La risposta illustra il formato atteso, non un audit della tua applicazione. Segui i passaggi e confronta file, test e risultati reali. Se l’assistente dice soltanto di aver finito, chiedi il risultato concreto, le prove e cosa resta da verificare.
Finding: invoice lookup must enforce the authenticated tenant.
Evidence: exact policy function and the cross-tenant regression case.
Expected: owner in Acme allowed; the same user cannot read Beta data.
Remaining work: verify the actual HTTP route derives identity on the server.L’obiettivo
Usa l’IA per indagare un confine di sicurezza, poi dimostra il comportamento con test. L’esercizio verifica chi può leggere una fattura B2B. È una politica di esempio, non un sistema completo di accesso.
1. Definire il perimetro
Scarica lo ZIP, estrailo in una nuova cartella e aprila. Basta Node.js 22 o successivo: nessuna dipendenza, account o chiave API. Esamina codice tuo o che sei autorizzato a verificare.
2. Eseguire il laboratorio locale
Esegui i comandi. I sette test coprono proprietario, altro membro, amministratore finanziario, accesso tra clienti e identità mancante. La politica corretta li supera. Per osservare una regressione, rimuovi temporaneamente il confronto del cliente in una copia di prova: i test tra clienti dovrebbero fallire.
node --version
node --test lab.test.mjs3. Chiedere prove all’IA
Fornisci all’assistente il primo prompt inglese. Un risultato utile indica codice, attore e accesso vietato. L’autenticazione identifica l’utente; l’autorizzazione decide se può leggere questa fattura.
Act as a security reviewer for this LOCAL training project. Read lab.mjs and
lab.test.mjs before proposing changes. The actor must come from verified server
authentication. Map the invoice owner, tenant boundary and finance_admin exception.
Produce a table: claim, exact file/line, required attacker capability, affected
data, existing test and missing evidence. Separate confirmed findings from
hypotheses. Check same-tenant and cross-tenant cases, anonymous users and missing
fields. Do not assume that a hidden button or an unpredictable ID is authorization.
Do not contact a live service or change files yet.4. Verificare la correzione
Il secondo prompt delimita una correzione locale concordata. Verifica rifiuti e usi legittimi. Una dichiarazione dell’IA sulla sicurezza del codice non è un risultato di test.
Implement only the smallest agreed authorization correction in this local exercise.
Keep the same-tenant owner and finance administrator use cases working. Add a
negative regression case that would fail with the original faulty policy. Run node
--test lab.test.mjs and report the real result, remaining assumptions and diff. Do
not weaken an existing check to make a test pass. In an application, derive identity
and roles from verified server authentication and enforce the policy on every
relevant request. Stop before deployment.5. Applicare al proprio progetto
Nell’app reale identità e cliente devono provenire dall’autenticazione affidabile del server. Aggiungi test degli endpoint che impediscano al JSON ricevuto di scegliere altri utenti o clienti. Documenta separatamente scanner e revisione umana: sette test non certificano l’intera applicazione.
Riferimenti ufficiali
Portalo nel tuo progetto
Scarica i file, conserva la guida o consegna al tuo assistente istruzioni pronte.
Prepara con l’IA
Copia questo prompt inglese nel tuo assistente. Include articolo, file disponibili e passaggi di preparazione.
Mostra il prompt di preparazione
Read this tutorial as reference material:
https://nethanelfitoussi.com/article/ai-security-code-review?lang=en
Goal: apply the documented workflow to my development project.
Read the existing project instructions, inspect the relevant files and explain the smallest useful setup.
Available starter files:
https://nethanelfitoussi.com/api/media/b10c304f-9e50-4c20-8185-b8190a92c5cd.zip
Download and inspect these files in a temporary folder before using them. Do not overwrite existing project instructions.
If I have not supplied a project folder, ask which development project to use. Do not invent a repository URL.
Additional project setup instructions:
Use the downloaded starter lab in a NEW folder. Read README.md and both English prompts first. Run its dependency-free Node.js tests before editing.
Act as a security reviewer for this LOCAL training project. Read lab.mjs and
lab.test.mjs before proposing changes. The actor must come from verified server
authentication. Map the invoice owner, tenant boundary and finance_admin exception.
Produce a table: claim, exact file/line, required attacker capability, affected
data, existing test and missing evidence. Separate confirmed findings from
hypotheses. Check same-tenant and cross-tenant cases, anonymous users and missing
fields. Do not assume that a hidden button or an unpredictable ID is authorization.
Do not contact a live service or change files yet.
Implement only the smallest agreed authorization correction in this local exercise.
Keep the same-tenant owner and finance administrator use cases working. Add a
negative regression case that would fail with the original faulty policy. Run node
--test lab.test.mjs and report the real result, remaining assumptions and diff. Do
not weaken an existing check to make a test pass. In an application, derive identity
and roles from verified server authentication and enforce the policy on every
relevant request. Stop before deployment.
Adapt example paths, commands and acceptance criteria to this repository rather than assuming they match.
Give me a short plan, then make the agreed local changes and run the relevant checks. Report actual results and anything not verified. Stop before credentials, paid services, production changes, push, merge or deployment.

