Testing de Seguridad
Autenticación, autorización y áreas comunes de vulnerabilidad, SAST vs. DAST, y por qué no es responsabilidad exclusiva del equipo de seguridad.
Qué es
El testing de seguridad busca identificar vulnerabilidades y evaluar si el sistema protege correctamente la autenticación, autorización, confidencialidad, integridad, acceso a datos, gestión de sesiones y manejo de entradas. En ReservaResto, preguntas típicas serían:
¿Puede un usuario cancelar la reserva de otro adivinando el ID?
¿Puede un request sin autenticar acceder al endpoint interno que lista teléfonos de comensales?
¿Puede un input malicioso en el buscador por zona alterar la query?
Áreas comunes
Entre otras: SQL Injection, XSS, CSRF, broken authentication, broken authorization, insecure direct object references, exposición de datos sensibles y vulnerabilidades en dependencias.
El testing de seguridad no es exclusivamente responsabilidad del security team. Debe incorporarse en diseño, implementación, testing, deployment y operaciones, no aparecer como un checkpoint al final. Muchas de las decisiones que lo hacen posible se toman antes: quién puede ejecutar un refund, dónde viven los secrets y cómo se auditan las operaciones sensibles son drivers de arquitectura, no detalles de implementación.
Testing de Seguridad Estático vs. Dinámico
SAST (Static Application Security Testing)
Código fuente → se analiza sin ejecutar → vulnerabilidades detectadas antes del deploy
DAST (Dynamic Application Security Testing)
Aplicación corriendo → se ataca / analiza en runtime → vulnerabilidades explotables detectadas en vivo
SAST analiza el código sin ejecutar la aplicación. DAST ataca o analiza la aplicación mientras está corriendo. A esto se suman herramientas de dependency scanning que complementan ambos enfoques. Ninguno reemplaza al otro: SAST detecta temprano, en el código; DAST detecta lo que solo se manifiesta en runtime.
