Auditoría de seguridad de apps con IA
Auditoría de seguridad para apps hechas con IA
Las herramientas de IA construyen apps que funcionan, y rápido. También se saltan lo que no se ve en una demo: reglas de acceso, secretos, límites de peticiones y revisión de dependencias. Nosotros revisamos eso y lo arreglamos contigo.
Una auditoría de seguridad de apps hechas con IA es una revisión enfocada de una aplicación creada con Lovable, Bolt, Cursor, Replit, v0, Claude o herramientas similares, centrada en los fallos que estas herramientas suelen dejar: claves de API expuestas, reglas de acceso a la base de datos ausentes, autenticación rota, paquetes inventados y falta de límites de peticiones. Es para fundadores y equipos pequeños a punto de lanzar o de cobrar. Parte de 1.500 € y lleva 3–5 días.
Para quién es
- Fundadores que han creado un MVP con Lovable, Bolt, Replit, v0, Cursor o Claude
- Equipos pequeños a punto de lanzar, cobrar o guardar datos personales
- Empresas cuyo personal ha creado herramientas internas con IA y quiere saber si son seguras
- Inversores o compradores que quieren una revisión independiente antes de cerrar
Por qué ahora
- Vas a lanzar o a empezar a cobrar, y nadie ha mirado el código salvo la propia IA
- Los estudios encuentran fallos de seguridad en una parte importante del código generado por IA (Veracode los encontró en cerca del 45 % de las muestras)
- Tu app guarda datos personales de usuarios de la UE, y una filtración sería un incidente RGPD
- Un inversor, cliente o socio te ha preguntado cómo sabes que la app es segura
Qué recibes
- Revisión de secretos: claves de API y tokens de servicio en el bundle del frontend, el repositorio y su historial, con plan de rotación
- Reglas de acceso a la base de datos: en Supabase y Firebase, row-level security y reglas probadas con un usuario real y con uno anónimo
- Pruebas de autenticación y autorización: ¿puede un usuario leer o cambiar los datos de otro, o llegar a funciones de administrador?
- Revisión de dependencias: paquetes que no existen o que la IA se ha inventado, typosquatting y vulnerabilidades conocidas
- Pruebas de abuso: falta de límites en login, registro, email, IA y pagos, que te cuestan dinero
- Entradas y archivos: inyecciones, subidas inseguras y peticiones del lado del servidor en rutas de API y edge functions
- Informe de hallazgos en lenguaje claro con la corrección exacta de cada uno, y una llamada corta para repasarlo
- Ayuda con las correcciones: prompts y parches que puedes aplicar con tu propia herramienta de IA, y una segunda revisión
Cómo funciona
Acceso
Compartes el repositorio (o una exportación) y una cuenta de prueba. No necesitamos datos de producción.
Revisión
Revisamos el código y probamos la app en marcha: secretos, reglas de base de datos, auth, dependencias y vías de abuso.
Informe
Una lista ordenada de hallazgos en lenguaje claro, cada uno con su solución. Lo crítico te lo contamos el mismo día.
Segunda revisión
Tú o nosotros aplicamos las correcciones; volvemos a probar y confirmamos qué está cerrado.
Por qué las apps hechas con IA fallan en los mismos sitios
Las herramientas de IA para programar son buenas haciendo que las funciones funcionen. Son menos fiables en lo que solo importa cuando alguien intenta abusar de la app. En la práctica, los mismos fallos aparecen una y otra vez:
- Claves en el navegador. Una clave de servicio con todos los permisos sobre la base de datos acaba en el código del frontend porque “así funciona”.
- Sin row-level security. Las tablas de Supabase se crean sin políticas RLS, así que cualquier usuario con sesión, o cualquiera con la clave pública anon, puede leer todas las filas.
- Auth que solo esconde botones. La página de administración no aparece en el menú, pero la API que hay detrás acepta a cualquier usuario.
- Paquetes alucinados. La IA importa un paquete que no existe o uno con un nombre casi igual. Un atacante puede publicar un paquete malicioso con ese nombre.
- Sin límites de peticiones. Registro, recuperación de contraseña, envío de emails y endpoints de IA se pueden llamar miles de veces, lo que te cuesta dinero o hace que bloqueen tu dominio.
Un hallazgo de ejemplo
Crítico: cualquier usuario puede leer todos los pedidos. La tabla
ordersde Supabase tiene row-level security desactivada. Con la clave pública anon del JavaScript de la app, listamos todos los pedidos con nombres y direcciones de clientes. Solución: activar RLS y añadir una política que solo permita seleccionar filas conuser_id = auth.uid(); probar con dos cuentas; revisar los logs de acceso en busca de lecturas masivas.
Lo que no hacemos
No reescribimos tu app ni te decimos que dejes de usar herramientas de IA. Nosotros también las usamos. Revisamos lo que han producido y te ayudamos a poner las salvaguardas que faltan.
Preguntas frecuentes
¿Es segura mi app si la he hecho con Lovable, Bolt o Cursor?
Puede que sí, pero desde fuera no se sabe. Estas herramientas generan código que funciona en una demo y a menudo se saltan reglas de acceso, gestión de secretos y límites de peticiones. La única forma de saberlo es probarlo, que es lo que hace esta auditoría.
¿Cuánto cuesta una auditoría de seguridad de una app hecha con IA?
Desde 1.500 € sin IVA para una app web típica. Recibes un precio cerrado antes de empezar.
¿Cuánto tarda?
De 3 a 5 días laborables. Si encontramos algo crítico, como una base de datos abierta o una clave filtrada, te lo decimos el mismo día en lugar de esperar al informe.
¿Cuáles son los fallos más habituales que revisáis?
Claves de API enviadas al navegador, tablas de Supabase sin row-level security, usuarios que ven datos de otros, paquetes que la IA se ha inventado o ha escrito mal, rutas de administración sin comprobaciones y endpoints sin límite de peticiones que un atacante puede usar para dispararte la factura.
¿Puedo arreglar los problemas yo mismo con la misma herramienta de IA?
Muchas veces, sí. Para cada hallazgo te damos una descripción precisa y, cuando ayuda, un prompt o un parche. Después volvemos a revisar, porque a veces la IA cierra un agujero y abre otro.
¿Necesitáis acceso a mi base de datos de producción?
No. Trabajamos con el código y una cuenta de prueba. Si hay que revisar reglas de base de datos, usamos un proyecto de staging o datos de prueba.
¿Lanzas pronto? Revísalo antes
Cuéntanos qué has construido y con qué herramientas. Te confirmamos alcance y precio, y normalmente empezamos en menos de una semana.