# Prompt maestro de corrección autónoma — VibeScan > **Cómo usar este archivo:** abrí tu asistente de código (**Claude Code, Codex, Cursor, Grok, Gemini, Copilot**, etc.) **dentro de este repositorio** y pegá o adjuntá este archivo completo como instrucción. Está escrito para que lo ejecute **de corrido, sin frenar por etapas ni preguntas**. --- ## Instrucciones para el agente de IA **ROL.** Sos un ingeniero senior de seguridad y arquitectura de software. Trabajás de forma **autónoma** sobre este repositorio. **MODO DE EJECUCIÓN (obligatorio).** - Ejecutá **todo** el trabajo de abajo en **una sola pasada continua**, de principio a fin. - **No te detengas** a pedir confirmación, **no hagas preguntas**, **no esperes aprobación** entre pasos ni entre fases. - Ante una ambigüedad, tomá la decisión **más segura y estándar**, anotala en `CHANGES.md` y **seguí**. - No pidas permiso para editar archivos, crear tests o actualizar dependencias: **hacelo**. - Única razón válida para frenar: que el repo no compile desde el inicio por algo ajeno a esta lista. En ese caso, arreglá lo mínimo para compilar y seguí. **OBJETIVO — definición de "terminado".** Cuando termines, cualquier ingeniero senior o IA especialista que revise este código debe poder afirmar que la **arquitectura, la estructura y la seguridad son impecables**. Como mínimo: - **Cero** hallazgos abiertos de la lista de abajo (corregidos **de raíz**, no cosméticos). - Sin secretos en el código ni en el bundle del cliente; los expuestos, **rotados** (dejá nota de cuáles). - **Control de acceso** verificado en cada endpoint (pertenencia / tenant); entradas **validadas**, salidas **escapadas**. - **Dependencias** sin CVEs conocidos (actualizadas a la versión corregida), lockfile regenerado. - **Tests** que cubren los flujos críticos; cada bug corregido deja un test que lo vuelve imposible. - **CI** que corre lint + typecheck + tests + build + escaneo de secretos/dependencias y **bloquea** merges rotos. - **Estructura** clara por capas, sin God files, con límites respetados y código muerto eliminado. **PASOS (hacelos todos, en orden, sin frenar).** 1. Leé la estructura del repo y **confirmá cada hallazgo contra el código real** antes de tocarlo. 2. Corregí **todos** los hallazgos de abajo, en orden **P0 → P1 → P2**. Causa raíz, no síntoma. 3. Por cada corrección de fondo, agregá/actualizá un **test** que falle antes del fix y pase después. 4. **Ordená la arquitectura**: separación por capas, nombres consistentes, dividí archivos gigantes, centralizá configuración y manejo de errores, borrá código muerto. 5. **Endurecé la seguridad transversal**: headers de seguridad, validación de entrada (p.ej. zod), autorización por recurso, secretos sólo del lado servidor, rate-limiting donde haga falta, CORS restrictivo. 6. **Actualizá** las dependencias vulnerables a su versión corregida y regenerá el lockfile. 7. Si falta, agregá **CI** (lint, typecheck, test, build, escaneo de secretos y dependencias) que bloquee merges rotos; agregá `.env` a `.gitignore` y dejá un `.env.example`. 8. Corré la **verificación final** (abajo). Si algo falla, arreglalo y volvé a correrla hasta que **todo** pase. 9. Escribí **`CHANGES.md`**: qué cambiaste por hallazgo, qué secretos rotar manualmente y qué decisiones tomaste ante ambigüedades. **VERIFICACIÓN FINAL (todo tiene que quedar en verde).** - Instalación limpia (p.ej. `npm ci`). - Lint y type-check sin errores. - Test suite completa en verde, incluidos los tests nuevos. - Build de producción exitoso. - Repaso de la lista: **cada** hallazgo cerrado, con el porqué. - Búsqueda de secretos en el árbol y en el build: **cero**. **ENTREGA FINAL (imprimí al terminar).** - Resumen de cambios por prioridad. - Lista de hallazgos cerrados (todos) y los tests que los cubren. - Acciones manuales pendientes (p.ej. rotar tal clave en tal proveedor). - Resultado de la verificación final (comandos corridos y salida resumida). --- ## Hallazgos a corregir (10) — informe de VibeScan sobre `acme/tienda-online` ### P0 (3) P0.1 — Stripe Live Secret Key expuesto al navegador (A05:2021 Security Misconfiguration, CWE-798) Dónde: src/components/Checkout.tsx:42 Qué: Una clave secreta de Stripe está incrustada en código que se envía al navegador. Cualquiera que abra tu app puede leerla y cobrar o reembolsar en tu nombre. Cómo: Rotá la clave YA (asumila comprometida). Movela a una variable de entorno del lado servidor y cobrá desde un endpoint/BFF; nunca la referencies en el cliente. Comandos: # rotar la clave en el dashboard de Stripe && git rm --cached .env P0.2 — Inyección SQL confirmada (error-based) (A03:2021 Injection, CWE-89) Dónde: https://tienda-online.com/api/products?q=1%27%22 Qué: Confirmamos que el buscador permite manipular la base de datos. Un atacante podría leer o borrar datos de todos tus clientes. Cómo: Usá consultas parametrizadas / prepared statements. Nunca concatenes entrada del usuario en SQL. P0.3 — lodash@4.17.11 — CVE-2021-23337 (A06:2021 Vulnerable & Outdated Components) Dónde: package.json Qué: La librería lodash que usás tiene una vulnerabilidad conocida (inyección de comandos). Ya existe versión corregida (4.17.21). Cómo: Actualizá lodash a 4.17.21 o superior. Corré tests y build para confirmar que no rompe nada. Comandos: npm install lodash@4.17.21 ### P1 (2) P1.1 — XSS confirmado (ejecución en el navegador) (A03:2021 Injection, CWE-79) Dónde: https://tienda-online.com/buscar?search=… Qué: Confirmamos que un atacante puede ejecutar JavaScript en el navegador de tus usuarios a través del buscador (robo de sesión, acciones en su nombre). Cómo: Escapá/encodeá la salida según contexto; para HTML dinámico usá DOMPurify. Sumá una CSP estricta. P1.2 — IDOR: pedido accedido por id sin chequeo de pertenencia (A01:2021 Broken Access Control, CWE-639) Dónde: src/app/api/orders/[id]/route.ts:18 Qué: Se trae un pedido usando el id de la URL sin verificar que sea del usuario que pide. Otro usuario podría ver pedidos ajenos cambiando el número. Cómo: Filtrá siempre por el dueño: where: { id, userId: session.user.id }. Verificá pertenencia antes de responder. ### P2 (5) P2.1 — Faltan headers de seguridad (4) (A05:2021 Security Misconfiguration, CWE-693) Dónde: https://tienda-online.com/ Qué: La app no envía varias cabeceras de seguridad. Facilita clickjacking y otros ataques desde el navegador. Cómo: Configurá CSP restrictiva, X-Frame-Options DENY, nosniff y HSTS. P2.2 — Open redirect (A01:2021 Broken Access Control, CWE-601) Dónde: https://tienda-online.com/login?next=https://evil.example/ Qué: El parámetro `next` permite redirigir a cualquier sitio externo. Se usa para phishing con enlaces que parecen tuyos. Cómo: Validá el destino contra una lista blanca de rutas propias; no redirijas a URLs absolutas del usuario. P2.3 — Sin CI: nada impide publicar algo roto (Quality & Architecture) Dónde: (repositorio) Qué: No hay integración continua. Cada cambio se puede publicar sin que nada verifique antes que compila o pasan los tests. Cómo: Agregá un workflow que en cada PR corra install, lint, typecheck, tests, build y escaneo de secretos/dependencias, y bloquee el merge si falla. P2.4 — Sin tests automatizados detectados (Quality & Architecture) Dónde: (repositorio) Qué: No encontramos tests. Cada arreglo puede romper algo sin que nadie se entere hasta que lo sufre un usuario. Cómo: Incorporá tests de los flujos críticos (auth, pagos, acceso a datos). Cada bug corregido deja un test que lo previene. P2.5 — Sin lockfile de dependencias (A08:2021 Software & Data Integrity Failures) Dónde: (repositorio) Qué: No hay archivo que fije las versiones exactas de las librerías; builds no reproducibles y más riesgo de cadena de suministro. Cómo: Generá y commiteá el lockfile. Usá npm ci en CI/despliegue. Comandos: npm install && git add package-lock.json --- _Trabajá de forma autónoma hasta cumplir el OBJETIVO completo. No entregues el control hasta que la VERIFICACIÓN FINAL pase entera._