Serialisierung kontrolliert, wie Objekte in das in Responses versendete JSON transformiert werden — entscheidend ist das Ausschließen sensibler Felder (wie Passwörter) und die Formung der Ausgabe. NestJS handhabt dies mit dem ClassSerializerInterceptor und class-transformer Dekoratoren.
()
() {
..(id);
}
Das direkte Zurückgeben von Datenbank-Entities kann Felder offenlegen, die den Client niemals erreichen sollten (Password-Hashes, interne Flags, Tokens) — ein ernstes Sicherheits-/Datenschutzproblem.
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)))
Der ClassSerializerInterceptor wendet class-transformer Dekoratoren beim Serialisieren von Responses an, sodass @Exclude() Felder automatisch entfernt werden — aber nur wenn du Class-Instanzen zurückgibst (nicht einfache Objekte).
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!
Eine häufige Fallstricke: Serialisierungs-Dekoratoren funktionieren nur bei echten Class-Instanzen, daher musst du eine Instanz zurückgeben (ORM-Entities sind normalerweise Instanzen; manuell erstellte einfache Objekte benötigen eine Konvertierung).
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.
Die Kontrolle der Response-Serialisierung ist wichtig für sowohl Sicherheit als auch sauberes API-Design.
Der kritischste Grund ist die Vermeidung von Datenlecks bei sensiblen Daten — das direkte Zurückgeben von Database-Entities kann Password-Hashes, interne Felder, Tokens oder andere Daten offenlegen, die auf keinen Fall Clients erreichen dürfen, eine häufige und ernsthafte Sicherheitslücke.
Der ClassSerializerInterceptor von NestJS mit class-transformer Dekoratoren (@Exclude, @Expose, @Transform) bietet eine saubere, deklarative Möglichkeit, Responses zu gestalten — automatisches Entfernen ausgeschlossener Felder, Umbenennung und Transformation von Werten.
Dies zu verstehen ist essentielles alltägliches Wissen für jede API, die Benutzer- oder Domain-Daten zurückgibt, und das Kennen des Schlüssel-Fallstrickes — dass Serialisierung nur auf Class-Instanzen funktioniert, nicht auf einfachen Objekten (eine häufige Quelle von "warum wird das Password immer noch angezeigt?" Bugs) — ist praktisch wichtig.
Ebenso wertvoll ist das Erkennen des alternativen Musters von dedizierten Response-DTOs (Mapping von Entities zu expliziten Output-Klassen mit nur Client-sicheren Feldern), das den API-Vertrag vom Datenbank-Modell entkoppelt und der sicherste Ansatz für sensible Daten ist.
Die richtige Kontrolle der Serialisierung ist ein Merkmal sicherer, gut gestalteter NestJS-APIs und eine häufig relevante Überlegung in echten Anwendungen, die mit nicht-öffentlichen Daten umgehen.