Saltar al contenido

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.

2 min. de lectura

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.

Te sirvió, compartilo

// ¿te sirvió?
// compartilo