Audit application security with AI: prove authorization with a local lab

Start here: why this guide is useful

You run a B2B application with invoices for several companies. A logged-in user changes the invoice ID in a request: can they read another company’s bill? A login check alone cannot answer that. This guide helps you turn that concrete risk into an authorization rule, an AI review with evidence and a regression test. You will learn to separate a confirmed defect from an assistant’s suspicion.

The useful end result is a small, reviewable correction that blocks a forbidden request while keeping the owner’s legitimate access. In this lab, removing the tenant comparison should break a cross-tenant test. That failure explains why the check exists. Passing tests support this policy; they do not certify your entire application.

A concrete example

The following is an illustrative response format, not the result of an audit of your application. Use it to recognise what a useful answer should contain. Follow the detailed steps below, then compare the actual files, tests or output with this target. If the assistant only says “done”, ask for the changed artifact, the evidence and what remains unverified.

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.

The goal

Use AI to investigate one security boundary, then prove the behaviour with tests. This exercise checks who may read an invoice in a B2B application. It is a policy example, not a complete login system.

1. Prepare the scope

Download the ZIP below, extract it into a new folder and open that folder. Node.js 22 or newer is enough; there are no dependencies, accounts or API keys to install. Use only code you own or are authorised to review.

2. Run the local lab

Run the commands below. The kit contains seven tests: owner access, another member, a finance administrator, cross-tenant access and missing identity data. The supplied corrected policy passes them. To see a regression, temporarily remove the tenant comparison in a disposable copy: the cross-tenant tests should fail.

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

3. Ask AI for evidence

Give your assistant the first English prompt. A useful finding names the code, the actor and the forbidden data access. Authentication proves identity; authorization decides whether that identity may access this invoice.

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. Verify the correction

Use the second prompt for an agreed local change. Verify both denied and legitimate requests. An AI statement that the code is secure is not a test result.

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. Apply it to your project

In the real application, get actor and tenant metadata from trusted server authentication. Add endpoint-level tests proving callers cannot choose another user or tenant in request JSON. Record scanner results and human review separately; these seven policy tests do not certify the whole application.

Official references

• 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.