Seguridad en SaaS: Cómo Proteger tu Aplicación Siguiendo OWASP Top 10

La seguridad no es una característica que se agrega al final del desarrollo. Es una propiedad que se construye desde el primer commit. Para un SaaS, una brecha de seguridad puede significar pérdida de datos de clientes, multas regulatorias, daño reputacional irreversible y, en el peor caso, el fin del negocio. Esta guía cubre las vulnerabilidades más comunes del OWASP Top 10 y cómo prevenirlas en un stack moderno de SaaS.

A01: Control de Acceso Roto (Broken Access Control)

La vulnerabilidad más común en aplicaciones web. Ocurre cuando un usuario puede acceder a recursos o realizar acciones que no debería. En un SaaS multi-tenant, el riesgo es que un usuario de la organización A acceda a datos de la organización B.

Prevención: Valida el tenantId del usuario autenticado en CADA query a la base de datos, no solo en el middleware de rutas
Implementación: Row Level Security (RLS) en PostgreSQL como segunda capa de defensa. Si tu ORM olvida el filtro, la DB lo rechaza
Prueba: Con Postman o curl, intenta acceder a recursos de otro tenant usando un token válido pero del tenant equivocado — debe retornar 403 o 404
Error común: Confiar solo en el ID enviado en el body/query de la request en lugar de extraerlo del token JWT

A02: Fallas Criptográficas

Exposición de datos sensibles por uso incorrecto de criptografía: contraseñas en texto plano, tokens predecibles, o datos sensibles en logs.

Contraseñas: Usa bcrypt (cost factor 12+) o Argon2id para hashear contraseñas. Nunca MD5 o SHA1
Datos sensibles en transit: HTTPS en todos los endpoints, sin excepciones. Stripe, Clerk y Supabase lo hacen automáticamente
API Keys y secrets: Nunca en el código fuente. Usa variables de entorno y servicios como Vercel Environment Variables o AWS Secrets Manager
Datos en reposo: Encripta columnas con datos especialmente sensibles (tarjetas, datos médicos, NIT/RFC) a nivel de aplicación

A03: Inyección (SQL, NoSQL, Command)

Los ataques de inyección ocurren cuando datos no confiables son enviados a un intérprete. En 2026, los ORMs modernos casi eliminan la inyección SQL, pero persisten en código legacy o queries crudas.

Usa Prisma o Drizzle: Los ORMs con queries tipadas previenen inyección SQL por diseño
Si usas raw queries: Siempre usa prepared statements con parámetros, nunca concatenación de strings
Validación de inputs: Usa Zod para validar y sanitizar todos los inputs del usuario en el servidor antes de procesarlos
Inyección en prompts de IA: Sanitiza los inputs del usuario antes de incluirlos en prompts de LLMs para prevenir prompt injection

A07: Cross-Site Scripting (XSS)

XSS permite a un atacante inyectar scripts maliciosos en páginas vistas por otros usuarios. En aplicaciones React modernas el riesgo es reducido, pero existen vectores específicos a vigilar.

React escapa automáticamente el contenido de las expresiones JSX — no uses dangerouslySetInnerHTML con datos del usuario
Content Security Policy (CSP): Configura headers CSP en Vercel (vercel.json o Next.js headers()) para restringir qué scripts pueden ejecutarse
Sanitiza HTML: Si necesitas renderizar HTML del usuario (editor de texto), usa DOMPurify antes de insertar en el DOM
HTTPOnly cookies: Los tokens de sesión deben ser HTTPOnly para que JavaScript no pueda leerlos

A09: Fallas en el Registro y Monitoreo

Un SaaS sin monitoreo adecuado no puede detectar ataques en curso ni investigar incidentes post-facto.

Sentry: Captura errores no manejados con contexto completo (usuario, request, stack trace)
Audit log: Registra acciones sensibles (login, cambio de contraseña, eliminación de datos, cambio de rol) con timestamp y IP
Alertas de anomalías: Configura alertas para patrones inusuales: muchos logins fallidos, acceso desde IPs inusuales, eliminación masiva de datos
Retención de logs: Conserva logs de seguridad al menos 90 días para investigación de incidentes

Rate Limiting y Protección contra Abuso

No está en el OWASP Top 10 pero es crítico para un SaaS:

Rate limiting en auth: Máximo 5-10 intentos de login por IP por minuto con bloqueo temporal
Rate limiting en API: Por usuario y por IP para prevenir abuso de recursos compartidos
Vercel Edge Middleware: Implementa rate limiting sin infraestructura adicional usando Upstash Redis
Protección contra bots: Turnstile de Cloudflare (gratis, GDPR compliant) en formularios de registro y login

Checklist de Seguridad Pre-Launch

☐ HTTPS en todos los endpoints (Vercel lo hace automáticamente)
☐ Variables de entorno para todos los secrets (no en el código)
☐ RLS habilitado en Supabase si usas shared schema
☐ Validación de inputs con Zod en todos los endpoints API
☐ Rate limiting en endpoints de autenticación
☐ Headers de seguridad: CSP, HSTS, X-Frame-Options
☐ Sentry configurado en producción
☐ Dependencias actualizadas (npm audit sin vulnerabilidades críticas)
☐ Audit log para acciones sensibles
☐ Backup automático de la base de datos

Conclusión

Implementar seguridad en un SaaS no requiere ser un experto en ciberseguridad. Requiere disciplina: usar las herramientas correctas (ORM, HTTPS automático, validación de inputs), no tomar atajos que comprometan la seguridad y monitorear activamente. En GENERA incluimos estas prácticas de seguridad como parte estándar de cada proyecto SaaS que construimos, no como un add-on opcional.