Cuando damos nuestros primeros pasos en el desarrollo web, los tutoriales nos enseñan a crear formularios increíbles. Aprendemos a usar atributos de HTML5 como required o maxlength, y nos apoyamos en las bondades de frameworks como React, Vue o Astro para mostrar mensajes de error en tiempo real si una contraseña es demasiado corta o si un correo no tiene el formato correcto. Al ver que nuestro formulario bloquea el envío de datos incorrectos, sentimos una falsa sensación de seguridad. Pensamos: “Mi aplicación está protegida”.

La dura realidad que todo analista de AppSec debe entender es que la validación en el cliente es excelente para la experiencia de usuario (UX), pero es absolutamente inútil para la seguridad. El navegador web es un entorno hostil que está bajo el control total del usuario. Por lo tanto, cualquier dato, request o archivo que provenga de allí debe ser considerado malicioso hasta que se demuestre lo contrario.

¿Cómo actúan los atacantes?

El principal error de diseño es asumir que todos los usuarios van a interactuar con nuestra API a través de la hermosa interfaz web que hemos construido.

Un atacante real no hace click en tu botón de “Enviar”. Un atacante configura un proxy de interceptación web como Burp Suite, o simplemente utiliza herramientas como Postman o comandos CURL en su terminal.

¿Qué significa esto en la práctica? Que el atacante captura la request HTTP original justo antes de que salga de su computadora, modifica el payload en formato JSON a su antojo y lo envía directamente al endpoint de tu servidor. Al hacer este bypass, las validaciones de tu frontend hechas en JavaScript simplemente dejan de existir. El atacante tiene una línea directa hacia tu backend.

¿Qué pasa cuando confiamos a ciegas?

Cuando un backend asume que el payload recibido ya fue “limpiado” por el frontend, abre la puerta a vectores de ataque devastadores que comprometen la tríada CIA (Confidencialidad, Integridad y Disponibilidad).

• SQL Injection (SQLi) y NoSQL Injection: Si tomas un valor del req.body y lo concatenas directamente en una consulta a tu base de datos, un atacante puede inyectar operadores lógicos para extraer información sensible o destruir tablas enteras.

• Cross-Site Scripting (XSS): Si aceptas un comentario de un usuario sin sanitizarlo y lo guardas en la base de datos, el atacante puede inyectar payloads con etiquetas <script>. Cuando otros usuarios carguen esa página, el código malicioso se ejecutará en sus navegadores, robando sus tokens de sesión.

• Business Logic Flaws (Asignación Masiva): Imagina que tienes un endpoint de registro de usuarios. Tu formulario en React solo envía nombre, email y password. Pero, ¿qué pasa si un atacante usa Burp Suite para inyectar un campo adicional oculto: {"role": "admin"}? Si tu backend toma todo el objeto JSON y lo guarda ciegamente, acabas de otorgarle privilegios de administrador a un atacante.

Validación Estricta en el Backend

El principio fundamental del desarrollo seguro es claro: “Valida en el frontend para mejorar la UX; sanitiza y valida estrictamente en el backend para garantizar la Seguridad”. Para lograr esto de manera escalable, no podemos depender de interminables bloques de if/else, por ejemplo: if (!req.body.email) return error. La solución estándar en la industria es implementar esquemas de validación. Veamos algunos ejemplos practicos:

El Enfoque Vulnerable 🔴

En este ejemplo, el controlador confía ciegamente en el input del cliente. Toma todo el payload e interactúa directamente con la lógica de negocio.

// CONTROLADOR VULNERABLE
app.post('/api/users', async (req, res) => {
  try {
    const userData = req.body

    // PELIGRO: Se guarda directamente en la base de datos
    // ¿Qué pasa si userData incluye "role": "admin"?
    await database.users.create(userData)

    res.status(201).json({ message: 'Usuario creado exitosamente' })
  } catch (error) {
    res.status(500).send('Error del servidor')
  }
})

El Enfoque Seguro 🟢

Para mitigar estos ataques, aplicamos Security by Design utilizando TypeScript y una librería de declaración de esquemas como Zod.

Zod nos permite definir exactamente qué forma deben tener nuestros datos. Además, al utilizar el método .strict(), ordenamos al servidor que rechace y elimine cualquier propiedad no declarada (mitigando los ataques de asignación masiva).

import { z } from 'zod'
import { Request, Response } from 'express'

// Definimos una política de validación estricta
const UserRegistrationSchema = z
  .object({
    username: z.string().min(3).max(20).trim(),
    email: z.string().email().trim(),
    password: z.string().min(12),
    age: z.number().int().positive()
  })
  .strict() // Rechaza cualquier campo extra inyectado por el atacante

// CONTROLADOR SEGURO
app.post('/api/users', async (req: Request, res: Response) => {
  try {
    // Pasamos el payload por el filtro de Zod
    const safeData = UserRegistrationSchema.parse(req.body)

    // A este punto, safeData está 100% validado y tipado
    await database.users.create({
      username: safeData.username,
      email: safeData.email,
      password: safeData.password,
      age: safeData.age,
      role: 'user' // El rol se asigna por defecto en el servidor, no por input
    })

    res.status(201).json({ message: 'Usuario creado exitosamente' })
  } catch (error) {
    // Si la validación falla, bloqueamos la request antes de tocar la DB
    res.status(400).json({ error: 'Payload inválido o manipulado' })
  }
})

Security by Design

La seguridad de las aplicaciones modernas no es una tirita que se pone al final del ciclo de desarrollo usando un escáner de red. La verdad segurida de aplicaciones se construye desde la primera línea de código, en el núcleo de la arquitectura de la API.

Validar el input es la línea de defensa más fundamental y barata de implementar, pero también es la ahorra que más dolores de cabeza a largo plazo.

La próxima vez que diseñes un endpoint, no pienses en cómo se comporta el usuario normal frente a la pantalla. Detente un momento, adopta la mentalidad de un atacante y pregúntate: “¿Qué pasaría si envío este JSON directamente desde Postman?”.