Hvordan kontrollerer du responsserialiseringen i NestJS?

Question

Accepted Answer

**Serialisering** kontrollerer, hvordan objekter transformeres til det JSON, der sendes i responses — afgørende set **ekskluderer sensitive felter** (som adgangskoder) og former outputtet. NestJS håndterer dette med `ClassSerializerInterceptor` og `class-transformer` dekoratører.

## Problemet: lækage af sensitive data

```ts
// ❌ returning an entity directly leaks the password hash!
@Get(":id")
findOne(@Param("id") id: string) {
  return this.usersService.findOne(id);   // { id, name, email, password: "$2b$..." } 😱
}
```

At returnere databaseentiteter direkte kan eksponere felter, der aldrig skulle nå klienten (adgangskode-hashes, interne flags, tokens) — et alvorligt sikkerhed-/privatlivsproblem.

## Løsningen: @Exclude og ClassSerializerInterceptor

```ts
import { Exclude } from "class-transformer";

export class User {
  id: number;
  name: string;
  email: string;

@Exclude()                    // this field is REMOVED from responses
  password: string;
}
```

```ts
// 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` dekoratører, når responses serialiseres, så `@Exclude()` felter fjernes automatisk — men **kun hvis du returnerer klasseinstanser** (ikke almindelige objekter).

## Flere transformationsdekoratører

```ts
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;
}
```

## Du skal returnere klasseinstanser

```ts
// ⚠️ 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!
```

En almindelig fælde: serialiseringsdekoratører fungerer kun på faktiske klasseinstanser, så du skal returnere en instans (ORM-entiteter er normalt instanser; manuelt opbyggede almindelige objekter kræver konvertering).

## Alternativ: dedikerede response DTOer

```text
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.
```

## Hvorfor det betyder noget

At kontrollere responsserialiseringen er vigtig for både **sikkerhed** og rent API-design.

Den vigtigste grund er at forhindre **lækage af sensitive data** — at returnere databaseentiteter direkte kan eksponere adgangskode-hashes, interne felter, tokens eller anden data, der aldrig må nå klienter, en hyppig og alvorlig sårbarhed.

NestJS's `ClassSerializerInterceptor` med `class-transformer` dekoratører (`@Exclude`, `@Expose`, `@Transform`) giver en ren, deklarativ måde at forme responses — automatisk fjerner ekskluderede felter, omdøber og transformerer værdier.

At forstå dette er vigtig dagligdags viden for ethvert API, der returnerer bruger- eller domænedata, og at kende den vigtigste fælde — at **serialisering kun fungerer på klasseinstanser, ikke almindelige objekter** (en hyppig kilde til "hvorfor vises adgangskoden stadig?" fejl) — er praktisk vigtig.

Ligeso værdifuldt er det at genkende det alternative mønster med **dedikerede response DTOer** (kortlægning af entiteter til eksplicitte outputklasser, der kun indeholder klient-sikre felter), som dekoblinger API-kontrakten fra databasemodellen og er den sikreste tilgang til sensitive data.

At kontrollere serialiseringen korrekt er et kendetegn på sikre, veldesignede NestJS APIer og en hyppigt relevant bekymring i virkelige applikationer, der håndterer ikke-offentlige data.