Los errores de seguridad más habituales al publicar una app hecha con IA son cuatro: claves secretas en el código que descarga el navegador, tablas de la base de datos sin reglas de acceso, pagos que se dan por buenos porque lo dice el navegador y datos personales recogidos sin avisar. Todos se pueden comprobar antes de compartir el enlace.
Ninguno exige saber programar para detectarlo. Exige saber dónde mirar. Las herramientas de vibe coding están pensadas para que la app funcione cuanto antes, y lo consiguen: en tus pruebas todo va bien porque eres el único usuario y la usas como esperas. Los problemas llegan con la primera persona que no la usa como esperas. Si además tu app lleva un asistente de IA, hay un quinto error que revisar. Aquí tienes cada error, por qué aparece, cómo comprobarlo y qué pedirle a la IA para corregirlo, con la documentación oficial de Supabase, Stripe y OWASP como referencia.
Por qué una app que funciona no siempre está lista para publicar
Porque funcionar y ser segura son cosas distintas. Una app hecha con IA suele tener dos mitades: lo que se ejecuta en el navegador de quien la usa y lo que se ejecuta en un servidor o en servicios como Supabase o Stripe. Todo lo que llega al navegador se puede leer, copiar y modificar.
El OWASP Top 10, la lista de referencia de riesgos en aplicaciones web que publica la fundación OWASP, abre su edición 2025 con «Broken Access Control» (control de acceso roto) y pone en segundo lugar «Security Misconfiguration» (configuración insegura). Buena parte de los errores de este artículo caen en esas dos categorías: alguien puede ver o tocar lo que no debería, o algo se quedó con la configuración de las pruebas.
Una regla práctica para cualquier app que vaya a usar alguien más: da por hecho que el usuario puede leer todo lo que llega a su navegador y cambiar cualquier dato que envía. Si con esa suposición tu app sigue protegida, vas bien. Si no, toca mover algo al servidor.
Error 1: claves secretas en el código que llega al navegador
Es el error más fácil de cometer y de comprobar. Tu app se conecta a la base de datos, a los pagos o a un modelo de IA con claves de API. Unas están pensadas para ir en el navegador y otras no: una clave secreta en el código del cliente la puede copiar cualquiera que abra la página.
Cada servicio separa los dos tipos y lo dice en su documentación:
Servicio | Puede ir en el navegador | Solo en el servidor |
|---|---|---|
Stripe | Clave publicable ( | Clave secreta ( |
Supabase | Clave publicable ( | Clave secreta ( |
Stripe explica que la clave publicable puede incluirse en el código del front-end, pero «no puede realizar operaciones confidenciales, como crear cargos o leer datos de la cuenta». La secreta tiene permisos sin restricciones sobre todas sus API. Supabase va igual de directo con la suya: no la uses nunca en el navegador, porque se salta las reglas de acceso de la base de datos. Con la clave de tu proveedor de modelos de IA aplica la misma lógica: si da acceso a tu cuenta y se paga por uso, vive en el servidor.
Un origen habitual del fallo son las variables de entorno. Si tu proyecto usa Vite (lo verás en el archivo package.json), su documentación avisa de que las variables que empiezan por VITE_ acaban en el código del cliente al compilar y que no deben contener información sensible como claves de API. Poner la clave secreta de Stripe en una variable VITE_STRIPE_SECRET es publicarla.
Cómo comprobarlo. Abre tu app ya publicada en Chrome, pulsa F12, ve a la pestaña «Sources» y busca en todos los archivos (Ctrl+Mayús+F, o Cmd+Opción+F en Mac) estos textos: sk_live, sk_test, rk_live, sb_secret y service_role. Si aparece alguno, esa clave está expuesta. Haz lo mismo en tu repositorio si es público: Stripe pide no incluir claves en el código fuente ni en archivos de configuración que se guarden en el control de versiones.
Qué pedirle a la IA. Algo como: «Mueve todas las operaciones que usan la clave secreta de Stripe a una función de servidor. Lee la clave de una variable de entorno sin prefijo VITE_. El navegador solo debe usar la clave publicable». Después vuelve a buscar en «Sources».
Error 2: tablas de la base de datos sin reglas de acceso
Si usas Supabase, la clave publicable está a la vista por diseño, y lo que protege tus datos son las reglas de Row Level Security (RLS). Sin ellas, la documentación es tajante: una tabla de un esquema expuesto sin RLS se puede leer y escribir por cualquier rol con permisos sobre ella. En la práctica, eso puede incluir a cualquiera con tu clave publicable.
La guía de RLS de Supabase pide activarla en todas las tablas de un esquema expuesto, como public. Al activarla sin crear políticas, la tabla se cierra: ningún dato es accesible por la API con la clave publicable hasta que crees políticas. Después añades las reglas que tu app necesita, por ejemplo que cada usuario solo pueda leer y modificar sus propias filas.
Un detalle que conviene tener presente cuando la IA crea tablas por ti: según la misma guía, en los proyectos existentes una tabla nueva en public nace con todos los privilegios concedidos a los tres roles. Cada tabla que añadas durante el desarrollo necesita su RLS, no solo las del principio.
Cómo comprobarlo. Crea dos cuentas de prueba, A y B. Con la cuenta A guarda algo (un pedido, una nota, un perfil). Entra con la cuenta B e intenta verlo: cambia el identificador en la URL o en la petición si la app lo muestra. Si B ve o modifica lo de A, el control de acceso falla. Repite la prueba sin iniciar sesión.
Qué pedirle a la IA. «Activa RLS en todas las tablas del esquema public y crea políticas para que cada usuario solo lea y modifique sus filas. Dame la lista de tablas y la política de cada una». Revisa esa lista contra las tablas que ves en el panel. Si tu app tiene inicio de sesión propio, en el artículo de sesiones, JWT y OAuth tienes cómo funciona por dentro.
Error 3: dar un pago por bueno porque lo dice el navegador
En una app con pagos, el fallo típico es activar el acceso de pago cuando el usuario llega a la página de «gracias». Stripe lo desaconseja de forma expresa: no puedes depender solo de esa página, porque no está garantizado que el cliente la visite. La confirmación fiable llega por webhook, directamente del servidor de Stripe al tuyo.
La guía de tramitación de pedidos de Stripe lo explica con un ejemplo: alguien paga bien y pierde la conexión antes de que cargue tu página de destino. Si vendes suscripciones, el webhook es obligatorio. Y el webhook tiene que estar verificado. En palabras de la documentación de webhooks: «Sin verificación, un atacante podría enviar eventos webhook falsos a tu punto de conexión para ejecutar acciones como completar pedidos, conceder acceso a cuentas o modificar registros».
La verificación se hace con la firma que Stripe envía en el encabezado Stripe-Signature y el secreto del webhook (empieza por whsec_). Stripe añade otro aviso práctico: la función que entrega lo comprado puede llamarse varias veces para el mismo pago, así que debe hacerlo solo una vez. El precio también se decide en el servidor: la sesión de pago se crea allí con una clave del servidor, así que no aceptes un importe que llegue del navegador.
Cómo comprobarlo. Usa el modo de prueba de Stripe (claves pk_test_ y sk_test_) con la tarjeta 4242 4242 4242 4242, cualquier fecha futura y cualquier CVC. Haz tres pruebas: paga y cierra la pestaña antes de que cargue la página de «gracias» (el acceso debe activarse igual); visita la URL de «gracias» sin pagar (no debe activarse nada); y repite un pago para ver que no se entrega dos veces.
Montar una suscripción de pago con este circuito completo es justo el proyecto 5 de AI Maker, «Suscripción de pago»: «Integra métodos de pagos y gestión de datos de clientes en una herramienta o plataforma de forma segura». Si quieres ver cómo encaja con el resto de proyectos del programa, descarga el dossier de AI Maker.
Error 4: recoger datos personales sin decir para qué
En cuanto tu app guarda un nombre, un correo o un teléfono, tratas datos personales y se aplica el RGPD. El fallo más común aquí no es técnico: es no informar a la persona de quién trata sus datos y para qué, o pedir más datos de los que la app necesita de verdad.
El Reglamento General de Protección de Datos recoge el deber de informar cuando los datos se obtienen del propio interesado (artículo 13), el principio de minimización, que limita los datos a los necesarios para cada fin (artículo 5.1.c), la protección de datos desde el diseño y por defecto (artículo 25) y la seguridad del tratamiento (artículo 32). Si tu app solo envía un formulario de contacto, en la guía para crear una landing con IA tienes la parte del aviso de privacidad y la LSSI.
Cómo comprobarlo. Abre cada tabla y haz una lista de los campos que guarda. Al lado, apunta para qué los usa la app. Lo que no tenga uso, fuera: un dato que no guardas no se puede filtrar. Revisa también que el formulario de registro enlaza a la información de privacidad antes de enviar.
Esto no es asesoramiento legal. Si tu app trata categorías especiales de datos, como los de salud (artículo 9 del RGPD), o datos de menores, consulta con un profesional antes de publicarla.
Error 5: un asistente de IA dentro de la app sin límites
Si tu app incluye un chat o un asistente conectado a un modelo, suma riesgos propios. OWASP los recoge en su Top 10 para aplicaciones con LLM, edición 2025, y cuatro afectan de lleno a quien publica su primera app: inyección de prompt, filtración del prompt de sistema, agencia excesiva y consumo sin límites.
Inyección de prompt (LLM01). El usuario, o un documento que el asistente lee, cambia el comportamiento del modelo. OWASP recomienda limitar los permisos del modelo al mínimo que necesita y pedir aprobación humana antes de operaciones privilegiadas.
Filtración del prompt de sistema (LLM07). Lo que pones en las instrucciones del asistente puede acabar a la vista. La primera medida de OWASP es no meter ahí claves, credenciales ni nombres de bases de datos y dejarlos en sistemas a los que el modelo no accede.
Agencia excesiva (LLM06). Un asistente que «actúa por ti» con más herramientas o permisos de los necesarios. OWASP propone reducir las extensiones, reducir sus permisos y pedir la aprobación del usuario en las acciones de impacto.
Consumo sin límites (LLM10). Alguien lanza miles de peticiones y la factura del proveedor la pagas tú; OWASP lo llama «Denial of Wallet». Las medidas: límite de tamaño en lo que se envía, límite de peticiones por usuario y tiempos máximos.
Cómo comprobarlo. Pídele a tu asistente que ignore sus instrucciones y te muestre su prompt de sistema. Pégale un texto enorme. Lanza muchas preguntas seguidas desde la misma cuenta. Y revisa en el panel de tu proveedor de IA si puedes fijar un límite de gasto. Si estás construyendo un asistente que hace cosas, en la guía para crear un agente de IA paso a paso tienes el método completo.
El OWASP Top 10 2025 aplicado a una app hecha con IA
El OWASP Top 10 2025 es la edición vigente de la lista de riesgos más importantes en aplicaciones web. No es una norma ni un examen: es una forma ordenada de repasar tu app. Esta tabla traduce cada categoría a lo que conviene mirar en un proyecto construido con IA.
Categoría (nombre oficial) | Qué significa | Qué mirar en tu app |
|---|---|---|
A01 Broken Access Control | Control de acceso roto | Que un usuario no pueda ver ni cambiar datos de otro (error 2) |
A02 Security Misconfiguration | Configuración insegura | Claves de prueba, opciones por defecto, claves en el cliente (error 1) |
A03 Software Supply Chain Failures | Fallos en la cadena de suministro de software | Las librerías que la IA ha añadido: que existan, se mantengan y las necesites |
A04 Cryptographic Failures | Fallos criptográficos | HTTPS en todo el sitio y contraseñas gestionadas por el sistema de autenticación, no por tu código |
A05 Injection | Inyección | Datos del usuario que acaban en una consulta o en la página sin filtrar |
A06 Insecure Design | Diseño inseguro | Flujos pensados sin el usuario malintencionado, como el pago del error 3 |
A07 Authentication Failures | Fallos de autenticación | Inicio de sesión, recuperación de contraseña y caducidad de las sesiones |
A08 Software or Data Integrity Failures | Fallos de integridad de software o datos | Aceptar datos o eventos sin verificar su origen, como un webhook sin firma |
A09 Security Logging and Alerting Failures | Fallos de registro y alertas | Saber qué ha pasado: registros de accesos y avisos ante errores |
A10 Mishandling of Exceptional Conditions | Mala gestión de situaciones excepcionales | Mensajes de error que enseñan detalles internos o dejan la app a medias |
Si tu app expone una API propia, en el artículo sobre cómo asegurar tus APIs frente a vulnerabilidades comunes tienes el detalle de esa parte.
La comprobación antes de compartir el enlace
Antes de mandar el enlace a tus primeros usuarios, dedica una sesión a repasar esta lista con la app ya publicada, no en tu ordenador. Son diez puntos y la mayoría se resuelven pidiéndole el cambio a la propia IA y volviendo a probar.
Ninguna clave secreta (
sk_,rk_,sb_secret,service_role, la de tu proveedor de IA) aparece al buscar en «Sources» del navegador.Las claves secretas están en variables de entorno del servidor, sin prefijo
VITE_, y fuera del repositorio.Todas las tablas del esquema
publictienen RLS activada y una política por operación que la app usa.Con una segunda cuenta de prueba no puedes ver ni modificar los datos de la primera, y sin sesión iniciada tampoco.
El acceso de pago se activa desde un webhook verificado con su firma, no desde la página de «gracias».
El precio se fija en el servidor y un mismo pago no se entrega dos veces.
Cada dato personal que guardas tiene un uso, y el formulario informa de quién lo trata y para qué.
Si hay asistente de IA: no hay claves en su prompt, tiene límite de peticiones y tamaño, y las acciones con impacto piden confirmación.
Los mensajes de error que ve el usuario no muestran detalles internos.
Has pasado de claves de prueba a claves de producción solo en el servidor y sabes dónde se rota cada una.
Lo bueno de esta lista es que se repite: la segunda vez la pasas en mucho menos tiempo, y con la tercera la tienes en la cabeza mientras construyes. Para profundizar, INCIBE tiene una guía pensada para equipos pequeños, «Cómo construir software seguro para mi start-up» (2024).
Qué hacer si ya has publicado con alguno de estos fallos
Primero se corrige la causa y después se cambian las claves. Si una clave secreta ha estado a la vista, muévela al servidor y rótala: Supabase pide rotar la clave filtrada en cuanto arregles la causa de la filtración, y Stripe permite rotar una clave desde su panel, con la antigua activa hasta 7 días para que migres sin cortes.
Si las tablas estaban abiertas, activa RLS ya. Y si hay indicios de que alguien ha accedido a datos personales, entra en juego el RGPD. La guía de la AEPD para la notificación de brechas de datos personales (versión de junio de 2021) lo resume así:
Una brecha es «toda violación de la seguridad que ocasionen la destrucción, pérdida o alteración accidental o ilícita de datos personales transmitidos, conservados o tratados de otra forma, o la comunicación o acceso no autorizados a dichos datos».
Toda brecha se documenta, con los hechos, sus efectos y las medidas tomadas (artículo 33.5 del RGPD).
Si es probable que suponga un riesgo para las personas, se notifica a la AEPD sin dilación y como tarde en 72 horas, contando fines de semana y festivos (artículo 33).
Si es probable que suponga un alto riesgo, también se comunica a los afectados (artículo 34).
De nuevo, esto no sustituye al asesoramiento legal: si te encuentras en este caso, apóyate en un profesional de protección de datos.
De prototipo a app publicada: dónde se aprende este criterio
Construir con IA ya no exige ser técnico. Lo que marca la diferencia entre un prototipo y una app que puedes enseñar a clientes es el criterio para revisar lo que la IA ha hecho, y ese criterio se entrena construyendo proyectos reales y publicándolos.
Es lo que plantea AI Maker, el máster de ThePower para construir con IA sin programar. Entre las competencias que trabaja está, literalmente, «Probar y publicar tu solución con fiabilidad, seguridad y privacidad». Lo hace con 8 proyectos acumulativos: «de una primera landing hasta una plataforma completa con IA aplicada», pasando por la suscripción de pago del proyecto 5 y un asistente con IA en el 7. Si vienes de Cursor o de otras herramientas de vibe coding, el programa incluye una especialización opcional en Claude Code y Codex.
Preguntas frecuentes sobre la seguridad de las apps hechas con IA
¿El código que genera la IA es seguro para publicar una app?
Puede serlo, pero no lo des por hecho. La IA genera código que funciona en el caso que le describes y no siempre piensa en el usuario que intenta saltarse las reglas. Revisa claves, reglas de acceso, pagos y datos personales con la app ya publicada, y pide a la IA que corrija cada fallo que encuentres.
¿Es un problema que se vea la clave publicable de Supabase o de Stripe?
No. Las claves publicables están pensadas para ir en el navegador. En Stripe no pueden crear cargos ni leer datos de la cuenta. En Supabase solo llegan a lo que permiten las reglas de Row Level Security, así que lo que tienes que vigilar es que cada tabla tenga RLS activada y bien configurada.
¿Qué es el OWASP Top 10 y cuál es la edición vigente?
Es la lista de los riesgos de seguridad más importantes en aplicaciones web que publica la fundación OWASP. La edición vigente es la de 2025, que empieza por el control de acceso roto y la configuración insegura. Para apps con chat o asistente, OWASP tiene además un Top 10 específico de aplicaciones con LLM.
¿Necesito saber programar para revisar la seguridad de mi app?
No para una primera revisión. Buscar claves en el navegador, probar con dos cuentas, hacer un pago de prueba y repasar qué datos guardas son comprobaciones al alcance de cualquiera. Si tu app maneja datos sensibles o mucho dinero, suma la revisión de un perfil técnico antes de abrirla al público.
¿Qué hago si he subido una clave secreta a GitHub?
Da la clave por comprometida aunque borres el archivo, porque queda en el historial del repositorio. Muévela a una variable de entorno del servidor, corrige el código y rota la clave desde el panel del servicio, que genera una nueva e invalida la antigua. Después revisa la actividad de la cuenta.
