Serialiseringen kontrollerer hvordan objekter blir transformert til JSON som sendes i responser — avgjørende for å ekskludere sensitive felt (som passord) og forme utdataene. NestJS håndterer dette med ClassSerializerInterceptor og class-transformer-dekoratorer.
()
() {
..(id);
}
Å returnere databaseenheter direkte kan eksponere felt som aldri skulle nå klienten (passordhasher, interne flagg, tokens) — et alvorlig sikkerhet/personvernproblem.
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)))
ClassSerializerInterceptor anvender class-transformer-dekoratorer når responser serialiseres, så @Exclude()-felt fjernes automatisk — men bare hvis du returnerer klasseinstanser (ikke vanlige objekter).
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!
Et vanlig fallgruve: serialiseringsdekoratorer fungerer bare på faktiske klasseinstanser, så du må returnere en instans (ORM-enheter er vanligvis instanser; manuelt bygde vanlige objekter trenger konvertering).
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.
Å kontrollere responsserialiseringen er viktig for både sikkerhet og ren API-design.
Den mest kritiske grunnen er å forhindre lekkasjer av sensitive data — å returnere databaseenheter direkte kan eksponere passordhasher, interne felt, tokens eller andre data som aldri må nå klienter, en vanlig og alvorlig sårbarhet.
NestJS sin ClassSerializerInterceptor med class-transformer-dekoratorer (@Exclude, @Expose, @Transform) gir en ren, deklarativ måte å forme responser på — automatisk fjerning av ekskluderte felt, omdøping og transformering av verdier.
Å forstå dette er essensielt daglig kunnskap for enhver API som returnerer bruker- eller domenedata, og å kjenne til hovedfallgruven — at serialisering bare fungerer på klasseinstanser, ikke vanlige objekter (en hyppig årsak til "hvorfor vises passordet fortsatt?" bugs) — er praktisk viktig.
Ekstra verdifullt er å gjenkjenne det alternative mønsteret med dedikerte response-DTO-er (kartlegging av enheter til eksplisitte utdataklasser som bare inneholder klientsikre felt), som separerer API-kontrakten fra databasemodellen og er den sikreste tilnærmingen for sensitive data.
Å ordentlig kontrollere serialiseringen er et kjennetegn på sikre, veldesignede NestJS-APIer og en hyppig relevant bekymring i ekte applikasjoner som håndterer ikke-offentlige data.