Serialization controls how objects are transformed into the JSON sent in responses — crucially, excluding sensitive fields (like passwords) and shaping the output. NestJS handles this with the ClassSerializerInterceptor and class-transformer decorators.
()
() {
..(id);
}
Returning database entities directly can expose fields that should never reach the client (password hashes, internal flags, tokens) — a serious security/privacy issue.
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)))
The ClassSerializerInterceptor applies class-transformer decorators when serializing responses, so @Exclude() fields are automatically removed — but only if you return class instances (not plain objects).
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!
A common gotcha: serialization decorators only work on actual class instances, so you must return an instance (ORM entities are usually instances; manually-built plain objects need conversion).
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.
Controlling response serialization is important for both security and clean API design.
The most critical reason is preventing sensitive data leaks — returning database entities directly can expose password hashes, internal fields, tokens, or other data that must never reach clients, a common and serious vulnerability.
NestJS's ClassSerializerInterceptor with class-transformer decorators (@Exclude, @Expose, @Transform) provides a clean, declarative way to shape responses — automatically stripping excluded fields, renaming, and transforming values.
Understanding this is essential everyday knowledge for any API that returns user or domain data, and knowing the key gotcha — that serialization only works on class instances, not plain objects (a frequent source of "why is the password still showing?" bugs) — is practically important.
Equally valuable is recognizing the alternative pattern of dedicated response DTOs (mapping entities to explicit output classes containing only client-safe fields), which decouples the API contract from the database model and is the safest approach for sensitive data.
Properly controlling serialization is a hallmark of secure, well-designed NestJS APIs and a frequently-relevant concern in real applications handling any non-public data.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate