¿Tu SaaS es seguro? Checklist de 9 señales: haz el autodiagnóstico antes de que se convierta en un problema.

Checklist

9 señales de alerta para SaaS B2B

Marca mentalmente cuáles se aplican a tu caso. Cada señal que identifiques es un punto de riesgo real — no un checklist genérico.

1. 01

   No tienes un pentest documentado en los últimos 12 meses

   Sin un pentest reciente, no sabes si estás seguro — solo sabes que aún no te han atacado, que es algo muy distinto. Cada feature que llegó a producción en ese intervalo es un riesgo sin probar.

2. 02

   Tu cumplimiento de privacidad se reduce a la política de privacidad

   La política de privacidad cubre el lado jurídico. Pero las leyes de protección de datos también exigen medidas técnicas: en la LGPD de Brasil, por ejemplo, la política responde al Art. 9 y las medidas técnicas, al Art. 46. Sin evidencia técnica documentada, quedas descubierto ante una fiscalización del regulador (como la ANPD en Brasil) o una due diligence enterprise.

3. 03

   Tu equipo nunca probó “¿y si cambio el ID en la URL?”

   BOLA (Broken Object Level Authorization) es la vulnerabilidad n.º 1 del OWASP API Top 10. Casi todo SaaS B2B en producción tiene al menos un endpoint vulnerable. Si nadie probó el acceso cross-tenant de forma manual, eres vulnerable hasta que se demuestre lo contrario.

4. 04

   Tu OAuth nunca pasó por una prueba de state confusion

   El login social (Google, Microsoft, Apple) tiene patrones clásicos de account takeover vía state confusion, fuzzing de redirect URI y code injection. Los investigadores de bug bounty ganan miles de dólares encontrando esto en SaaS reconocidos. Si nunca lo probaste, eres candidato.

5. 05

   Permites que tus clientes configuren la URL de un webhook

   Si es así, necesitas bloquear los rangos privados (127.0.0.1, 169.254.169.254, 10.0.0.0/8) en la petición saliente. Sin eso, un atacante apunta el webhook a la metadata de AWS y exfiltra credenciales IAM. Pivot hacia toda la infraestructura.

6. 06

   Tus endpoints de billing y cupones nunca se probaron contra race conditions

   El HTTP/2 single-packet attack envía 30 peticiones en el mismo paquete TCP. Sin un lock atómico, todas se procesan en paralelo: un cupón de un solo uso se aplica 30 veces, se consume saldo negativo, se hace bypass de MFA con una race en el código OTP. Un bug clásico en productos con flujos financieros.

7. 07

   Corres un escáner cada mes y sales “limpio”

   Nessus, Acunetix y Burp Pro en modo automatizado encuentran XSS triviales y versiones desactualizadas. No encuentran BOLA, account takeover vía OAuth, race conditions, cadenas de SSRF, JWT confusion ni abuso de lógica de negocio — que son los vectores detrás de la mayoría de las brechas en 2026.

8. 08

   Tu equipo de ingeniería no está entrenado en “pensamiento adversarial”

   Al dev se le entrena para construir. Al investigador, para romper. Son mentalidades opuestas. En el code review, el dev valida que la feature funcione según la especificación — no que NO haga lo que no debería. Resultado: features que llegan a producción con cobertura de pruebas positivas, pero cero pruebas adversariales.

9. 09

   No tienes un plan de respuesta a incidentes documentado

   Cuando haya una filtración (o peor, cuando descubras una de hace 3 meses), ¿qué haces en las primeras 24 horas? Tendrás que notificar a la autoridad de protección de datos dentro del plazo de la ley aplicable (en Brasil, el Art. 48 de la LGPD exige comunicarlo a la ANPD en un plazo de 3 días hábiles, según la Resolución CD/ANPD n.º 15/2024). Sin un playbook escrito de antemano, tomas malas decisiones bajo presión — y el daño regulatorio empeora.

Preguntas frecuentes

• ¿Cómo saber si mi SaaS es seguro?

  La única forma confiable es un pentest manual hecho por un investigador humano. Un escáner automatizado detecta XSS triviales y versiones desactualizadas — pero no BOLA cross-tenant, account takeover vía OAuth, race conditions ni cadenas de SSRF, que dominan los ataques en 2026. Como diagnóstico inicial, usa el checklist de 9 señales de esta página: si identificas 3 o más, tu plataforma probablemente tiene una vulnerabilidad crítica.

• ¿Qué señales indican que un SaaS puede ser vulnerable?

  9 señales prácticas: (1) sin pentest documentado en los últimos 12 meses; (2) cumplimiento de privacidad solo en lo jurídico; (3) nadie probó BOLA cross-tenant de forma manual; (4) OAuth nunca pasó por una prueba de state confusion; (5) webhooks que aceptan URLs sin allowlist; (6) endpoints de billing nunca probados contra race conditions; (7) confianza exclusiva en un escáner automatizado; (8) equipo sin entrenamiento adversarial; (9) sin plan de respuesta a incidentes.

• ¿Puedo hacer el diagnóstico por mi cuenta?

  Para un diagnóstico de SUPERFICIE, sí — el checklist de esta página te da una primera idea. Pero para confirmar si existen vulnerabilidades reales, necesitas un pentest manual: un investigador atacando tu aplicación como lo haría un atacante real, con una PoC reproducible para cada hallazgo. El autodiagnóstico indica RIESGO; un pentest documentado indica VULNERABILIDADES específicas.

• ¿Cuánto se tarda en detectar una intrusión en un SaaS?

  En promedio, las organizaciones tardan meses en detectar una intrusión si no tienen herramientas dedicadas. En un SaaS B2B sin SIEM ni monitoreo activo de logs, un atacante sofisticado puede pasar inadvertido durante trimestres. Por eso el pentest periódico es importante: encuentra las vulnerabilidades ANTES de que el atacante las explote y evita el daño de un descubrimiento tardío.

• ¿Un sitio web, un SaaS y una app tienen el mismo perfil de riesgo?

  No. Un sitio institucional simple (sin login) tiene un riesgo limitado: defacement, XSS, filtración de formularios. Un SaaS B2B tiene riesgo multi-tenant — que un cliente vea los datos de otro —, y eso es catastrófico: viola el contrato y la normativa de protección de datos, y liquida la renovación. Una app móvil suma riesgos de ingeniería inversa, secretos hardcodeados y deeplink hijacking. Cada uno exige una cobertura específica.

• ¿La LGPD de Brasil se aplica a un SaaS B2B?

  Sí, por completo, si tu SaaS trata datos personales de personas en Brasil. Aunque tus clientes sean empresas, los usuarios finales son personas físicas. Se aplican todos los artículos: Art. 7 (bases legales), Art. 9 (información al titular), Art. 18 (derechos), Art. 37 (registro del tratamiento), Art. 46 (medidas técnicas de seguridad) y Art. 48 (notificación de incidentes). Una filtración activa obligaciones de comunicación ante la ANPD, la autoridad brasileña de protección de datos.

• ¿Qué hacer si identificas una vulnerabilidad crítica?

  (1) No la expongas públicamente en redes sociales ni en la prensa — los atacantes están atentos. (2) Confirma si fue explotada (logs, comportamiento anómalo). (3) Corrígela de inmediato en un ambiente aislado. (4) Evalúa el impacto (cuántos clientes afectados, qué datos quedaron expuestos). (5) Si hubo filtración, prepara la notificación a la autoridad de protección de datos dentro del plazo de la ley aplicable (por ejemplo, a la ANPD en Brasil, según el Art. 48 de la LGPD). (6) Contrata un pentest de validación para confirmar la corrección e identificar bugs relacionados.

• ¿Cómo distinguir un pentest serio de un escáner con nombre de pentest?

  Un pentest serio tiene: investigadores con trayectoria pública (programas internacionales de bug bounty, CVEs, charlas), una PoC reproducible en cada hallazgo, severidad calibrada (CVSS 4.0 + impacto de negocio), retest incluido, comunicación directa con el investigador e informe con formato para el auditor. Un escáner con nombre de pentest entrega un PDF con capturas de Nessus/Acunetix, sin PoC manual.