Serialisatie bepaalt hoe objecten worden getransformeerd naar de JSON die in responses wordt verzonden — van cruciaal belang, het uitsluiten van gevoelige velden (zoals wachtwoorden) en het vormgeven van de output. NestJS behandelt dit met de ClassSerializerInterceptor en class-transformer decorators.
()
() {
..(id);
}
Het rechtstreeks retourneren van database-entiteiten kan velden blootstellen die nooit bij de client mogen komen (wachtwoordhashes, interne vlaggen, tokens) — een ernstig beveiligings- en privacyprobleem.
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)))
De ClassSerializerInterceptor past class-transformer decorators toe bij het serialiseren van responses, dus @Exclude() velden worden automatisch verwijderd — maar alleen als je class instances retourneert (niet platte objecten).
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!
Een veelvoorkomende valkuil: serialisatie-decorators werken alleen op werkelijke class instances, dus je moet een instance retourneren (ORM-entiteiten zijn meestal instances; handmatig gebouwde platte objecten hebben conversie nodig).
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.
Het controleren van response-serialisatie is belangrijk voor zowel beveiliging als schoon API-ontwerp.
De meest kritieke reden is het voorkomen van gevoelige gegevenslekken — het rechtstreeks retourneren van database-entiteiten kan wachtwoordhashes, interne velden, tokens of andere gegevens blootstellen die nooit bij clients mogen komen, een veelvoorkomende en ernstige kwetsbaarheid.
De ClassSerializerInterceptor van NestJS met class-transformer decorators (@Exclude, @Expose, @Transform) biedt een schone, declaratieve manier om responses te vormgeven — automatisch uitgesloten velden verwijderen, hernoemen en waarden transformeren.
Het begrijpen hiervan is essentiële alledaagse kennis voor elke API die gebruikers- of domeingegevens retourneert, en het kennen van de sleutelknelpunt — dat serialisatie alleen werkt op class instances, niet op platte objecten (een frequente bron van "waarom wordt het wachtwoord nog steeds weergegeven?" bugs) — is praktisch belangrijk.
Evenso waardevol is het herkennen van het alternatieve patroon van toegewijde response-DTOs (entiteiten toewijzen aan expliciete uitvoerklassen die alleen client-veilige velden bevatten), wat de API-contract ontkoppelt van het databasemodel en de veiligste benadering is voor gevoelige gegevens.
De juiste controle van serialisatie is een kenmerk van veilige, goed ontworpen NestJS-API's en een regelmatig relevant probleem in echte applicaties die niet-openbare gegevens verwerken.