Checklist de seguridad antes de lanzar tu startup SaaS

Por el equipo de QuantumSec

Estás a punto de lanzar. El producto funciona, el equipo está emocionado, los primeros usuarios esperan. Antes de pulsar el botón, hay una serie de controles de seguridad que deberías haber revisado. No para ser perfecto (ningún sistema lo es), sino para no cometer los errores que hacen que un breach sea cuestión de días en lugar de años.

Autenticación y gestión de sesiones

☐ Contraseñas hasheadas con bcrypt, scrypt o Argon2 (nunca MD5 o SHA1). ☐ Autenticación de doble factor (MFA) disponible para usuarios, obligatoria para admins. ☐ Tokens de sesión con expiración y revocación. ☐ Protección contra fuerza bruta: rate limiting y bloqueo temporal de cuentas. ☐ Flujo de recuperación de contraseña seguro (tokens de un solo uso con expiración corta). ☐ OAuth/OIDC correctamente configurado si usas login social.

Cifrado y protección de datos

☐ HTTPS en toda la aplicación con TLS 1.2+ (preferiblemente TLS 1.3). ☐ Datos sensibles cifrados en reposo (datos de pago, datos de salud, datos personales críticos). ☐ Certificados SSL/TLS válidos y con renovación automática (Let's Encrypt). ☐ Headers de seguridad HTTP: HSTS, CSP, X-Frame-Options, X-Content-Type-Options. ☐ Política de cookies: Secure, HttpOnly, SameSite.

Gestión de secretos y configuración

☐ Sin credenciales ni API keys en el código fuente ni en el repositorio git. ☐ Secretos gestionados con un servicio dedicado (AWS Secrets Manager, HashiCorp Vault, Doppler). ☐ Variables de entorno separadas por entorno (dev, staging, prod). ☐ .gitignore correctamente configurado para excluir ficheros .env. ☐ Revisión del historial de git para asegurarse de que nunca se committieron secretos.

Validación de entradas y protección contra inyecciones

☐ Toda la entrada de usuario es validada en el servidor (nunca solo en el cliente). ☐ Queries a base de datos parametrizadas u ORM (nunca concatenación de strings). ☐ Sanitización de HTML para prevenir XSS (DOMPurify o equivalente). ☐ Protección CSRF en formularios y mutations. ☐ Rate limiting en todas las APIs públicas.

Control de accesos y autorización

☐ Principio de mínimo privilegio: cada usuario solo accede a lo que necesita. ☐ Verificación de autorización en el servidor en cada endpoint (no solo en el frontend). ☐ Tests de IDOR: ¿puede el usuario A acceder a los recursos del usuario B cambiando el ID? ☐ Separación clara entre roles (admin, usuario, solo lectura, etc.). ☐ Acceso a funciones administrativas restringido por IP o requiere MFA adicional.

Logging, monitorización y respuesta a incidentes

☐ Logs de autenticación: intentos fallidos, cambios de contraseña, accesos desde nuevas IPs. ☐ Logs de acciones sensibles: borrado de datos, cambios de configuración, exportaciones. ☐ Alertas para patrones anómalos: múltiples fallos de login, scraping, accesos a horas inusuales. ☐ Plan básico de respuesta a incidentes documentado: a quién notificar, cómo contener, cómo comunicar. ☐ Proceso documentado de notificación de breach bajo GDPR (72 horas a la AEPD).

FAQ

¿Tengo que implementar todo esto desde el día uno?

Los puntos de la sección de autenticación, cifrado y gestión de secretos: sí, desde el día uno. Son el suelo mínimo de cualquier aplicación web. El resto puedes priorizarlo por el tipo de datos que manejas y el perfil de tus primeros usuarios. Pero ten en cuenta que es mucho más fácil y barato implementarlos desde el inicio que remediarlo después con usuarios reales.

¿Este checklist es suficiente o necesito también un pentesting?

El checklist te ayuda a no cometer los errores más obvios. El pentesting te dice si, aun siguiendo el checklist, hay vulnerabilidades en tu implementación específica que un atacante podría explotar. Ambos son complementarios: el checklist es tu línea base, el pentesting valida que la has alcanzado realmente.