Auditoría de seguridad de una app web construida con IA: qué revisar

Una auditoría de seguridad de una app web para una app construida con IA es una revisión estructurada de quién puede leer y modificar qué datos, dónde viven tus secretos, cómo se confirman los pagos y si puedes recuperarte de un mal día. En la mayoría de las apps hechas con Lovable, Bolt, Base44 o Supabase, unas pocas revisiones enfocadas encuentran la mayor parte del riesgo, y no necesitas un proyecto de meses para empezar.

Soy un ingeniero brasileño con siete años trabajando en sistemas en producción, así que puede que tenga un sesgo hacia Brasil, pero el patrón que veo es constante: los problemas rara vez son exóticos. Están en las reglas de datos, en claves expuestas en el navegador y en la lógica de pagos. Esta guía muestra cómo hacer esa revisión, qué exigir del resultado y cuándo hacerla.

¿Qué cubre una auditoría de seguridad de una app web?

Una auditoría bien hecha revisa la aplicación que construiste, no solo los servidores que hay debajo. Para una app construida con IA, la agrupo en cinco áreas:

• Autenticación y sesiones: registro, inicio de sesión, restablecimiento de contraseña y si las apps privadas son realmente privadas.
• Autorización: ¿puede el usuario A leer o editar los registros del usuario B cambiando un ID?
• Secretos y claves: qué llega al navegador, qué está en el repositorio, qué se puede rotar.
• Pagos y lógica de negocio: cómo un pedido pasa a estar pagado y qué ocurre con los reintentos o los duplicados.
• Resiliencia: backups, pruebas de restauración, logs y rendimiento básico bajo carga.

El modelo de responsabilidad compartida importa aquí. El constructor protege su infraestructura y sus cuentas. Tú eres responsable de quién puede leer qué datos y de los datos de tus usuarios. En julio de 2025, investigadores de Wiz descubrieron que Base44, propiedad de Wix, permitía que un atacante se registrara en apps que debían ser privadas usando solo el ID de la app. Se corrigió en un día. La plataforma corrigió su parte, pero nadie más podía verificar por ti las reglas de tu propia app.

¿Necesito una auditoría completa o unas pocas revisiones enfocadas?

Al principio, revisiones enfocadas. La mayor parte del riesgo se encuentra con unas pocas revisiones específicas y no con una auditoría completa, y el costo de corregir crece cuando llegan usuarios reales y pagos. Ese es el argumento para hacer la versión pequeña temprano.

Cuándo bastan las revisiones enfocadas

• Todavía no lanzaste, o tienes un puñado de usuarios de prueba.
• Guardas datos de cuenta comunes, no registros de salud ni financieros.
• Los pagos pasan por Stripe Checkout, sin manejo propio de tarjetas.

Cuándo profundizar

• Manejas datos personales sensibles u operas en un área regulada. Habla con un abogado sobre tus obligaciones; este artículo no es asesoría legal.
• Clientes enterprise te piden un cuestionario de seguridad o un informe de terceros.
• La app tiene datos multi-tenant, roles y paneles de administración con reglas complejas.

Una auditoría completa también tiene sentido después de las revisiones enfocadas, una vez cerrados los agujeros obvios. Pagar por una revisión profunda de una app con tablas de datos abiertas desperdicia el presupuesto en hallazgos que podrías haber visto en una tarde.

¿Qué no detectan los escáneres automáticos?

Los escáneres son útiles y baratos. Detectan librerías desactualizadas, headers de seguridad faltantes, puertos abiertos y algunos patrones de inyección. Usa uno. Pero prueban lo que pueden ver desde afuera y no entienden lo que se supone que hace tu app.

No detectan la lógica de negocio. Un escáner no sabrá que:

• Un handler de webhook de Stripe acepta cualquier POST sin verificar la firma, así que cualquiera puede marcar un pedido como pagado.
• El mismo evento que llega dos veces crea dos pedidos u otorga créditos dos veces.
• Un usuario puede cambiar un precio o una cantidad en la solicitud y el servidor lo da por bueno.
• Un código de descuento se puede reutilizar sin límite.
• Una ruta de administración está oculta en la interfaz, pero no protegida en el servidor.

Por eso también pedirle al constructor con IA que corrija lo que él mismo generó no es un sustituto. Las reglas de datos, las claves y los flujos de pago son justo lo que estas herramientas suelen hacer mal, y el mismo modelo que los escribió puede no detectar sus propios errores. Una persona independiente que lea los flujos, con el escáner como apoyo, encuentra más.

¿Cómo reviso las reglas de acceso a datos y las claves?

Las apps construidas con Lovable han mostrado un patrón de reglas débiles de row level security (RLS) en Supabase. Empieza por ahí.

Reglas de acceso a datos

1. Lista todas las tablas. En cada una, confirma que RLS está habilitado.
2. Lee cada policy en lenguaje sencillo. Una policy que en la práctica dice “cualquier usuario autenticado puede leer todas las filas” es una fuga.
3. Prueba con dos cuentas reales. Inicia sesión como el usuario A y luego intenta obtener los registros del usuario B directamente a través de la API, no de la interfaz.
4. Prueba sin sesión iniciada. Las solicitudes anónimas no deben devolver nada privado.
5. Revisa que los buckets de storage tengan las mismas reglas que las tablas.
6. Revisa que las policies de escritura sean tan estrictas como las de lectura, incluidas las actualizaciones y los borrados.

Claves expuestas

Algunas claves están pensadas para ser públicas, como la anon key de Supabase, y solo son seguras cuando RLS está bien configurado. Otras nunca deben llegar al navegador: las service role keys, las claves secretas de Stripe, los secretos de webhook y las claves de API de terceros.

• Abre la pestaña de red del navegador y mira el JavaScript compilado. Busca los nombres de tus claves secretas.
• Busca en el repositorio de GitHub y en su historial, no solo en los archivos actuales.
• Mueve los secretos a variables de entorno del lado del servidor o a edge functions.
• Si un secreto estuvo expuesto alguna vez, rótalo. Borrarlo del código no deshace la filtración.

¿Cómo reviso los pagos y la lógica de negocio?

La regla es simple: el navegador nunca decide que alguien pagó. Solo lo decide un mensaje verificado de Stripe a tu servidor.

1. Encuentra la fuente de verdad. ¿La app da acceso cuando el usuario llega a una página de éxito o cuando un webhook confirma el pago? Debe ser el webhook.
2. Verifica las firmas. El handler debe comprobar la firma de Stripe con el secreto de tu webhook y rechazar todo lo demás.
3. Haz que los handlers sean idempotentes. Guarda el ID del evento e ignora las repeticiones, para que los reintentos no creen pedidos duplicados.
4. Maneja los eventos negativos. Los pagos fallidos, los reembolsos, las disputas y las suscripciones canceladas deben cambiar el acceso, no ignorarse.
5. Calcula los precios en el servidor. Nunca aceptes un monto que venga del cliente.
6. Prueba en el modo de prueba de Stripe. Reenvía eventos, envíalos dos veces, envíalos fuera de orden.

Más allá de los pagos, recorre los principales flujos del usuario como lo haría un atacante: sáltate pasos, repite pasos, cambia IDs, usa el enlace de otra persona. Los bugs de lógica de negocio viven en esos huecos.

Backups

La cuarta revisión es aburrida y vital. Confirma que los backups automáticos están activados, conoce el período de retención y haz una restauración en un entorno separado. Un backup que nunca restauraste es una esperanza, no un backup.

¿Qué debe darme el informe de auditoría?

Un informe útil es algo sobre lo que puedes actuar esa misma semana. Espera:

• Hallazgos ordenados por severidad, con una explicación sencilla de lo que podría hacer un atacante.
• Evidencia: la tabla, la ruta o la solicitud que muestra el problema, para que tu desarrollador pueda reproducirlo.
• Una corrección específica para cada punto, no solo “mejorar la seguridad”.
• Lo que no se revisó. Los límites de alcance honestos importan más que una calificación de aspecto impecable.
• Un paso de nueva prueba después de las correcciones, para confirmar que funcionan.

Desconfía de los informes que son sobre todo resultados de un escáner pegados en un PDF, o que prometen que la app es “totalmente segura”. Ninguna auditoría puede prometer eso. Reduce el riesgo y muestra dónde está el riesgo que queda.

¿Cuándo debo programar la auditoría?

Antes de tener usuarios reales y antes de cobrar pagos reales. Es el momento más barato, porque hay pocos datos que proteger, nada que migrar y ningún cliente a quien notificar si algo sale mal.

• Antes del lanzamiento: haz las cuatro revisiones.
• Antes de pasar Stripe a modo live: vuelve a revisar el flujo de pago de punta a punta.
• Después de cambios importantes: nuevos roles, nuevas tablas, una nueva integración, o la salida del constructor hacia GitHub y tu propio hosting.
• Periódicamente: las herramientas de IA siguen cambiando el código, así que un nuevo prompt puede alterar una regla de datos sin que te des cuenta.

Quedarse en el constructor a veces es la decisión correcta. Si la app es simple, los datos son de bajo riesgo y los controles de la plataforma son suficientes, puede que solo necesites las revisiones enfocadas, no una migración. Pasar a tu propio hosting es posible con código construido en Lovable, pero suma responsabilidades que pasan a ser tuyas.

¿Quieres una segunda opinión?

Si estás por lanzar una app construida con IA, escríbeme a me@filipeeduardo.dev con una descripción de tu configuración y con gusto te digo qué revisaría primero.