Lista de verificación de seguridad para apps creadas con IA: qué revisar antes del lanzamiento

Antes de que personas reales usen una app que creaste con IA, revisa siete cosas: cada página y cada API comprueba quién es el usuario y qué puede hacer; las claves secretas viven en el servidor, nunca en el navegador ni en el chat; todas las entradas se validan en el servidor; cada usuario solo puede acceder a sus propios registros; el inicio de sesión y los endpoints costosos tienen límites de uso; las dependencias están actualizadas; y puedes restaurar tus datos si algo sale mal. La lista que sigue convierte cada una de esas cosas en pruebas concretas que puedes ejecutar sin leer código.

Los constructores de apps con IA son buenos haciendo que las funciones funcionen. No son cuidadosos de forma automática, porque “cuidadoso” rara vez aparece en el prompt. La mayoría de los problemas de abajo surgen de cosas que nadie pidió, así que la solución suele ser pedirlas.

Cómo usar esta lista

Recórrela en orden y, para cada punto, haz dos cosas: pide a la IA que se asegure de que está resuelto, y pruébalo tú mismo. La IA puede escribir una comprobación de permisos; solo una prueba te dice que funciona. Los puntos se marcan así:

• Obligatorio: hazlo antes de que nadie más use la app.
• Recomendado: hazlo antes de tener usuarios reales o datos reales.
• Más adelante: vale la pena hacerlo a medida que la app crece.

Si solo tienes una hora, haz todos los obligatorios.

1. Autenticación: ¿quién es?

La autenticación consiste en confirmar quién es alguien, normalmente mediante el inicio de sesión. Consulta qué es la autenticación para los conceptos básicos y cómo añadir inicio de sesión a tu app para las opciones.

• Obligatorio: toda página que muestre datos privados exige inicio de sesión. Prueba: cierra sesión y pega la URL de una página privada directamente en el navegador.
• Obligatorio: todo endpoint de API detrás de esas páginas también exige inicio de sesión, no solo la página. Prueba: cierra sesión, abre la pestaña de red del navegador y repite una petición que la app hizo mientras tenías sesión iniciada.
• Obligatorio: las contraseñas se guardan con hash mediante un algoritmo de hash lento pensado para contraseñas, nunca en texto plano. La guía de almacenamiento de contraseñas de OWASP recomienda Argon2id en primer lugar, con scrypt, bcrypt o PBKDF2 como alternativas. Pregunta: “¿Cómo se guardan las contraseñas?”.
• Recomendado: los enlaces para restablecer la contraseña caducan y solo funcionan una vez.
• Recomendado: las cookies de sesión están marcadas como Secure, HttpOnly y SameSite, y cerrar sesión termina la sesión en el servidor.
• Más adelante: ofrece autenticación de dos factores, o inicio de sesión a través de un proveedor que lo tenga.

Comprueba cada ruta de API y cada página que devuelva datos de usuario. Cada una debe rechazar las peticiones de usuarios que no han iniciado sesión, en el servidor, no solo en el código de la página. Enumera las rutas que comprobaste.

2. Autorización: ¿qué tiene permitido hacer?

La autorización es el paso posterior al inicio de sesión: decidir qué puede ver y cambiar este usuario concreto. Aquí es donde las apps creadas con IA suelen tener agujeros graves, porque la app parece correcta (el panel de cada usuario solo muestra sus propios datos), mientras que el servidor entregará los datos de cualquiera si se le piden directamente.

• Obligatorio: cada lectura, actualización y borrado comprueba, en el servidor, que el registro pertenece al usuario actual (o a su equipo).
• Obligatorio: pruébalo: crea dos cuentas, A y B. Como A, abre uno de los registros de A y anota el ID de la URL o de la petición de red. Inicia sesión como B y pide ese mismo ID. B debe recibir un error, no los datos de A.
• Obligatorio: las páginas de administración y los endpoints de API de administración comprueban el rol del usuario en el servidor. Ocultar el enlace de administración no es protección.
• Obligatorio: los usuarios no pueden cambiar su propio rol, precio, saldo ni campos de propietario editando la petición. Prueba: en la pestaña de red, mira lo que envía una actualización de perfil. Si incluye campos como role o isAdmin, pide a la IA que los ignore desde el cliente.
• Recomendado: los ID en las URL son difíciles de adivinar (ID aleatorios en lugar de 1, 2, 3). Esto no sustituye a las comprobaciones de permisos, pero limita el daño cuando falta una.

Para cada endpoint que lea o cambie un registro, comprueba en el servidor que el usuario conectado es el propietario o tiene permiso de acceso. Devuelve 404 si no lo tiene. Después, muéstrame cómo lo probarías con dos cuentas.

3. Acceso a nivel de fila en la base de datos

“Acceso a nivel de fila” significa que cada fila de una tabla (una reserva, una factura) solo es visible para los usuarios a los que pertenece. Hay dos formas habituales de aplicarlo:

Cualquiera de los dos puede hacerse bien. Lo que importa:

• Obligatorio: si el navegador habla directamente con la base de datos (algunos productos de bases de datos alojadas lo permiten), las reglas de nivel de fila están activadas en todas las tablas. Sin ellas, cualquiera con la clave pública puede leer toda la tabla.
• Obligatorio: las consultas filtran por el usuario o equipo actual, no por un ID que envía el navegador.
• Recomendado: los datos compartidos (los proyectos de un equipo) tienen una regla clara sobre quién forma parte del equipo, aplicada en un único lugar.

4. Secretos y claves de API

Una clave de API es una contraseña para un servicio. Stripe, el correo electrónico y los proveedores de IA usan todos claves. Para más contexto, consulta qué son las variables de entorno y los secretos.

• Obligatorio: las claves se guardan en las variables de entorno o los secretos del proyecto, nunca escritas en el código.
• Obligatorio: las claves que pueden gastar dinero o leer datos privados solo se usan en el servidor. Prueba: abre tu sitio en producción, mira el código fuente de la página y los archivos JavaScript en las herramientas para desarrolladores, y busca el inicio de tu clave (por ejemplo sk_). No debe aparecer.
• Obligatorio: las claves nunca se pegaron en el chat, en un repositorio público ni en una captura de pantalla. Si alguna se expuso, rótala en el proveedor (crea una nueva y elimina la antigua).
• Recomendado: usa claves restringidas o con alcance limitado cuando el proveedor las ofrezca. Stripe, por ejemplo, recomienda claves restringidas que solo tengan los permisos que necesita tu integración.
• Recomendado: las claves de prueba y las reales están separadas, y la app en producción solo usa claves reales cuando estás listo.

Algunas claves están pensadas para ser públicas: la clave publicable de Stripe (pk_…) o una clave de mapas restringida a tu dominio. La regla se refiere a las claves que otorgan poder, no a cualquier cadena que parezca una clave.

5. Validación de entradas

Cualquier cosa que envíe un usuario (campos de formulario, subidas de archivos, parámetros de URL) puede ser cualquier cosa, no solo lo que permite tu formulario.

• Obligatorio: la validación se hace en el servidor, no solo en el navegador. Las comprobaciones del navegador son por comodidad; cualquiera puede saltárselas.
• Obligatorio: las consultas a la base de datos usan parámetros, no texto pegado a partir de lo que escribe el usuario (esto previene la inyección SQL). Pide a la IA que lo confirme.
• Obligatorio: el texto que escriben los usuarios se muestra como texto, no se ejecuta como HTML. Prueba: escribe <b>hola</b> como tu nombre. Deberías ver las etiquetas, no un texto en negrita.
• Recomendado: las subidas de archivos comprueban el tipo y el tamaño, y los archivos subidos no se sirven desde el dominio principal de tu app como páginas ejecutables.
• Recomendado: los errores que se muestran a los usuarios son sencillos (“Algo salió mal”); los errores detallados solo van a los registros del servidor.
• Recomendado: los webhooks de servicios como Stripe verifican la firma del proveedor antes de actuar. Consulta qué es un webhook.

Añade validación en el servidor a cada formulario y endpoint de API: campos obligatorios, longitudes, formatos y valores permitidos. Rechaza cualquier otra cosa con un mensaje claro. No muestres a los usuarios detalles internos de los errores.

6. Límites de uso y abuso

Un límite de uso restringe cuántas peticiones puede hacer alguien en un periodo. Sin ellos, cualquiera puede intentar adivinar contraseñas todo el día, saturar tu formulario de registro o disparar tu factura en una API de pago.

• Obligatorio: el inicio de sesión, el registro y el restablecimiento de contraseña tienen límite de uso por dirección IP y por cuenta.
• Obligatorio: todo lo que te cuesta dinero por llamada (peticiones a modelos de IA, SMS, correo) tiene un límite por usuario y requiere inicio de sesión.
• Recomendado: los formularios públicos (contacto, lista de espera) tienen protección contra spam: un límite de uso, un campo oculto trampa o un CAPTCHA.
• Recomendado: configura límites de gasto o alertas en tus proveedores de pago, para que un error o un atacante no pueda generar una factura ilimitada.

7. Dependencias

Las apps se construyen con paquetes de código abierto, y los paquetes a veces tienen vulnerabilidades conocidas.

• Recomendado: pide a la IA que busque vulnerabilidades conocidas (en proyectos JavaScript, npm audit o el equivalente de tu gestor de paquetes) y actualice lo afectado.
• Recomendado: elimina los paquetes que la app ya no usa.
• Recomendado: desconfía de paquetes con muy pocos usuarios o con nombres que parecen erratas de otros populares.
• Más adelante: revisa cada uno o dos meses, o activa alertas automáticas si tu código está en GitHub.

8. Copias de seguridad y recuperación

La seguridad incluye poder recuperarte de los errores, sean tuyos, de la IA o de un atacante.

• Obligatorio: sabe dónde viven tus datos y si tienen copia de seguridad. No lo des por hecho; consulta la documentación de tu proveedor de alojamiento.
• Recomendado: guarda tu propia exportación periódica de los datos importantes (por ejemplo, una función de exportación a CSV o un volcado de la base de datos), en un lugar separado.
• Recomendado: guarda tu código en control de versiones, para poder restaurar cualquier versión.
• Recomendado: las acciones destructivas (eliminar cuenta, eliminar proyecto) piden confirmación, y considera un “borrado lógico” que pueda deshacerse durante un tiempo.
• Más adelante: prueba de verdad a restaurar una vez. Una copia de seguridad que nunca has restaurado es una esperanza, no un plan.

9. Antes del lanzamiento

• Obligatorio: el sitio en producción usa HTTPS en todas partes.
• Obligatorio: se eliminan los datos de ejemplo, las cuentas de prueba y las páginas de depuración del desarrollo.
• Recomendado: una política de privacidad indica qué datos recoges y por qué; en muchos lugares es obligatoria si recoges datos personales. No afirmes certificaciones (SOC 2, HIPAA) que no tengas.
• Recomendado: tienes una forma de que te contacten por temas de seguridad, y sabes cómo rotar cada clave con rapidez.

Para una revisión previa al lanzamiento más amplia, más allá de la seguridad, consulta cómo llevar un prototipo de IA a producción.

Cuándo pedir una revisión profesional

Una lista de verificación detecta los errores comunes; no sustituye a un experto. Considera pagar una revisión si procesas números de tarjeta tú mismo en lugar de usar un pago alojado, si almacenas datos de salud, financieros o de menores, si vendes a empresas que piden cuestionarios de seguridad, o si una filtración te causaría un daño grave. Poder exportar tu código facilita mucho esa revisión.

Seguridad al construir en Mythex

Mythex no incluye un panel de análisis de seguridad, así que la lista anterior es el proceso a seguir. Algunas cosas que ayudan:

• Secretos del proyecto. Guarda las claves en Ajustes del proyecto → Secretos, o a través de la tarjeta de secretos que el agente muestra en el chat, para que no estén en tu código ni en tus mensajes. Después de cambiar un secreto de una app en producción, vuelve a publicar.
• Modos Plan y Preguntar. Pide al agente que revise los permisos sin editar: “En modo Preguntar, enumera cada ruta de API y qué comprobación de permisos hace”.
• /test hace que el agente recorra tu vista previa como un usuario, útil para la prueba de dos cuentas de la sección 2.
• Puntos de control te permiten revertir un cambio que rompió algo.

Consulta Seguridad para las apps que creas y Variables de entorno y secretos en la documentación. Si vas a añadir cuentas de usuario, lee después cómo añadir inicio de sesión a tu app.

Preguntas