Hay muchas formas en que una app vibe coded termina hackeada. Esto corre 20 chequeos contra las más comunes — las que llegan solas cuando una IA escribe el código y nadie lo lee después.

Apuntas un agente a tu repositorio y trabaja los 20 en orden — secretos en el repo, RLS que falta, IDs predecibles, webhooks sin firma, y el resto — y tiene que enseñarte la línea de código antes de poder llamarle vulnerabilidad a algo.

Esa última parte es el punto completo. Si le preguntas a un agente "¿mi app es segura?", va a encontrar problemas existan o no. Este tiene que probarlo, o marcarlo sin verificar y decirte dónde buscar tú.

La auditoría

Auditoría de seguridad — 20 chequeos. Solo lectura.
Si no señalas la línea del código, no cuenta.

Vas a auditar este código buscando las 20 vulnerabilidades de abajo. Eres
revisor, no reparador. No edites, no refactorices, no "limpies" nada. No abras
un PR. Lo único que produces es un reporte.

REGLAS

1. SI NO SEÑALAS LA LÍNEA DEL CÓDIGO, NO CUENTA. Para decir que algo es
   VULNERABLE tienes que enseñarme el código: la ruta del archivo, el número
   de línea y la línea exacta. Si no puedes señalarla, no lo llames
   vulnerabilidad — el veredicto es SIN VERIFICAR. No adivines por el nombre
   de un archivo, por la reputación de un framework ni por lo que
   "normalmente" pasa.

2. VERIFICA TAMBIÉN LA MITIGACIÓN. Antes de marcar algo, busca lo que lo haría
   seguro: el middleware, el archivo de políticas, el comportamiento por
   defecto del framework, la configuración de la plataforma. Un ORM que
   parametriza por defecto no es inyección SQL. Un framework que escapa por
   defecto no es XSS. Di qué mitigación encontraste y dónde vive.

3. SOLO CUATRO VEREDICTOS, uno por chequeo:
   VULNERABLE — confirmado, con la línea de código (archivo:línea).
   SEGURO — confirmado que está manejado; nombra la mitigación y dónde está.
   NO APLICA — la funcionalidad no existe aquí (no hay uploads, no hay webhooks).
   SIN VERIFICAR — no se resuelve solo con el código, o no lo pudiste
   confirmar. Di exactamente qué tengo que revisar a mano y dónde (dashboard,
   consola, configuración del proveedor).

4. NUNCA IMPRIMAS EL VALOR DE UN SECRETO. Si encuentras una clave, token o
   contraseña real, reporta el archivo y la línea y solo los primeros 4
   caracteres. Nunca el valor completo, ni en el reporte, ni en un commit.

5. NADA DE RELLENO. Si 14 de 20 están bien, dilo en una línea cada uno. Largo
   no es lo mismo que exhaustivo.

LOS 20 CHEQUEOS

1.  Secretos en el repositorio. ¿Hay un .env o algún archivo de credenciales
    versionado en git? Revisa .gitignore, `git ls-files` y el historial — una
    clave borrada en un commit posterior sigue en el historial y sigue quemada.
2.  Claves de API en el front end. Cualquier clave real accesible desde el
    código cliente o el bundle compilado. Revisa las variables con prefijo
    public/NEXT_PUBLIC/VITE_ y decide una por una si de verdad es publicable o
    si es una clave de servicio que se filtró al cliente.
3.  Row-level security. Si la base de datos es accesible directamente desde el
    cliente (Supabase, Firebase, PocketBase), ¿está RLS o su equivalente
    activo en todas las tablas, y las políticas de verdad limitan las filas al
    dueño? Una política activa que dice "true" es lo mismo que no tener nada.
4.  Autorización solo en el front end. Cualquier chequeo que únicamente
    esconde interfaz — un render condicional, un botón deshabilitado, un guard
    de ruta — sin un chequeo equivalente en el servidor para esa misma acción.
5.  Rate limiting. Login, registro, recuperación de contraseña, OTP, búsqueda y
    todo lo que cuesta dinero (llamadas a IA, correo, SMS). Nombra el limitador
    y dónde aplica. No tener limitador en los endpoints de auth es un hallazgo.
6.  Concatenación de strings en SQL. Cualquier query armada por interpolación o
    concatenación con input del usuario. Incluye los escapes de SQL crudo
    dentro de un ORM, y las cláusulas LIKE y los ORDER BY o nombres de tabla
    dinámicos.
7.  Validación en el servidor. ¿Cada endpoint valida body, query y params del
    lado del servidor — tipos, largos, enums, rangos? La validación en el
    cliente no cuenta. Los tipos solos tampoco cuentan; TypeScript desaparece
    en runtime.
8.  Contenido del usuario renderizado como HTML crudo. dangerouslySetInnerHTML,
    v-html, innerHTML, o un renderizador de Markdown con HTML habilitado y sin
    sanitizador. Nombra el sanitizador si existe.
9.  Almacenamiento de contraseñas. Texto plano, cifrado reversible, MD5, SHA-1
    o SHA-256 sin salt. Busca bcrypt, argon2 o scrypt — o un proveedor de auth
    manejado que nunca te entrega la contraseña.
10. Tokens de sesión en localStorage. Tokens o estado de sesión en localStorage
    o sessionStorage en vez de cookies httpOnly. Di si al mismo tiempo la app
    está expuesta a XSS — las dos cosas juntas son el problema real.
11. Superficies de admin sin protección. Paneles de admin, rutas /debug y /dev,
    dashboards de jobs, playgrounds de GraphQL, documentación de API, studios
    de base de datos. ¿Se llega a ellos en producción sin autenticación?
12. CORS permisivo. Access-Control-Allow-Origin en "*", o reflejando el Origin
    de la petición, sobre todo combinado con credentials: true. Revisa la
    configuración de la app y también la de la plataforma o el CDN.
13. Verificación de correo. ¿Se puede crear y usar una cuenta con un correo sin
    verificar? Di qué puede hacer realmente una cuenta sin verificar.
14. IDs predecibles sin chequeo de pertenencia. IDs secuenciales o adivinables
    en URLs y rutas de API donde el handler busca por ID sin confirmar que el
    registro le pertenece a quien pregunta. Este es el hueco real más común —
    revisa todas las rutas que reciben un ID.
15. Asignación masiva. Handlers que pasan el body completo a un create o un
    update, dejando que quien llama escriba campos que no debería (role,
    is_admin, plan, credits, user_id, price). Busca spreads dentro de llamadas
    al ORM.
16. Verificación de firma en webhooks. Stripe, Clerk, GitHub, Resend, cualquier
    entrada. ¿Se verifica la firma contra el body crudo, antes de parsearlo, y
    con comparación de tiempo constante? Confirma que el body crudo no venga ya
    parseado por un middleware — eso rompe la verificación en silencio.
17. Stack traces y salida de debug en producción. Errores devueltos al cliente
    con stack traces, SQL o rutas internas. Flags de debug, manejadores de
    error verbosos, source maps servidos públicamente.
18. Dependencias sin actualizar. Corre la auditoría del lockfile (npm audit /
    pip-audit / equivalente). Reporta solo high y critical, y solo donde la
    ruta vulnerable sea realmente alcanzable desde esta app. Anota lo que esté
    sin mantenimiento.
19. Fuerza de contraseña y chequeo de filtraciones. Largo mínimo y un chequeo
    contra bases de contraseñas filtradas (HaveIBeenPwned con k-anonymity o
    equivalente) en el registro y en el cambio de contraseña. Un mínimo de 8
    caracteres sin chequeo de filtraciones es un hallazgo.
20. Validación de archivos subidos. Tipo verificado por contenido y no solo por
    extensión o por el MIME que declara el cliente, tamaño limitado, nombre
    saneado, guardado fuera del web root o en object storage, nunca ejecutado, y
    servido con un content type que no se pueda re-interpretar. Revisa también
    el flujo de URLs firmadas si lo tienes.

SALIDA

A. Veredicto en una línea: qué tan mal está y qué es lo primero que hay que
   arreglar.

B. Tabla, ordenada VULNERABLE primero, luego SIN VERIFICAR, luego el resto:
   # | Chequeo | Veredicto | Severidad | Dónde está (archivo:línea)

C. Por cada hallazgo VULNERABLE, en orden de severidad:
   - Qué está mal, en una oración.
   - El código, con archivo:línea.
   - El ataque concreto. Quién hace qué, en qué orden, y qué se lleva. Si no
     puedes escribir esa oración, baja la severidad.
   - El arreglo, descrito. No escribas el parche a menos que te lo pida.

D. Lista de SIN VERIFICAR: exactamente qué tengo que revisar a mano y dónde.

E. Cualquier cosa fuera de estos 20 con la que te tropezaste. Aplica la misma
   regla: si no señalas la línea del código, no cuenta.

Empieza diciéndome qué es la app, cuál es el stack y dónde están los límites de
confianza. Después trabaja los chequeos en orden.

Notas

Reporta, no arregla. Un modelo que encuentra un hueco y lo parcha en la misma pasada te va a decir que arregló cosas que nunca entendió. Lee el reporte primero, y después entrégale un hallazgo a la vez.
"Sin verificar" no es "seguro". Varios de estos — políticas de RLS, CORS en el CDN, dashboards de admin públicos — viven en la consola de un proveedor, no en tu repositorio. El prompt obliga al agente a decirlo en vez de adivinar, y esa lista es la parte que te toca revisar a mano.
El chequeo 14 casi siempre es el que duele. IDs predecibles sin chequeo de pertenencia. La ruta existe, el login funciona, y le entrega a cualquier usuario logueado el registro de otro. Es aburrido, está en todas partes, y es por ahí que la data se va.
Córrelo por repositorio, no por monorepo. El alcance le gana a la ambición. Una pasada enfocada sobre un servicio produce evidencia; un barrido sobre todo produce un resumen.
Va a ver tu código. Úsalo junto con la barrera para agentes de navegador si ese mismo agente tiene acceso a tus dashboards, y recuerda la regla 4: reporta dónde está un secreto, nunca qué dice.

Cuándo usarlo: antes de tu primer usuario real, antes de cobrar el primer pago, y después de cualquier semana en la que publicaste más rápido de lo que leíste.