HACER CUMPLIR la validación de entrada del lado del servidor en la capa límite antes de que los datos lleguen a la lógica de negocio o base de datos. Usar Zod 4 (TS/Node), Pydantic (Python) o go-playground/validator (Go). Nunca confiar en la validación del lado del cliente. Prevenir asignación masiva, confusión de tipos y agotamiento de búfer. Activadores: "create an API endpoint", "handle a form submission", "save user data", "build a backend route".
HACER CUMPLIR la validación de entrada del lado del servidor en la capa límite antes de que los datos lleguen a la lógica de negocio o base de datos. Usar Zod 4 (TS/Node), Pydantic (Python) o go-playground/validator (Go). Nunca confiar en la validación del lado del cliente. Prevenir asignación masiva, confusión de tipos y agotamiento de búfer. Activadores: "create an API endpoint", "handle a form submission", "save user data", "build a backend route".
Activar siempre que el código RECIBA entrada de una fuente externa:
Datos de formulario enviados por el usuario o cargas útiles API
Webhooks de terceros
Parámetros de URL o cadenas de consulta
Cargas de archivos
PRINCIPIO FUNDAMENTAL
Validar en el límite, luego confiar internamente. Cada carga útil entrante DEBE verificarse contra un esquema antes de que se ejecute cualquier lógica de negocio. La entrada inválida recibe una respuesta inmediata de clase 400, la ejecución NO continúa más allá de la capa de validación.
SELECCIÓN DE BIBLIOTECA (2026)
Stack
Biblioteca
Versión
Característica Clave
TypeScript / Node.js
Zod
v4
Esquema + análisis en un paso. z.object({...}).strict()
Python
Pydantic
v2
Modelos basados en clases con anotaciones de tipo
Go
go-playground/validator
v10
Etiquetas de struct para reglas de validación
Ruby
ActiveModel::Validations
(integrado)
Integrado en Rails
EJECUTAR: Instrucciones
Paso 1: Definir Esquema Antes del Manejador de Ruta
Define el esquema como una exportación con nombre separada. NO lo incluyas dentro del manejador de ruta.
// ❌ EN LÍNEA, no reutilizable, satura el manejador de ruta
post
'/users'
async
const
object
strict
// No incluir en línea
REGLAS:
SIEMPRE establecer .max() en campos de cadena, previene el agotamiento de búfer (una cadena de 10MB puede bloquear el servidor)
SIEMPRE usar .strict() o .strip(), rechaza/elimina campos desconocidos. Defensa principal contra asignación masiva.
SIEMPRE establecer .min() y .max() en campos numéricos
SIEMPRE usar .default() para campos opcionales con valores predeterminados sensatos
Paso 2: Analizar en el Límite: Antes de Cualquier Otra Lógica
La validación DEBE ser la primera operación absoluta. NO obtener datos, verificar autenticación o registrar antes de la validación.
// ✅ ORDEN CORRECTO: validar → autenticar → lógica de negociofunctionvalidate(schema: z.ZodSchema) {
return(req: Request, res: Response, next: NextFunction) => {
const result = schema.safeParse(req.body);
if (!result.success) {
return res.status(400).json({
error: 'Validation failed',
details: result.error.flatten().fieldErrors,
});
}
req.body = result.data; // Reemplazar cuerpo crudo con datos validados+eliminadosnext();
};
}
app.post('/api/users', validate(CreateUserSchema), authenticate, async (req, res) => {
const user = await db.user.create({ data: req.body }); // req.body ahora es seguro
});
Paso 3: Devolver Errores Estructurados a Nivel de Campo
SIEMPRE devolver errores que el cliente pueda mapear a campos de formulario:
// ✅ ANALIZABLE, errores a nivel de campo para mostrar en formulario
{
"error": "Validation failed",
"details": {
"email": ["Formato de correo inválido"],
"name": ["Requerido", "Debe tener como máximo 100 caracteres"]
}
}
// ❌ NO ANALIZABLE, cadena que el cliente no puede mostrar de forma confiable"El correo es inválido"
Paso 4: Solo Usar Datos Validados Aguas Abajo
Después de la validación, NUNCA referenciar la entrada cruda. Usar SOLO el resultado analizado:
