Auditer la sécurité avec l’IA : prouver les autorisations sur un projet local

Commencer ici : à quoi sert ce guide

Vous gérez une application B2B contenant les factures de plusieurs entreprises. Un utilisateur connecté change l’identifiant de facture dans sa requête : peut-il lire celle d’une autre société ? Vérifier seulement sa connexion ne répond pas à cette question. Ce guide transforme ce risque en règle d’autorisation, revue IA avec preuves et test de non-régression. Vous apprendrez à distinguer défaut confirmé et soupçon de l’assistant.

Le résultat utile est une petite correction vérifiable qui bloque l’accès interdit tout en conservant l’accès du propriétaire. Dans le laboratoire, retirer la comparaison d’entreprise doit faire échouer un test entre clients. Cet échec explique la raison du contrôle. Les tests soutiennent cette politique ; ils ne certifient pas toute votre application.

Un exemple concret

La réponse ci-dessous illustre le format attendu ; elle ne prétend pas auditer votre application. Elle permet de reconnaître une réponse utile. Suivez les étapes détaillées puis comparez fichiers, tests ou sorties réels à cet objectif. Si l’assistant répond seulement « terminé », demandez le livrable modifié, les preuves et ce qui reste à vérifier.

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’objectif

Utilisez l’IA pour examiner une frontière de sécurité, puis prouvez le comportement par des tests. Le laboratoire vérifie qui peut lire une facture dans une application B2B. Ce n’est pas un système de connexion complet.

1. Préparer le périmètre

Téléchargez le ZIP ci-dessous, décompressez-le dans un nouveau dossier et ouvrez ce dossier. Node.js 22 ou supérieur suffit : aucune dépendance, aucun compte ni clé API. Travaillez sur du code qui vous appartient ou que vous êtes autorisé à examiner.

2. Exécuter le laboratoire local

Exécutez les commandes. Le kit contient sept tests : propriétaire, autre membre, administrateur financier, accès entre clients et identité manquante. La politique corrigée fournie les passe. Pour observer une régression, retirez temporairement la comparaison de client dans une copie jetable : les tests entre clients doivent échouer.

node --version
node --test lab.test.mjs

3. Demander des preuves à l’IA

Donnez le premier prompt anglais à votre assistant. Un constat utile précise le code, l’acteur et l’accès interdit. L’authentification établit l’identité ; l’autorisation décide si elle peut consulter cette facture.

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. Vérifier la correction

Le deuxième prompt encadre une correction locale convenue. Vérifiez les refus et les accès légitimes. « Le code est sécurisé » n’est pas un résultat de 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. Appliquer à votre projet

Dans l’application réelle, identité et client doivent venir de l’authentification serveur. Ajoutez des tests d’endpoint montrant que le JSON reçu ne peut pas choisir un autre utilisateur ou client. Documentez séparément scanners et revue humaine : ces sept tests ne certifient pas toute l’application.

Références officielles

• OWASP · Secure Code Review
• OWASP · Authorization

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.