¿Ven sus usuarios datos de otras personas? Revise su prototipo usted mismo

Para vibe coders y fundadores cuyo prototipo hecho con Lovable, Bolt, Cursor o Claude Code ya tiene sus primeros usuarios. Abra el repositorio en la herramienta, pegue el prompt y deje trabajar al agente. Tarda unos 10 minutos.

Hoy la IA escribe todo nuestro código y un senior responde del resultado. Estas seis áreas son lo primero que revisamos en cada prototipo que asumimos.

1. El prompt

El prompt prohíbe al agente cambiar nada y mostrar secretos completos.

Eres un revisor de seguridad. Recorre este repositorio y no cambies nada en él. No ejecutes comandos que escriban algo, desplieguen o se conecten a producción. Si encuentras un secreto (clave, contraseña, token), no lo muestres completo: indica solo el archivo, la línea y los primeros 4 caracteres.

Revisa estas 6 áreas. En cada una escribe ESTADO (OK / PROBLEMA / NO LO SÉ), PRUEBA (archivo y línea, o qué falta) y QUÉ HACER (una frase).

1. Acceso a los datos (RLS): si la aplicación usa Supabase, Firebase o una base de datos similar llamada directamente desde el navegador, ¿tiene cada tabla activado Row Level Security o security rules que dejen al usuario acceder solo a sus propias filas? Enumera las tablas sin reglas y las reglas que dejan pasar a todos.
2. Claves en el código: ¿hay claves, contraseñas o tokens en el repositorio o en el historial de git? ¿Está .env en .gitignore? ¿Hay en el código que se ejecuta en el navegador una clave que no debería estar ahí (clave service role, clave secreta de API, clave de pagos)?
3. Inicio de sesión y permisos: ¿comprueba el servidor en cada ruta de la API quién ha iniciado sesión y si puede acceder a esos datos? Enumera las rutas que devuelven o modifican datos sin comprobación. ¿Se comprueba el rol (por ejemplo admin) en el servidor, o solo ocultando un botón en la interfaz?
4. Dónde se ejecuta: ¿el hosting, la base de datos y el dominio están en una cuenta de la empresa o en la cuenta personal de una sola persona? Busca pistas en la configuración (nombres de proyectos, correos, URL). Si no lo puedes saber por el código, escribe NO LO SÉ y qué debo preguntar.
5. Copias de seguridad: ¿hay una copia de seguridad periódica de la base de datos y está descrito en algún sitio cómo se restaura?
6. Monitorización: ¿nos enteramos de un error en producción antes que el usuario? Busca captura de errores, logs y alertas.

Al final, da una tabla: área, estado, gravedad (CRÍTICA / ALTA / MEDIA) y el paso más importante. CRÍTICA es todo lo que permite a un desconocido llegar a datos ajenos o a secretos. Ordena la tabla de mayor a menor riesgo y escribe debajo el número de hallazgos por gravedad. No inventes nada: lo que no veas en el código, márcalo como NO LO SÉ.

2. Cómo leer la respuesta

• Resuelva un PROBLEMA en las áreas 1 a 3 antes de que lleguen más usuarios. Es donde un desconocido llega con más frecuencia a datos ajenos.
• NO LO SÉ no es OK. Significa que la respuesta no está en el código. Pregunte a quien tenga acceso al hosting y a la base de datos.
• Compruebe usted mismo al menos un hallazgo. Abra el archivo y la línea que indicó el agente. Si no hay nada, el agente se lo inventa y conviene tomar los demás hallazgos con cautela.
• Cambie cualquier clave que haya estado en el repositorio. Borrarla del código no basta, sigue en el historial.
• OK en las seis áreas no significa que el prototipo sea seguro. El prompt encuentra parte de los problemas, no todos. Solo significa que lo básico está en su sitio.
• ¿Reforzar o reescribir? Cuando sepa qué arreglar, el test del prototipo le dirá si basta con correcciones.

3. Qué encontró la revisión

Marque las áreas en las que el agente escribió PROBLEMA o NO LO SÉ.