Las 10 medidas de seguridad mínimas que toda app hecha con IA (vibe coding) debe tener

Si programás con ayuda de IA —Claude Code, Cursor, Replit, v0, Bolt, lo que sea— seguro ya sentiste esa mezcla de asombro y vértigo: en minutos tenés una app funcionando, pero ¿qué tan segura es realmente? La respuesta honesta, la mayoría de las veces, es: no mucho.

Las IAs generativas son extraordinarias resolviendo el "que funcione", pero tienden a priorizar la funcionalidad visible por sobre la seguridad invisible. Nadie te pide explícitamente "protegé esto de inyección SQL" y la IA, salvo que se lo pidas, no lo hace por vos. El resultado: apps que se ven profesionales por fuera pero que por dentro tienen la puerta de atrás abierta.

Esto no es teoría. Auditando proyectos reales hechos con vibe coding me encontré con casos como: claves de API de Firebase commiteadas públicamente en el repo, sistemas de pago completamente simulados en el cliente, datos de usuario guardados solo en localStorage (editables desde la consola del navegador), y roles de usuario ("admin", "premium") que se podían escalar manipulando el estado del lado del cliente. Todo esto en apps que "funcionaban perfecto".

Acá van las 10 medidas mínimas que no deberían faltar en ninguna app, la hayas escrito vos línea por línea o se la hayas pedido a una IA.

1. Nunca confíes en el cliente (client-side validation no es seguridad)

Todo lo que corre en el navegador puede ser leído, modificado o directamente ignorado por el usuario. Si tu única validación de "el usuario tiene 500 puntos" o "el precio es $10" vive en React o en el estado de tu app, cualquiera con las herramientas de desarrollador abiertas puede alterarlo.

Regla de oro: toda regla de negocio crítica (precios, permisos, puntajes, roles) debe validarse en el servidor, nunca solo en el cliente.

2. Sanitizá y parametrizá cada consulta a la base de datos

La inyección SQL sigue siendo, décadas después, una de las vulnerabilidades más comunes y más devastadoras. Si tu IA te generó queries armadas con concatenación de strings ("SELECT * FROM users WHERE id = " + userId), tenés un problema.

Usá siempre queries parametrizadas o un ORM (Prisma, Drizzle, Supabase client) que las maneje por vos. Si trabajás con Supabase o Firebase, esto además significa usar correctamente las funciones del SDK en vez de construir strings a mano.

3. Configurá Row Level Security (RLS) o reglas de seguridad desde el día uno

Si usás Supabase (PostgreSQL) o Firebase (Firestore), tener la base de datos abierta sin reglas es como dejar la puerta de tu casa abierta con un cartel de "pasen y sírvanse". Es sorprendentemente común en apps vibe-coded porque en el modo desarrollo todo "funciona" sin reglas activadas.

    • En Supabase: activá RLS en cada tabla y escribí políticas explícitas por operación (SELECT, INSERT, UPDATE, DELETE).

    • En Firebase: definí Security Rules que verifiquen autenticación y ownership de los datos, nunca reglas tipo allow read, write: if true.

4. Jamás expongas claves secretas en el frontend

Las claves de API, tokens de servicio, y credenciales service_role deben vivir exclusivamente en el servidor (variables de entorno en Vercel, funciones serverless, Edge Functions), nunca en código que se envía al navegador ni en repos públicos de GitHub.

Un error clásico: usar la clave service_role de Supabase (que se salta todas las reglas de RLS) directamente en el cliente porque "así funcionaba más rápido". Esa clave nunca debe salir del backend.

5. Implementá rate limiting para prevenir ataques DoS y abuso de API

Sin límites de frecuencia, cualquier endpoint público —un formulario de contacto, un login, una API de IA que consume créditos— puede ser bombardeado con miles de solicitudes por segundo, tirando abajo tu servicio o vaciando tu billetera en costos de infraestructura.

Herramientas accesibles: Vercel Edge Middleware con rate limiting, Upstash Redis para contadores distribuidos, o servicios como Cloudflare delante de tu app.

6. Autenticación robusta, no "de mentira"

Un sistema de login que guarda isLoggedIn: true en el localStorage no es autenticación, es una sugerencia. Usá proveedores probados (Supabase Auth, Firebase Auth, NextAuth/Auth.js, Clerk) que manejen correctamente:

    • Hashing de contraseñas (nunca texto plano).

    • Tokens con expiración y refresco seguro.

    • Verificación de email cuando corresponda.

    • Protección contra fuerza bruta en el login.

7. Control de acceso basado en roles, verificado en el servidor

Si tu app tiene roles (admin, editor, usuario gratuito, premium), ese rol tiene que verificarse en cada request del backend, no solo ocultando un botón en la interfaz. Ocultar el botón de "Eliminar usuario" en el frontend no evita que alguien llame directamente al endpoint que borra usuarios.

8. Validá y sanitizá todo input, incluyendo lo que suba el usuario

Formularios, uploads de archivos, comentarios, nombres de perfil: todo input de usuario es una superficie de ataque potencial (XSS, inyección de código, archivos maliciosos disfrazados de imágenes). Validá tipo, tamaño y contenido tanto en frontend (para UX) como en backend (para seguridad real).

9. Nunca simules procesos de pago o lógica financiera crítica sin validación real

Vi apps donde el "sistema de pago" simplemente cambiaba una variable de estado en el cliente a pagado: true sin ninguna verificación real con la pasarela de pago (Stripe, PayPal, Pi SDK). Eso no es un sistema de pagos, es una invitación a que cualquiera se dé acceso premium gratis.

Toda confirmación de pago debe validarse del lado del servidor mediante webhooks firmados y verificados criptográficamente por el proveedor de pagos.

10. Hacé una auditoría de seguridad antes de lanzar a producción

Antes de publicar, revisá manualmente (o con ayuda de la misma IA, pidiéndole explícitamente que audite) al menos:

    • Que no haya claves secretas en el repo (git log incluido, no solo el estado actual).

    • Que las reglas de base de datos estén activas y sean restrictivas por defecto.

    • Que los endpoints críticos requieran autenticación.

    • Que no haya lógica de negocio importante corriendo solo en el cliente.

Herramientas como gitleaks o truffleHog para detectar secretos filtrados en el historial de Git son gratuitas y toman minutos en correr.

La conclusión incómoda

El vibe coding no es inseguro por naturaleza: es inseguro cuando asumimos que "si funciona, está bien". La IA te va a dar el camino más corto para que la funcionalidad ande, y la seguridad casi nunca es parte de ese camino corto salvo que se lo pidas explícitamente, con detalle, y más de una vez.

La buena noticia es que la misma IA que te ayudó a construir la app puede ayudarte a blindarla, si sabés qué pedirle. Por eso armé una guía complementaria con los 10 prompts exactos que podés usar con Claude, Cursor o cualquier asistente de código para auditar y reforzar la seguridad de tu proyecto — la vas a encontrar en este enlace.