Serialización controla cómo los objetos se transforman en el JSON enviado en respuestas — crucialmente, excluyendo campos sensibles (como contraseñas) y dando forma a la salida. NestJS maneja esto con el ClassSerializerInterceptor y decoradores de class-transformer.
()
() {
..(id);
}
Devolver entidades de base de datos directamente puede exponer campos que nunca deberían llegar al cliente (hashes de contraseñas, banderas internas, tokens) — un problema serio de seguridad/privacidad.
import { Exclude } from "class-transformer";
export class User {
id: number;
name: string;
email: string;
@Exclude() // this field is REMOVED from responses
password: string;
}
// enable the serializer interceptor (globally or per-controller)
@UseInterceptors(ClassSerializerInterceptor)
@Controller("users")
export class UsersController {
@Get(":id")
findOne(@Param("id") id): User {
return this.usersService.findOne(id); // password is automatically stripped
}
}
// or globally: app.useGlobalInterceptors(new ClassSerializerInterceptor(app.get(Reflector)))
El ClassSerializerInterceptor aplica decoradores de class-transformer al serializar respuestas, por lo que los campos con @Exclude() se eliminan automáticamente — pero solo si devuelves instancias de clase (no objetos planos).
export class User {
@Expose() id: number; // explicitly include (with excludeAll strategy)
@Exclude() password: string; // remove from output
@Expose({ name: "full_name" }) // rename in the output
name: string;
@Transform(({ value }) => value.toUpperCase()) // transform the value
code: string;
@Exclude({ toPlainOnly: true }) // exclude only when serializing OUT (not on input)
internalField: string;
}
// ⚠️ the interceptor only transforms CLASS INSTANCES — plain objects pass through unchanged
return new User(data); // ✅ decorators apply
return plainToInstance(User, data); // ✅ convert a plain object to an instance
return { ...data }; // ❌ plain object — @Exclude is IGNORED!
Una trampa común: los decoradores de serialización solo funcionan en instancias reales de clase, así que debes devolver una instancia (las entidades ORM suelen ser instancias; los objetos planos construidos manualmente necesitan conversión).
Instead of decorating entities, map to a separate Response DTO containing only the
fields meant for the client — explicit, decoupled from the DB model, and very safe.
Controlar la serialización de respuestas es importante tanto para seguridad como para diseño limpio de API.
La razón más crítica es prevenir fugas de datos sensibles — devolver entidades de base de datos directamente puede exponer hashes de contraseñas, campos internos, tokens u otros datos que nunca deben llegar a los clientes, una vulnerabilidad común y seria.
El ClassSerializerInterceptor de NestJS con decoradores de class-transformer (@Exclude, @Expose, @Transform) proporciona una forma limpia y declarativa de dar forma a respuestas — eliminando automáticamente campos excluidos, renombrando y transformando valores.
Comprender esto es conocimiento esencial día a día para cualquier API que devuelva datos de usuario o dominio, y conocer la trampa clave — que la serialización solo funciona en instancias de clase, no en objetos planos (una fuente frecuente de errores "¿por qué la contraseña sigue mostrándose?") — es prácticamente importante.
Igualmente valioso es reconocer el patrón alternativo de DTOs de respuesta dedicados (mapeando entidades a clases de salida explícitas que contienen solo campos seguros para el cliente), que desacopla el contrato de API del modelo de base de datos y es el enfoque más seguro para datos sensibles.
Controlar adecuadamente la serialización es un sello distintivo de APIs NestJS seguras y bien diseñadas, y una preocupación frecuentemente relevante en aplicaciones reales que manejan datos no públicos.