Saltar al contenido
Lección 8 de 8

Codificación Segura y Herramientas

10 min read

La Mentalidad del Secure Coding

A lo largo del curso hemos visto vulnerabilidad por vulnerabilidad. Esta última lección reúne las defensas en un conjunto coherente de prácticas y herramientas. El secure coding no es una lista de trucos, sino una mentalidad: asumir que toda entrada es potencialmente maliciosa, que toda confianza debe justificarse y que la seguridad es una propiedad que se diseña, no que se añade al final.

Esta mentalidad se concreta en un puñado de principios que se repiten en casi todas las defensas que hemos estudiado. Vale la pena enunciarlos con precisión, porque son la síntesis de todo el curso:

  • Validar la entrada. Nunca confíes en datos que cruzan un límite de confianza. Lo vimos en la inyección: los datos del usuario no deben interpretarse como código.
  • Codificar la salida. Trata cada dato según el intérprete al que se dirige. Es el corazón de la defensa contra XSS y contra la inyección en general.
  • Denegar por defecto. El acceso, las rutas y las capacidades deben estar cerrados salvo permiso explícito. El control de acceso roto casi siempre nace de un "permitir por defecto".
  • Mínimo privilegio. Cada componente, usuario y credencial recibe solo lo estrictamente necesario. Limita el radio de daño de una cuenta o una clave comprometida.
  • Defensa en profundidad. No apuestes a un único control. Si uno falla, otro debe contener el impacto; así ninguna clase de fallo se vuelve catastrófica por sí sola.
  • Fallar de forma segura. Ante un error, el sistema debe quedar en el estado más restrictivo, nunca abrir la puerta. Un catch que otorga acceso "por si acaso" es una vulnerabilidad.

Si internalizas estos principios, podrás razonar sobre vulnerabilidades que aún no conoces, no solo sobre las del OWASP Top 10 actual. Recorre mentalmente el curso con esta lente: la inyección se resuelve con parametrización (separar código de datos), el XSS con codificación contextual, los fallos de autenticación con gestión rigurosa de credenciales y sesiones, el control de acceso roto con verificación del lado del servidor en cada objeto, la configuración incorrecta con endurecimiento y denegación por defecto, y el SSRF y los componentes vulnerables con validación de destinos y gestión de dependencias. Cada defensa es un principio aplicado a un contexto. La seguridad cambia; los principios permanecen.

Validación de Entrada y Codificación de Salida

Las dos defensas más transversales merecen una mirada conjunta. La validación de entrada consiste en comprobar que los datos que entran a la aplicación cumplen lo esperado: tipo, formato, longitud y rango. La validación más robusta usa listas de permitidos (allow-lists: definir qué es válido y rechazar todo lo demás) en lugar de listas de denegados (intentar enumerar lo malo, que siempre deja huecos). La validación debe ocurrir en el servidor, recordando que la validación del cliente es solo cosmética y puede saltarse con cualquier proxy.

La codificación de salida es la otra cara: tratar los datos correctamente cuando salen de la aplicación hacia un intérprete, ya sea el navegador, una base de datos o un shell. Es clave entender que validación y codificación resuelven problemas distintos y se complementan: la validación rechaza datos con formato incorrecto, mientras que la codificación neutraliza los datos peligrosos en el contexto donde se usan. Un dato puede ser válido (un nombre con comillas es un nombre legítimo) y aún así requerir codificación al insertarse en HTML o en SQL.

El problema: confiar en la entrada sin validar

Considera un handler de registro en Node/Express que confía en el cuerpo de la petición. La validación es laxa o inexistente, y a lo sumo se apoya en una deny-list ad-hoc que intenta enumerar lo prohibido:

// VULNERABLE: sin esquema, confía en el shape del body y usa deny-list frágil
app.post("/api/register", async (req, res) => {
  const { email, age, role } = req.body;

  // Deny-list ad-hoc: siempre deja huecos (mayúsculas, unicode, etc.)
  if (email && email.includes("<script>")) {
    return res.status(400).send("Entrada inválida");
  }

  // `age` puede llegar como string, objeto o array; `role` sin restringir
  await createUser({ email, age, role });
  res.status(201).send("Usuario creado");
});

Aquí hay varios problemas: no se valida el tipo de age, no se restringe role (un atacante podría enviar role: "admin", un caso de asignación masiva y escalada de privilegios), y la comprobación de email es una deny-list que se evade trivialmente. La causa raíz es confiar en la forma de la entrada.

El fix: allow-list basada en esquema

La solución es una allow-list declarativa: definir un esquema que describa exactamente lo aceptable y rechazar todo lo que no encaje. Con una librería de validación por esquema como zod (o Joi), esto es conciso y se ejecuta en el servidor:

import { z } from "zod";

const RegisterSchema = z.object({
  email: z.string().email().max(254),
  age: z.number().int().min(18).max(120),
  role: z.enum(["user", "editor"]), // 'admin' NO es asignable por el cliente
}).strict(); // rechaza cualquier campo no declarado

app.post("/api/register", async (req, res) => {
  const result = RegisterSchema.safeParse(req.body);

  if (!result.success) {
    // Fallar seguro: rechazar sin filtrar detalles internos
    return res.status(400).json({ error: "Datos de registro inválidos" });
  }

  await createUser(result.data); // datos ya tipados y validados
  res.status(201).send("Usuario creado");
});

El esquema convierte la validación en una allow-list explícita: email debe ser un correo válido y acotado, age un entero en un rango razonable, y role solo puede ser uno de los valores permitidos. El .strict() rechaza campos inesperados, cerrando la puerta a la asignación masiva. Cuando la validación falla, se falla de forma segura devolviendo un error genérico. Fíjate que aquí no intentamos "limpiar" la entrada: la rechazamos si no encaja, que es más seguro y más simple.

Recordatorio integrador: la codificación sigue siendo necesaria

Validar no exime de codificar en la salida. Aunque email haya pasado el esquema, al usarlo hay que respetar el contexto de destino: parametrización hacia la base de datos, codificación contextual hacia el HTML.

// SQL: parametrización (separación de código y datos), nunca concatenación
await db.query("SELECT id FROM users WHERE email = $1", [data.email]);

// HTML: dejar que el framework codifique por contexto (React escapa por defecto);
// evitar innerHTML / dangerouslySetInnerHTML con datos del usuario.

Validación y codificación son capas distintas de la misma defensa en profundidad: la primera decide si el dato entra; la segunda, cómo se representa sin cambiar de significado al cruzar hacia un intérprete.

Herramientas: Burp Suite y OWASP ZAP

Para encontrar vulnerabilidades necesitas herramientas que te dejen ver y manipular el tráfico. Burp Suite es el proxy de interceptación estándar de la industria para pruebas de seguridad web. Se sitúa entre el navegador y el servidor y te permite inspeccionar cada request y response, y modificarlas al vuelo. Sus módulos clave son:

  • Repeater: reenvía una petición una y otra vez con pequeñas variaciones para observar cómo responde el servidor. Es la herramienta ideal para probar hipótesis de forma manual y controlada.
  • Intruder: automatiza el envío de peticiones variando parámetros de forma sistemática, útil para pruebas dirigidas sobre un campo concreto.
  • Scanner: en la versión profesional, un escáner automatizado que recorre la aplicación en busca de patrones conocidos de vulnerabilidad.

OWASP ZAP (Zed Attack Proxy) es la alternativa libre y de código abierto, mantenida por la fundación OWASP. Ofrece funcionalidad de proxy similar, un spider para descubrir contenido siguiendo enlaces, y escaneo pasivo (observa el tráfico que generas normalmente y marca indicios sin enviar ataques) y escaneo activo (envía peticiones diseñadas para provocar comportamientos reveladores). Es excelente tanto para aprender como para integrarse en pipelines automatizados. Ambas herramientas son fundamentales para el testing manual dirigido, especialmente para vulnerabilidades de lógica como el control de acceso roto y las IDOR, que los escáneres automáticos difícilmente detectan por sí solos porque requieren entender la intención del negocio.

SAST, DAST y SCA: Análisis Automatizado

El análisis automatizado de seguridad se apoya en tres enfoques complementarios que cubren momentos y ángulos distintos.

SAST (Static Application Security Testing) analiza el código fuente sin ejecutarlo, buscando patrones inseguros como concatenación de SQL, uso de funciones peligrosas o secretos incrustados. Su ventaja es que se ejecuta temprano, incluso antes de desplegar, y señala la línea exacta del problema; su limitación es que genera falsos positivos y no ve fallos que dependen del entorno de ejecución. Herramientas como Semgrep o CodeQL encajan aquí y se integran bien en cada commit.

DAST (Dynamic Application Security Testing) prueba la aplicación en ejecución, enviándole peticiones y observando las respuestas; OWASP ZAP y el escáner de Burp son herramientas DAST. Ve la aplicación tal como funciona realmente, incluyendo comportamientos que dependen de la configuración y el entorno, pero no señala la línea de código y puede no cubrir todos los caminos.

SCA (Software Composition Analysis) se centra en las dependencias de terceros, comparando tu árbol de paquetes con bases de datos de vulnerabilidades conocidas. Lo vimos en la lección anterior sobre componentes vulnerables; herramientas como Dependabot o Snyk automatizan esta vigilancia y proponen actualizaciones.

Lo ideal es combinar los tres: SAST y SCA integrados en el pipeline de CI/CD para retroalimentación temprana en cada commit, y DAST sobre entornos desplegados donde la aplicación corre de verdad. Ninguna herramienta sustituye a las demás ni al criterio humano: los escáneres encuentran lo conocido y repetitivo, pero los fallos de lógica siguen requiriendo revisión y pruebas manuales.

Integrando la Seguridad en el Ciclo de Vida

La seguridad eficaz no es una fase final ni una auditoría puntual, sino una práctica continua integrada en todo el ciclo de vida del desarrollo, lo que se conoce como DevSecOps o "shift left": desplazar la seguridad hacia las etapas tempranas, donde corregir es más barato. En la práctica, esto significa formar a los desarrolladores, modelar amenazas durante el diseño, integrar SAST/SCA en cada commit, ejecutar DAST en pruebas y realizar revisiones de código con foco en seguridad.

Apóyate en recursos de referencia: el OWASP Top 10 como mapa de riesgos prioritarios, el OWASP ASVS como estándar de verificación con requisitos concretos por nivel, las cheat sheets de OWASP como recetas prácticas, la WSTG (Web Security Testing Guide) como metodología de pruebas, y el catálogo CWE para clasificar debilidades de forma común. Complementa las herramientas automatizadas con pruebas de penetración manuales periódicas y, cuando el alcance lo justifique, programas de divulgación responsable o bug bounty.

Checklist de Prevención

Este es el checklist maestro del curso: recorre las ocho áreas que estudiamos y condensa lo accionable de cada una.

  • Superficie de ataque: minimiza endpoints, funciones y datos expuestos; retira lo que no se usa; conoce y documenta tu superficie.
  • Inyección: usa siempre consultas parametrizadas o un ORM; nunca construyas comandos concatenando entrada del usuario; valida la entrada con allow-lists.
  • XSS: codifica la salida según el contexto; confía en el escape del framework; evita innerHTML/dangerouslySetInnerHTML con datos del usuario; aplica una CSP como defensa en profundidad.
  • Autenticación: almacena contraseñas con hashing lento (bcrypt/argon2); ofrece MFA; gestiona sesiones con cookies seguras; aplica límites de tasa y bloqueos ante fuerza bruta.
  • Control de acceso: deniega por defecto; verifica autorización en el servidor para cada objeto y acción; nunca confíes en identificadores del cliente (evita IDOR).
  • Configuración incorrecta: endurece los valores por defecto; desactiva lo innecesario; gestiona secretos fuera del código; envía las cabeceras de seguridad; no filtres detalles en los errores.
  • SSRF y componentes: valida y restringe destinos de peticiones salientes con allow-lists; mantén las dependencias actualizadas y monitorizadas con SCA.
  • Secure coding y herramientas: valida entrada y codifica salida como hábito; aplica los seis principios en cada decisión; integra SAST, DAST y SCA en el pipeline y complementa con revisión humana.

Recuerda: la meta no es alcanzar una seguridad perfecta (que no existe), sino elevar continuamente el costo para el atacante mientras reduces tu superficie y tu tiempo de respuesta. Con los fundamentos de este curso, tienes el marco para construir aplicaciones web defendibles.