Auditar seguridad con IA: demostrar la autorización en un proyecto local
Convierte sospechas de la IA en pruebas, una corrección mínima y siete tests de autorización. Incluye proyecto ejecutable y prompts en inglés.

Empieza aquí: para qué sirve esta guía
Una aplicación B2B guarda facturas de varias empresas. Un usuario conectado cambia el ID: ¿puede leer una ajena? El login no basta. Convertirás el riesgo en política, revisión IA con evidencia y test de regresión. El resultado es una corrección pequeña que bloquea accesos prohibidos y conserva al propietario. Quitar la comparación de empresa debe hacer fallar el test entre clientes; pasar no certifica toda la aplicación.
Un ejemplo concreto
La respuesta ilustra el formato esperado, no una auditoría de tu aplicación. Sigue los pasos y compara archivos, tests y salidas reales con el objetivo. Si el asistente solo dice que terminó, pide el entregable, las pruebas y lo pendiente.
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.El objetivo
Usa la IA para investigar una frontera de seguridad y demuestra su comportamiento con tests. El ejercicio comprueba quién puede leer una factura B2B. Es una política de ejemplo, no un sistema completo de acceso.
1. Definir el alcance
Descarga el ZIP, extráelo en una carpeta nueva y ábrela. Basta Node.js 22 o posterior: no requiere dependencias, cuentas ni claves API. Examina código propio o que tengas autorización para revisar.
2. Ejecutar el laboratorio local
Ejecuta los comandos. Hay siete tests sobre propietario, otro miembro, administrador financiero, acceso entre clientes e identidad ausente. La política corregida los supera. Para observar una regresión, elimina temporalmente la comparación de cliente en una copia desechable: los tests entre clientes deberían fallar.
node --version
node --test lab.test.mjs3. Pedir pruebas a la IA
Entrega al asistente el primer prompt en inglés. Un hallazgo útil identifica código, actor y acceso prohibido. Autenticar identifica al usuario; autorizar decide si puede consultar esta factura.
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. Verificar la corrección
El segundo prompt acota una corrección local acordada. Comprueba rechazos y usos legítimos. Que la IA diga que el código es seguro no es un resultado 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. Aplicarlo a tu proyecto
En la aplicación real, identidad y cliente deben venir de autenticación fiable del servidor. Añade tests de endpoint que impidan elegir otro usuario o cliente en el JSON recibido. Documenta por separado escáneres y revisión humana: estos siete tests no certifican toda la aplicación.
Referencias oficiales
Llévalo a tu proyecto
Descarga los archivos, guarda la guía o entrega un encargo listo a tu asistente.
Preparar con IA
Copia este prompt inglés en tu asistente. Incluye el artículo, los archivos disponibles y los pasos de preparación.
Ver el prompt de preparación
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.

