Lista de comprobació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 peticiones; las dependencias están actualizadas; y puedes restaurar tus datos si algo sale mal. La lista siguiente convierte cada una de esas cosas en pruebas concretas que puedes hacer sin leer código.

Los creadores de apps con IA son buenos haciendo que las funciones funcionen. No son automáticamente cuidadosos, porque "cuidado" rara vez aparece en el prompt. La mayoría de los problemas siguientes vienen 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 están marcados así:

• Imprescindible: hazlo antes de que nadie más use la app.
• Recomendable: hazlo antes de tener usuarios reales o datos reales.
• Más adelante: merece la pena a medida que la app crece.

Si solo tienes una hora, haz todos los Imprescindibles.

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.

• Imprescindible: Toda página que muestre datos privados exige inicio de sesión. Prueba: cierra sesión y pega directamente en el navegador la URL de una página privada.
• Imprescindible: 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 estabas conectado.
• Imprescindible: Las contraseñas se guardan con hash usando un algoritmo lento de hash de contraseñas, nunca en texto plano. La guía de OWASP sobre almacenamiento de contraseñas recomienda Argon2id en primer lugar, con scrypt, bcrypt o PBKDF2 como alternativas. Pregunta: "¿Cómo se almacenan las contraseñas?"
• Recomendable: Los enlaces para restablecer la contraseña caducan y solo funcionan una vez.
• Recomendable: 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 la tenga.

Comprueba cada ruta de API y 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 hayas comprobado.

2. Autorización: ¿qué puede 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), pero el servidor entregará los datos de cualquiera si se le pide directamente.

• Imprescindible: Cada lectura, actualización y borrado comprueba, en el servidor, que el registro pertenece al usuario actual (o a su equipo).
• Imprescindible: 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.
• Imprescindible: 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.
• Imprescindible: Los usuarios no pueden cambiar su propio rol, precio, saldo o campos de propietario editando la petición. Prueba: en la pestaña de red, mira qué envía una actualización de perfil. Si incluye campos como role o isAdmin, pide a la IA que los ignore cuando lleguen desde el cliente.
• Recomendable: Los ID en las URL son difíciles de adivinar (ID aleatorios en lugar de 1, 2, 3). No sustituyen a las comprobaciones de permisos, pero limitan el daño cuando una falta.

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

3. Acceso por fila en la base de datos

"Acceso por 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:

• Imprescindible: Si el navegador habla directamente con la base de datos (algunos productos de bases de datos alojadas lo permiten), las reglas de acceso por fila están activadas en todas las tablas. Sin ellas, cualquiera con la clave pública puede leer la tabla entera.
• Imprescindible: Las consultas filtran por el usuario o equipo actual, no por un ID que envíe el navegador.
• Recomendable: 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 y los proveedores de IA usan todos claves. Como contexto, consulta qué son las variables de entorno y los secretos.

• Imprescindible: Las claves se guardan en las variables de entorno o secretos del proyecto, nunca escritas en el código.
• Imprescindible: Las claves que pueden gastar dinero o leer datos privados solo se usan en el servidor. Prueba: abre tu sitio en directo, mira el código fuente de la página y los archivos JavaScript en las herramientas de desarrollo, y busca el inicio de tu clave (por ejemplo sk_). No debe aparecer.
• Imprescindible: Las claves nunca se pegaron en el chat, en un repositorio público ni en una captura de pantalla. Si alguna se pegó, rótala en el proveedor (crea una nueva y borra la antigua).
• Recomendable: 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.
• Recomendable: Las claves de prueba y las de producción están separadas, y la app en producción usa claves reales solo 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.

• Imprescindible: La validación se hace en el servidor, no solo en el navegador. Las comprobaciones del navegador son por comodidad; cualquiera puede saltárselas.
• Imprescindible: Las consultas a la base de datos usan parámetros, no texto pegado a partir de lo que escribe el usuario (esto evita la inyección SQL). Pide a la IA que lo confirme.
• Imprescindible: El texto que escriben los usuarios se muestra como texto, no se ejecuta como HTML. Prueba: escribe <b>hola</b> como tu nombre. Debes ver las etiquetas, no un texto en negrita.
• Recomendable: 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.
• Recomendable: Los errores que se muestran a los usuarios son sencillos ("Algo ha salido mal"); los errores detallados van solo a los registros del servidor.
• Recomendable: 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 peticiones y abuso

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

• Imprescindible: El inicio de sesión, el registro y el restablecimiento de contraseña tienen límite de peticiones por dirección IP y por cuenta.
• Imprescindible: Todo lo que te cueste dinero por llamada (peticiones a modelos de IA, SMS, correo) tiene un límite por usuario y exige inicio de sesión.
• Recomendable: Los formularios públicos (contacto, lista de espera) tienen protección contra spam: un límite de peticiones, un campo oculto trampa o un CAPTCHA.
• Recomendable: Configura límites de gasto o alertas en tus proveedores de pago, para que un error o un atacante no pueda generar una factura sin límite.

7. Dependencias

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

• Recomendable: Pide a la IA que busque vulnerabilidades conocidas (en proyectos JavaScript, npm audit o el equivalente de tu gestor de paquetes) y actualice lo que esté afectado.
• Recomendable: Elimina los paquetes que la app ya no usa.
• Recomendable: Desconfía de los paquetes con muy pocos usuarios o con nombres que parecen erratas de otros populares.
• Más adelante: Vuelve a revisar 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 recuperarse de los errores, sean tuyos, de la IA o de un atacante.

• Imprescindible: Sabe dónde están tus datos y si tienen copia de seguridad. No lo des por hecho; consulta la documentación de tu proveedor de alojamiento.
• Recomendable: Mantén 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), guardada en un lugar aparte.
• Recomendable: Guarda tu código en un sistema de control de versiones, para poder restaurar cualquier versión.
• Recomendable: Las acciones destructivas (eliminar cuenta, eliminar proyecto) piden confirmación, y valora un "borrado suave" que pueda deshacerse durante un tiempo.
• Más adelante: Prueba de verdad una restauración una vez. Una copia de seguridad que nunca has restaurado es una esperanza, no un plan.

9. Antes del lanzamiento

• Imprescindible: El sitio en directo usa HTTPS en todas sus partes.
• Imprescindible: Se eliminan los datos de muestra, las cuentas de prueba y las páginas de depuración del desarrollo.
• Recomendable: 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.
• Recomendable: Tienes una forma de que te contacten por problemas de seguridad, y sabes cómo rotar cualquier clave con rapidez.

Para una revisión previa al lanzamiento más amplia que vaya 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 comprobación detecta los errores comunes; no sustituye a un experto. Considera pagar una revisión si procesas tú mismo números de tarjeta en lugar de usar un pago alojado, si guardas datos de salud, financieros o de menores, si vendes a empresas que piden cuestionarios de seguridad, o si una filtración te perjudicaría seriamente. Tener tu código exportable 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 directo, vuelve a publicarla.
• Modos Plan y Ask. Pide al agente que revise los permisos sin editar: "En modo Ask, enumera cada ruta de API y qué comprobación de permisos hace."
• /test hace que el agente navegue por tu vista previa como un usuario; es útil para la prueba de dos cuentas de la sección 2.
• Puntos de control te permiten deshacer un cambio que haya roto algo.

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

Preguntas