Back home
Writing

Blog

Practical notes from a decade of shipping — backend patterns, SaaS decisions, and the small things that compound.

2024

Securing JSON Responses in NestJS

How @Exclude() prevents data leaks.

4 min

2024

HTTP Methods in NestJS — A Practical Guide

When to GET, POST, PATCH and PUT.

6 min

NestJSSecurityclass-transformer

Securing JSON Responses in NestJS with @Exclude()

4 min read · 2024

When you return a user entity from a NestJS controller, it serializes every property — including the ones you never meant to expose. Passwords, refresh tokens, and internal flags can quietly leak.

The fix is the @Exclude() decorator from class-transformer. Wrap your entity, mark the sensitive fields, and apply the ClassSerializerInterceptor globally:

import { Exclude } from 'class-transformer';

export class User {
  id: string;
  email: string;
  @Exclude() password: string;
  @Exclude() refreshToken?: string;
}

Then in main.ts add the interceptor so every response runs through it. You now ship by default secure — adding a new sensitive field is a one-decorator job, not a one-incident postmortem.

NestJSHTTPREST

HTTP Methods in NestJS — A Practical Guide

6 min read · 2024

GET retrieves. POST creates. PUT replaces. PATCH partially updates. DELETE removes. HEAD returns headers only. OPTIONS describes what's allowed. The semantic difference matters more than the wire format.

NestJS makes each one a decorator: @Get(), @Post(), @Put(), @Patch(), @Delete(), @Head(), @Options(). Pair them with DTOs and validation pipes, and you have a self-documenting contract.

The mistake I see most often: using POST for everything because 'it works.' Caches, retries, idempotency — all of these depend on you picking the right verb. Get this right and your API ages well.

Chat on WhatsApp