Autenticación y control de acceso
Gestión de sesiones, verificación de firmas JWT, protección a nivel de ruta, filtros de propietario y aislamiento entre clientes. Es una superficie de alto impacto que comprobamos explícitamente.
Servicio · Auditoría de código IA
Audita el código que envió tu IA.
Cursor, v0, Lovable, Copilot o cualquier otra IA te ha llevado a un producto funcional más rápido de lo que parecía posible. Ahora los usuarios reales, la carga de producción o un proceso de due diligence exigen certeza sobre lo que hay realmente en la base de código. Nosotros la leemos como la leería un ingeniero sénior antes de una adquisición, nombramos lo que está roto o es un riesgo, y te decimos qué arreglar primero.
Qué es
Una auditoría humana
del código que escribió la IA.
Lo construyó tu IA. Nos aseguramos de que no se rompa, filtre datos ni acabe comprometido.
Las herramientas de codificación con IA entregan funcionalidad de superficie a velocidad de vértigo. También pueden introducir errores sutiles en los filtros de propietario, tablas públicas en Supabase, claves de servidor filtradas al cliente, dependencias inventadas y rutas de API sin proteger, con seguridad, en código que pasa una revisión rápida sin que salte nada. Son modos de fallo plausibles que merecen verificación antes de que aparezcan bajo carga, en una auditoría externa o en el postmortem de un incidente.
Leemos tu base de código como la leería un ingeniero que la mira para una operación de adquisición: línea por línea, con los modos de fallo de tu herramienta concreta presentes. Recibes un informe escrito ordenado por gravedad, una revisión en directo y 30 días de seguimiento mientras vais arreglando.
Qué auditamos
Ocho superficies que leemos con cuidado.
Secretos y configuración
Credenciales en el repositorio o en el historial de git, claves de servidor filtradas al bundle del cliente, higiene de variables de entorno y la frontera entre configuración pública y privada.
Integridad y privacidad de datos
Reglas de acceso a base de datos (RLS de Supabase, reglas de Firebase), datos personales en logs, exposición RGPD, flujos de prompt-a-base-de-datos y qué pasa cuando la IA tiene permiso para escribir consultas.
Dependencias y cadena de suministro
Higiene del lockfile, paquetes inventados o con typosquatting, dependencias transitivas vulnerables, origen de los paquetes y el npm install que la IA ejecutó sin pedir permiso.
Riesgo específico de LLM
Caminos de prompt injection, exfiltración del system prompt, ausencia de límites en llamadas caras al modelo, huecos de moderación de contenido y la frontera de confianza alrededor de la salida del modelo.
Infraestructura y runtime
Configuración de CORS, gestión de errores, logs, límites de uso, topología de despliegue y qué hay expuesto a internet que probablemente no debería estarlo.
Rendimiento y coste
Consultas N+1, bucles que no terminan, gasto descontrolado en modelos, huecos de caché y las operaciones que convierten a un usuario de 20 € en uno de 2.000 € de la noche a la mañana.
Operabilidad
Observabilidad, alertas, superficie de guardia y caminos de recuperación. Si algo se rompe a las tres de la mañana, ¿alguien se entera?
Auditoría por sector
Riesgos y controles dentro de tu contexto operativo.
Servicios profesionales
Menos tiempo en documentos, propuestas, investigación, informes y gestión de clientes.
Ver enfoque →Inmobiliario y gestión de propiedades
Automatización de contactos, visitas, documentación, incidencias y comunicación multilingüe.
Ver enfoque →Hoteles y turismo
Atención 24/7, respuestas multilingües, gestión de solicitudes, venta adicional y análisis de reseñas.
Ver enfoque →Distribución e industria B2B
Cotizaciones, soporte comercial, previsión, documentación técnica y seguimiento operativo.
Ver enfoque →Catálogo ilustrativo
Hallazgos de muestra de una auditoría sintética.
Ejemplos compuestos para mostrar el tipo de riesgo y el nivel de detalle del informe; no describen proyectos ni resultados de clientes.
Todos los nombres, herramientas, rutas, cuentas, respuestas y efectos de este catálogo son ficticios o compuestos. Sirven únicamente para ilustrar posibles hallazgos y no deben interpretarse como casos reales, incidencias confirmadas ni resultados de clientes.
Críticov0
Tablas públicas en Supabase tras una UI con apariencia privada
En esta muestra ficticia, la app protegía cada pantalla detrás de un login, pero el row-level security estaba deshabilitado en tres tablas. La clave anónima, diseñada para ser pública, leía la lista de clientes entera desde un navegador.
CríticoLovable
Clave service_role enviada al navegador
En esta muestra ficticia, una clave service_role de Supabase quedó incrustada en el bundle de JavaScript para que la subida al storage funcionara. Cualquier visitante con DevTools podía escribir filas arbitrarias en cualquier tabla del proyecto.
CríticoCursor
Fuga entre clientes por filtro de propietario ausente
En esta muestra ficticia, el endpoint de detalle de factura aceptaba cualquier id en la URL y devolvía la fila. Dos cuentas sembradas podían leerse las facturas mutuamente cambiando un número.
MedioClaude Code
Dependencia inventada en el lockfile
En esta muestra ficticia, el paquete sugerido por la IA no existía en el primer commit y después apareció como un nombre casi idéntico con un payload de postinstall.
AltoMVP construido con ChatGPT
Prompt injection en un agente con acceso de escritura a la base de datos
En esta muestra ficticia, el texto de un formulario de soporte fluía sin tratar al contexto del agente. Una entrada adversa consiguió que el agente llamara a una herramienta de borrado que tenía permisos excesivos.
Cómo funciona
De cinco a diez días hábiles.
Con acceso de lectura al repositorio basta para arrancar. No necesitamos desplegar nada en tu infraestructura, ni credenciales más allá de lo que tendría cualquier persona haciendo revisión de código.
01
Arranque
Llamada de 30 minutos: qué herramienta lo construyó, qué stack, qué hay en producción, dónde están las costuras. Confirmamos alcance y firmamos lo que haya que firmar.
02
Auditoría estática y dinámica
Lectura línea por línea de cada archivo relevante. Herramientas automáticas encima de la lectura, no en lugar de ella. Pruebas en runtime de los endpoints públicos cuando proceda.
03
Revisión en directo
Llamada de 60 minutos repasando el informe, la gravedad, el orden de arreglo y las preguntas que tu equipo va a tener cuando lo lea.
04
Seguimiento de 30 días
Ventana por Slack o correo para aclaraciones, revisión de arreglos y un segundo vistazo a lo que cambies. Re-auditoría a coste si el código se mueve mucho.
Metodología pública
Qué comprobamos y cómo lo comprobamos.
Acordamos el alcance y el modelo de amenazas antes de revisar. La evidencia manual manda; las herramientas automáticas apoyan la revisión, pero no sustituyen el criterio humano ni permiten prometer seguridad absoluta.
Metodología revisada:
Cobertura mínima de la revisión
Auth
Identidad y autorización
Sesiones, firmas de tokens, guards de rutas, recuperación de cuenta y decisiones de autorización derivadas en servidor, no de datos controlados por el cliente.
Secretos
Secretos y configuración
Variables de entorno, historial de git, bundles de cliente, logs y fronteras entre claves públicas, privadas y privilegiadas.
Tenancy
Aislamiento entre clientes
Identificadores manipulables, filtros de propietario, RLS, storage y pruebas negativas entre dos tenants sembrados cuando el entorno autorizado lo permite.
Cadena
Cadena de suministro
Lockfiles, origen y ciclo de vida de paquetes, versiones vulnerables, nombres parecidos, scripts de instalación y coherencia entre código y despliegue.
Entradas
Validación de entradas
Esquemas en la frontera, subidas de archivos, consultas SQL, comandos, webhooks y salidas que llegan a HTML, logs u otros sistemas.
LLM
Riesgo específico de LLM
Prompt injection, permisos de herramientas, exposición de contexto, tratamiento de salida no fiable, límites de uso y control de coste del modelo.
Despliegue
Runtime y operación
Headers, CORS, errores, logs, exposición pública, configuración del runtime, monitorización, backups y caminos de recuperación visibles en el alcance.
Etapas de revisión
- 01
Alcance y modelo de amenazas
Inventariamos repositorios, entornos, datos sensibles, roles, fronteras de confianza, exclusiones y pruebas autorizadas.
- 02
Revisión estática manual y asistida
Seguimos flujos de datos y privilegios en código, configuración, migraciones y lockfiles; los escáneres solo aportan señales que después verificamos.
- 03
Pruebas dinámicas y negativas
En un entorno autorizado comprobamos controles con entradas adversas, identidades de distinto rol y accesos entre tenants sin ejecutar acciones destructivas fuera de alcance.
- 04
Clasificación e informe
Cada hallazgo incluye evidencia reproducible, impacto contextual, prioridad, propuesta de corrección y pasos concretos de retest.
- 05
Revisión y retest
Recorremos el informe con el equipo y verificamos las correcciones acordadas contra el caso original y una prueba de regresión.
Rúbrica de gravedad
La gravedad combina impacto y probabilidad en el contexto acordado; no copiamos sin más la puntuación de un escáner. Los plazos son objetivos orientativos para priorizar, no garantías universales.
| Nivel | Criterio | Respuesta orientativa |
|---|---|---|
| Crítico | Compromiso directo de datos, cuentas o control privilegiado, reproducible y con pocas barreras. | Contener de inmediato; corregir antes de lanzar o mantener expuesto. |
| Alto | Impacto importante con una ruta de explotación creíble o un control esencial ausente. | Priorizar en el ciclo actual y aplicar mitigación temporal si sigue expuesto. |
| Medio | Impacto o explotabilidad limitados, o riesgo que requiere varias condiciones. | Planificar corrección y prueba de regresión en el siguiente ciclo razonable. |
| Bajo | Endurecimiento, exposición mínima o mejora de defensa en profundidad. | Registrar y resolver junto con mantenimiento relacionado. |
Referencias de la metodología
Usamos estos estándares públicos para ordenar cobertura, nombrar debilidades y comunicar gravedad. El alcance acordado y la evidencia del sistema siguen determinando cada conclusión.
- OWASP ASVS 5.0.0Requisitos verificables para controles técnicos de seguridad en aplicaciones web.
- OWASP Top 10:2025Documento vigente de concienciación sobre los riesgos más críticos de aplicaciones web.
- OWASP Top 10 for LLM Applications 2025Riesgos y mitigaciones específicos del ciclo de vida de aplicaciones con LLM y GenAI.
- MITRE CWETaxonomía común para describir la causa técnica de debilidades de software y hardware.
- FIRST CVSS v4.0Marco para comunicar características y gravedad técnica; lo contextualizamos con impacto y probabilidad.
Informe de muestra
Así documentamos un hallazgo.
Muestra ficticia · no es un caso de cliente
Este informe es un ejemplo sintético y compuesto. Los nombres, código, rutas, cuentas, respuestas y métricas se han inventado únicamente para enseñar el formato del entregable; no representan una auditoría ni resultados reales.
Proyecto ficticio
LedgerFox · SaaS B2B con Next.js y Supabase
Alcance y supuestos de la muestra
La muestra supone una revisión de solo lectura y pruebas no destructivas en staging, acordadas previamente con el propietario del sistema.
- Repositorio, lockfile, migraciones y plantilla de variables de entorno.
- Flujos de login, API de facturas, panel de administración, base de datos y storage.
- Staging autorizado con dos cuentas sembradas de empresas distintas.
- Pagos, consola del proveedor y controles de infraestructura de producción quedan excluidos.
Hallazgo ficticio · SYN-AUTH-001Crítico
El endpoint de facturas permite leer datos de otro tenant
El identificador de factura llega desde la URL y la consulta devuelve la fila sin vincularla al tenant de la sesión. La interfaz oculta facturas ajenas, pero el control no existe en la API ni en la política de base de datos de este ejemplo.
Evidencia reproducible de muestra
- Ruta ficticia app/api/invoices/[id]/route.ts, líneas 24–31: la consulta filtra solo por id.
- Con la sesión sembrada de Tenant B, GET /api/invoices/inv_tenant_a_104 devuelve 200 y el JSON de Tenant A.
- La tabla ficticia invoices no tiene una política RLS que compare tenant_id con la identidad autenticada.
Impacto
Un usuario autenticado que obtenga o adivine otro identificador podría leer facturas, importes y datos de contacto de otra empresa. En este escenario sintético, la confidencialidad entre clientes queda rota.
Corrección propuesta
- Derivar usuario y tenant de la sesión verificada en servidor; nunca aceptar tenant_id del cliente.
- Exigir tenant_id en la consulta y una política RLS equivalente como control independiente.
- Usar identificadores opacos solo como defensa adicional, no como autorización.
- Añadir una prueba negativa entre tenants al conjunto de regresión.
Criterios de retest
- La cuenta de Tenant B recibe 403 o 404 para la factura de Tenant A.
- La cuenta de Tenant A conserva un 200 para su propia factura.
- Una consulta directa con el rol autenticado también queda bloqueada por RLS.
- La prueba negativa se ejecuta en CI y falla si reaparece la lectura cruzada.
Limitaciones y exclusiones
- La revisión es una instantánea del código, configuración y entorno incluidos en la fecha acordada.
- No es una certificación legal, de cumplimiento ni una garantía de ausencia total de vulnerabilidades.
- No incluye carga destructiva, ingeniería social ni explotación de terceros salvo acuerdo expreso.
- Los controles internos de proveedores solo se evalúan hasta donde los hace visibles la configuración disponible.
- Cualquier prueba intrusiva en producción requiere autorización escrita y un alcance específico.
Aplicarlo a tu base de código
El diagnóstico fija alcance, activos, entornos y permisos antes de compartir código. Si ya tienes esa información, puedes escribirnos directamente.
Qué te llevas
Cinco entregables al final del proceso.
Informe escrito (PDF)
Hallazgos ordenados por gravedad, con rutas de archivo, referencias de línea, motivo y boceto de arreglo. Legible tanto por ingeniería como por roles no técnicos.
Vídeo Loom de repaso
Grabación de 15 minutos del informe, para el socio, inversor o director que no asistió a la llamada en directo.
Llamada de revisión de 60 minutos
Conversación en vivo sobre gravedad, orden de arreglo y las decisiones que requieren a una persona en el bucle.
Ventana de seguimiento de 30 días
Slack o correo para aclaraciones, revisión de arreglos y un segundo par de ojos sobre los parches.
Plazo: 5 a 10 días hábiles
Base de código típica de pyme construida con IA, desde el arranque hasta el informe. Auditorías más grandes o multi-repo se cotizan aparte.
Para quién es
Tres situaciones donde encaja.
El fundador
Has lanzado un MVP con v0 o Lovable. Funciona, los usuarios se están dando de alta y estás a punto de activar pagos o migrar a una base de datos seria. Necesitas que alguien que no seas tú confirme que no hay un agujero.
El responsable técnico
Has heredado una base de código construida con Cursor o Copilot, de un contractor, de una acqui-hire o de los primeros seis meses del fundador. Necesitas una lectura defendible de lo que tienes realmente antes de empezar a tocarlo.
La agencia
Estás a punto de entregar un proyecto construido con IA a un cliente. Quieres la firma de un tercero sobre la postura de seguridad para que la entrega no se convierta en un informe de incidente dos meses después.
¿Es seguro mandaros el código?
+
Trabajamos bajo NDA y con acceso de solo lectura. No guardamos copias después de cerrar el encargo, no entrenamos modelos con tu código y no subcontratamos.
¿Firmáis NDA?
+
Sí. Podemos firmar el tuyo o mandar el nuestro. En cualquier caso, antes de que compartas nada.
¿Arregláis lo que encontráis o solo lo señaláis?
+
Las dos cosas. El encargo por defecto es solo auditoría para mantener la revisión independiente. Si prefieres que arreglemos hallazgos concretos, lo cotizamos como un encargo adicional.
¿En qué se diferencia esto de una auditoría de seguridad genérica?
+
Las auditorías genéricas buscan el OWASP top 10 en código escrito a mano. Nosotros buscamos los patrones específicos que producen las herramientas de IA, claves de Supabase filtradas, RLS ausente, dependencias inventadas, superficies de prompt injection, que una auditoría genérica se salta porque no conoce los modos de fallo de la herramienta.
¿Necesitáis saber con qué IA lo construimos?
+
Ayuda, pero no es imprescindible. Solemos detectarlo desde el código en la primera hora. Saberlo de antemano simplemente nos permite enfocar la auditoría más rápido.
¿Y si nuestra app no está construida con IA?
+
La auditamos igual, tenemos un servicio de revisión de código clásico. El ángulo de IA es la cuña porque ahí está el volumen de riesgo ahora mismo, no lo único que leemos.
¿Qué stacks cubrís?
+
Next.js, Remix, SvelteKit, React Native, Express, Fastify, Hono, Python (FastAPI, Flask, Django), Supabase, Firebase, Postgres, Vercel, Cloudflare, Hetzner. Si tu stack no aparece en la lista, pregúntanos.
Otros servicios
Automatización con IA
Procesos repetitivos de administración interna funcionando sin supervisión, con registros y revisión humana.
Leer más →Agentes de IA
Asistentes conversacionales de varios pasos para soporte, ventas y documentación interna.
Leer más →IA a medida
Clasificadores, extractores y modelos de puntuación entrenados con tus datos y tu dominio.
Leer más →Integraciones CRM/ERP
Conectar la IA con Salesforce, HubSpot, SAP, Holded, Odoo y el resto de tu stack.
Leer más →Confianza
IA segura, trazable,
preparada para empresa.
Diseñamos soluciones con privacidad desde el inicio, control humano, trazabilidad, límites de uso, gestión de permisos y documentación. Para procesos sensibles, ayudamos a evaluar los riesgos y obligaciones aplicables bajo el RGPD y el Reglamento de IA.
- 01No entrenamos modelos con tus datos sin autorización explícita.
- 02Revisión humana incorporada cuando el riesgo del proceso lo requiere.
- 03Trazabilidad: instrucciones, fuentes, permisos, errores y métricas documentados.
- 04Privacidad, seguridad y control integrados desde el diseño.
- 05Soluciones que se pueden mantener, auditar y mejorar con el tiempo.
RGPDReglamento de IAAEPDPreparado para ISO 27001Datos alojados en la UE
Diagnóstico personal
Trabajamos con
pocos clientes.
Cada proyecto lo lidera personalmente uno de los socios. Si hay encaje, te respondemos en menos de 24 horas con una primera lectura concreta de tu caso, no con una demostración genérica.
Cómo trabajamos
- 01Nos cuentas qué proceso te quita tiempo
- 02Te respondemos personalmente en < 24 h
- 03Llamada de 20 min, sin demostración ni discurso comercial