Revisar código generado por IA: qué mirar antes de que toque dinero, datos o accesos

Antes de que un código generado por IA toque dinero, datos personales o accesos, hay que revisar siete cosas: quién puede hacer qué, dónde están los secretos, qué dependencias entran, qué se valida, qué se registra, qué pasa cuando algo falla y quién responde después. No es una auditoría completa: es el mínimo para no publicar un agujero.

La IA escribe código inseguro igual de rápido que código correcto. Tu trabajo no es teclear menos; es juzgar mejor.

Esta pieza cierra el bloque que empieza en qué es el vibe coding y sigue en de prototipo con IA a producción. Aquí va lo concreto: qué abrir, qué buscar y en qué orden.

¿Por qué el código generado necesita otro tipo de revisión?

Porque falla en un sitio distinto al que estamos acostumbrados a vigilar.

Un modelo casi nunca comete errores de sintaxis. Lo que produce compila, arranca y hace lo que le pediste. Donde falla es en las decisiones que no le pediste explícitamente: si esa consulta debería filtrar por usuario, si ese endpoint debería estar protegido, si ese valor debería venir del cliente o calcularse en el servidor, si esa librería es la correcta o una con nombre parecido.

Hay un detalle que lo agrava: el modelo escribe con el mismo tono de seguridad en los dos casos. No hay una señal en el código que diga “esto lo he improvisado”. Y el prompt tampoco ayuda, porque nadie escribe “hazme un panel de administración, y por cierto, que un usuario no pueda ver los pedidos de otro”. Se da por supuesto. El modelo no supone.

Por eso la revisión no es leer línea a línea buscando fallos. Es ir a los sitios donde se toman decisiones de confianza y comprobar cada una.

¿Qué es OWASP y por qué usarlo de guion?

OWASP es una fundación sin ánimo de lucro dedicada a la seguridad del software, y su Top 10 es la lista de referencia de las categorías de riesgo más críticas en aplicaciones web. Es pública, gratuita y está mantenida por la comunidad.

La edición vigente es el OWASP Top 10:2025 (consultada en septiembre de 2026), con estas categorías:

Uso esta lista como guion de revisión por una razón práctica: está ordenada por lo que de verdad aparece en aplicaciones reales, no por lo que suena más grave. Y resulta que las tres primeras son exactamente donde una app generada con IA suele estar más floja.

No hace falta cubrir las diez para una revisión de prototipo. Sí las que siguen.

1. Control de acceso: ¿quién puede hacer qué? (A01)

El primero de la lista, A01:2025 Broken Access Control, y el que más veces encuentro mal.

Qué comprobar:

• ¿Dónde se decide el permiso? Si la única comprobación es que el botón no se pinta, no hay permiso. Busca cada ruta de la API y comprueba que valida la sesión y el rol antes de hacer nada.
• Cambiar el identificador. Coge una URL con un id (/pedidos/1042) y prueba con el id de otro usuario desde una cuenta distinta. Si devuelve datos, tienes un agujero de manual.
• Consultas sin filtro de propietario. Busca en el código las consultas a tablas con datos de clientes y comprueba que todas filtran por el usuario o la organización de la sesión.
• Reglas a nivel de base de datos. Si la base de datos se consulta desde el navegador, las políticas de fila son obligatorias. La documentación de Supabase lo dice literalmente: “una tabla en un esquema expuesto sin RLS es legible y escribible por cualquier rol que tenga permiso sobre ella” (consultado en septiembre de 2026).
• Rutas administrativas. Los paneles de administración generados suelen quedar accesibles por URL directa. Pruébalo desde una sesión normal y desde ninguna sesión.

La prueba que lo resume todo: crea dos cuentas de usuario distintas con datos distintos, e intenta con cada una llegar a los datos de la otra. Por URL, por API, por lo que sea. Si lo consigues, no se publica.

2. Secretos y configuración (A02)

A02:2025 Security Misconfiguration. Barato de revisar, caro de ignorar.

• Claves en el navegador. Abre las herramientas de desarrollo, busca en el código que se descarga cadenas como sk_, api_key, secret, token. Una clave de servicio ahí es una brecha, no un descuido.
• Variables de entorno. En muchos frameworks, cualquier variable con cierto prefijo acaba en el bundle del cliente. Comprueba cuáles llevan ese prefijo y por qué.
• Modo depuración apagado en producción, y mensajes de error que no devuelvan trazas internas ni consultas SQL al usuario.
• CORS que no permita cualquier origen.
• Cabeceras de seguridad básicas puestas.
• Endpoints de prueba y datos de ejemplo eliminados. Las apps generadas dejan usuarios de demo con contraseñas obvias con una frecuencia sorprendente.

3. Dependencias: qué ha metido el modelo en tu proyecto (A03)

A03:2025 Software Supply Chain Failures subió mucho en esta edición, y con la generación automática tiene todo el sentido.

• Revisa el fichero de dependencias entero. Cada paquete que hay ahí es código de un tercero ejecutándose en tu producto.
• Comprueba que cada paquete existe y es el que crees. Los modelos a veces citan nombres plausibles pero equivocados, y ese hueco lo aprovecha quien registra ese nombre con contenido malicioso.
• Vulnerabilidades conocidas: pasa una auditoría de dependencias y trata lo crítico antes de publicar.
• Versiones fijadas con su fichero de bloqueo, para que un despliegue no traiga una versión distinta de la que probaste.
• Paquetes abandonados: si la última publicación es de hace años y toca autenticación o pagos, cámbialo.

4. Validación de entradas (A05)

A05:2025 Injection. El código generado suele usar consultas parametrizadas por defecto, que es buena noticia, pero hay que confirmarlo.

• Consultas SQL construidas concatenando texto: busca cualquier sitio donde una variable se pegue dentro de una consulta.
• Validación en el servidor, no solo en el formulario. Todo lo que llega del cliente es sospechoso, incluidos los campos ocultos.
• Contenido de usuario que se pinta en HTML sin escapar.
• Ficheros subidos: tipo comprobado de verdad, tamaño limitado, y guardados fuera de la raíz pública.
• Si hay una IA dentro del producto que recibe texto del usuario y luego actúa (llama a herramientas, consulta la base de datos), esa entrada es una superficie de ataque más, no menos.

5. Lógica de negocio: el punto ciego (A06)

A06:2025 Insecure Design es la categoría que ningún escáner automático va a encontrarte, porque no es un patrón de código: es una regla de tu negocio que falta.

Preguntas que hago siempre:

• ¿El precio se calcula en el servidor o llega desde el navegador?
• ¿Se puede pedir una cantidad negativa, o cero, o un número absurdo?
• ¿Un usuario del plan básico puede llamar directamente al endpoint de la función premium?
• ¿Se puede aplicar el mismo descuento diez veces?
• ¿Qué pasa si alguien pulsa dos veces el botón de comprar? ¿Y si el webhook llega duplicado?
• ¿Se puede llegar al estado final de un flujo saltándose un paso intermedio?
• ¿Qué pasa si el pago falla a mitad del proceso: queda el usuario creado sin acceso, con acceso sin pagar, o nada?

Estas preguntas no salen de una lista genérica: salen de conocer el negocio. Por eso la revisión no se puede delegar entera a una herramienta.

6. Registro y alertas (A09)

A09:2025 Security Logging and Alerting Failures.

• ¿Queda registro de los inicios de sesión, los cambios de permisos, los pagos y las altas y bajas de acceso?
• ¿Los logs guardan datos sensibles que no deberían (contraseñas, tarjetas, tokens)? Eso también es un fallo.
• ¿Hay alerta cuando algo crítico falla, y llega a un sitio que alguien mira?
• ¿Se pueden reconstruir los hechos de un incidente de hace una semana con lo que hay guardado?

7. Qué pasa cuando algo falla (A10)

A10:2025 Mishandling of Exceptional Conditions es nueva en esta edición y encaja como un guante con el código generado, que casi siempre implementa el camino feliz y poco más.

• ¿Qué pasa si el servicio de terceros no responde? ¿Se reintenta? ¿Se reintenta infinitamente?
• ¿Un fallo a mitad de una operación deja datos a medias (usuario creado, pago no registrado)?
• ¿Los errores se capturan y se tragan en silencio? Un catch vacío es un incidente futuro.
• ¿El mensaje de error que ve el usuario le dice algo útil sin contarle cómo está montada la aplicación por dentro?

¿Y los escáneres integrados en las propias herramientas?

Úsalos. Son útiles y ahorran la primera pasada.

Lovable, por ejemplo, incluye un escaneo básico con revisión de políticas RLS, del esquema de base de datos y de dependencias, y uno más profundo con revisión de control de acceso, protección de endpoints y vulnerabilidades a nivel de código.

Y en la misma página deja claro el límite: “estas herramientas ayudan a identificar problemas de seguridad comunes, pero no pueden garantizar una seguridad completa”, no sustituyen “una revisión de seguridad exhaustiva”, y “eres responsable de asegurar que tu app cumple los requisitos de seguridad apropiados para su caso de uso” (documentación de seguridad de Lovable, consultada en septiembre de 2026).

Eso es exactamente lo que hay: un escáner cubre lo que se puede detectar por patrón. Los puntos 5, 6 y 7 de esta lista —lógica de negocio, registro útil y comportamiento ante fallos— siguen siendo humanos.

Cómo pedir esta revisión si no la vas a hacer tú

Si eres responsable de un proyecto y no vas a abrir el código, tu palanca es exigir evidencia. No “¿está seguro?”, que siempre se responde que sí, sino:

1. “Enseñadme la prueba de que el usuario A no puede ver los datos del usuario B.” Una captura de la petición y la respuesta denegada.
2. “Enseñadme el resultado de la auditoría de dependencias.”
3. “¿Dónde está la comprobación de permisos de este endpoint?” Señalando la línea.
4. “¿Qué pasa si el webhook de pago llega dos veces?” La respuesta correcta menciona idempotencia.
5. “¿A qué canal llega la alerta si esto falla un domingo?”

Cinco preguntas. Si las respuestas son vagas, el proyecto no está listo, independientemente de lo bien que se vea la interfaz.

Qué hacer con lo que encuentres

Ordenado por lo que arreglaría primero:

1. Bloqueante: cualquier acceso a datos de otro usuario, cualquier secreto expuesto, cualquier importe calculado en el cliente. No se publica hasta que esté.
2. Antes de usuarios reales: validación en servidor, webhooks idempotentes, límites de peticiones, copias de seguridad.
3. Primeras semanas: logs y alertas completos, dependencias al día, manejo de errores.
4. Continuo: un plan de mantenimiento con responsable, porque las dependencias envejecen solas y las vulnerabilidades se publican después de que lanzaste.

Si al revisar aparece que los permisos hay que rehacerlos enteros y la lógica de negocio vive repartida por la interfaz, ya no estás revisando: estás reconstruyendo. Ese camino, por piezas y sin parar la operación, está en de prototipo con IA a producción y, cuando lo que hay debajo es un stack no-code, en de no-code a software a medida.

¿Quieres una revisión de lo que habéis construido?

Si tenéis una app generada con IA y os la vais a jugar con ella delante de usuarios de un cliente, esta revisión es el paso barato antes del paso caro. La hago sobre lo que ya existe: os digo qué es bloqueante, qué se aprovecha y qué hay que reconstruir, con prioridades y sin adornos. También en white label, para que la agencia siga siendo la cara ante su cliente.

Cuéntame qué habéis construido y con qué. Si después toca levantar la versión sólida, eso es software a medida; si lo que buscáis es tener criterio técnico detrás de forma continuada, es partner tecnológico.