¿Tu app es segura? 3 validaciones antes de lanzar
No necesitas ser experto en ciberseguridad para aplicar un nivel de protección decente. Necesitas tres hábitos y dos herramientas.
Construir rápido tiene un precio que no siempre se ve en el momento: el código que genera la IA funciona, pero no siempre es seguro. Y "funciona" y "es seguro" son dos propiedades distintas.
Hola, soy Pol Marzà, AI Product Builder y cada semana escribo una nueva edición de Con Criterio, la newsletter sobre construir productos digitales con IA, con planificación, método y sin atajos. Si te han reenviado este email, puedes suscribirte aquí:
Hoy hablaremos de seguridad en nuestros desarrollos 🤓
Te hago un pequeño resumen por si quieres ir directamente a ese apartado que más te interese:
Las imperdibles— Variables de entorno, RLS en Supabase y rotación de keys: lo que ninguna herramienta puede compensar si lo ignoras.
/security-reviewen Claude Code — El comando nativo de Anthropic que audita tu código antes de cada deploy, sin configuración.Aikido: escaneo continuo — Conecta tu repositorio y vigila vulnerabilidades en segundo plano, gratis hasta 10 repos.
Bonus: pentesting en Lovable — Agentes que atacan tu app en vivo para encontrar lo que el análisis estático no ve.
Ahora sí, ¡empezamos!
1. Las imperdibles
Antes de hablar de herramientas, hay decisiones de arquitectura que ningún escáner puede compensar si las ignoras desde el principio.
Nunca hardcodees credenciales en el código. Las API keys, tokens de base de datos y secrets no deben estar escritos en ningún archivo de tu repositorio, ni en comentarios, ni en archivos de configuración que subes a GitHub. Esto parece obvio hasta que ves a alguien publicar un repo con las keys de Stripe expuestas.
La alternativa es usar variables de entorno. En Vercel las gestionas desde el panel del proyecto (Settings → Environment Variables). En Supabase tienes las claves de servicio accesibles desde Project Settings → API. Tu código lee esas variables pero nunca las contiene.
Activa Row Level Security en Supabase desde el inicio. Si construyes con Supabase y no activas RLS en tus tablas, cualquier usuario autenticado puede leer (o modificar) los datos de cualquier otro usuario. No es una vulnerabilidad avanzada, es la configuración por defecto cuando creas una tabla sin políticas.
Actívalo al crear la tabla, no después. Añadirlo retroactivamente cuando ya tienes datos y lógica construida es más costoso y más fácil de hacer mal.
Rota las keys si sospechas una exposición. Si en algún momento una key estuvo en un commit, en un mensaje de chat, o en cualquier lugar fuera de las variables de entorno, invalídala y genera una nueva. El tiempo que tardas en rotar es menor que el daño potencial.
2. Auditoría con Claude Code: el comando /security-review
Claude Code incluye por defecto un slash command mantenido por Anthropic llamado /security-review. No hay que instalarlo ni configurarlo: está ahí desde el primer momento.
Lo que hace es analizar los cambios pendientes en tu codebase buscando vulnerabilidades reales y explotables. No es una búsqueda por patrones superficiales: examina el código en contexto, entiende qué hace cada parte y filtra los falsos positivos para darte solo hallazgos que merecen atención.
Las categorías que cubre:
Inyección de SQL, comandos y otros vectores de inyección
Problemas de autenticación y autorización (escalada de privilegios, bypass de sesiones)
Exposición de datos sensibles y secrets en el código
Problemas criptográficos
Configuraciones inseguras
Cómo usarlo: abre Claude Code en tu proyecto, escribe /security-review y deja que analice. El momento ideal es antes de cada deploy relevante, especialmente si has tocado autenticación, esquema de base de datos o endpoints de API.
También puedes integrarlo en GitHub Actions para que revise automáticamente cada pull request. El repositorio oficial de Anthropic (anthropics/claude-code-security-review) tiene el workflow listo para copiar.
Un par de enlaces de interés:
Documentación oficial sobre /security-review en el blog de Anthropic.
Repositorio oficial en Github.
3. Aikido: escaneo continuo del repositorio
/security-review analiza tus cambios de forma manual y bajo demanda. Aikido hace algo diferente: conecta con tu repositorio de GitHub, lo escanea de forma automática cada pocos días y te avisa cuando encuentra algo.
El plan gratuito incluye hasta 10 repositorios, 2 usuarios y escaneo básico. Para un builder individual o un equipo pequeño es suficiente para tener visibilidad continua sin pagar nada.
Lo que escanea en el plan gratuito:
SCA (Software Composition Analysis): vulnerabilidades conocidas en tus dependencias npm. Las librerías que instalas también tienen CVEs, y Aikido los detecta antes de que alguien los explote.
SAST (Static Application Security Testing): análisis estático del código buscando patrones de vulnerabilidad.
Detección de secrets: credenciales que pudieran haberse filtrado en el repositorio.
Escaneo de cloud: misconfigurations en tu cuenta de Vercel, AWS o GCP si la conectas.
La diferencia respecto a otras herramientas similares es la reducción de ruido. Contextualiza los hallazgos según tu entorno real y descarta los que no suponen un riesgo efectivo. Menos alertas, más señal.
Cómo empezar: entra en aikido.dev, conecta tu cuenta de GitHub y selecciona los repositorios que quieras monitorizar. El primer escaneo tarda entre 1 y 5 minutos.
Bonus track: pentesting con Aikido en Lovable
Si construyes con Lovable, hay una capa adicional disponible desde marzo de 2026: pentesting con IA directamente integrado en el editor.
La distinción importante es que el escáner de seguridad de Lovable (que ya existía) hace análisis estático: lee el código y detecta patrones problemáticos. El pentesting de Aikido hace análisis dinámico: despliega agentes que atacan la aplicación en vivo, como lo haría un atacante real. Prueban flujos de autenticación, intentan acceder a datos de otros usuarios, sondean las APIs.
Las dos cosas son complementarias:
El estático detecta lo que podría ir mal en el código.
El dinámico detecta lo que efectivamente se rompe cuando alguien lo intenta.
Para proyectos en Lovable, el precio de lanzamiento es de 100 dólares por test. También hay “Security weekends” gratuitos anunciados puntualmente. El modelo de pago es cómodo: puedes iniciar el pentest sin pagar y solo desbloqueas el informe completo si decides que los hallazgos merecen el coste.
El flujo desde Lovable: Settings → Connectors → App connectors → Aikido. Desde ahí puedes lanzar el test y los hallazgos se sincronizan directamente en tu proyecto para corregirlos sin salir del editor.
El orden lógico
Las tres validaciones no son alternativas, son capas:
Las buenas prácticas son el suelo. Sin ellas, nada de lo demás importa.
/security-reviewes la revisión activa antes de cada deploy importante.Aikido es la vigilancia continua en segundo plano.
El pentesting es el siguiente paso cuando el producto ya está en producción y quieres poder demostrar, no solo suponer, que es seguro.
Construir rápido no obliga a construir inseguro. Solo requiere que estas validaciones sean parte del flujo desde el principio, no algo que se añade cuando ya hay un problema.
Si este post te resulta útil, ¿qué te parece si lo compartes? 😜
¡Y hasta aquí la newsletter de esta semana! Espero que no haya sido muy densa.
Lo bueno de todo esto es que, como digo al final, ¡lo puedes empezar a aplicar desde YA! No esperes a que salgan errores.
¡Nos vemos la próxima semana!
Un abrazo.