Whitelisting, nested validation and partial updates

whitelist: the field that was never supposed to be there

By default ValidationPipe validates the decorated properties and leaves everything else on the object. A field with no decorator isn’t rejected — it’s ignored by the validator and passed through untouched. That is the entire mechanism behind the incident: an undecorated role is invisible to validation but fully present in the payload your service hands to the ORM.

// main.ts — the hardened global pipe
app.useGlobalPipes(
  new ValidationPipe({
    whitelist: true,            // strip any property with NO validation decorator
    forbidNonWhitelisted: true, // …and 400 instead of silently stripping
    transform: true,            // instantiate the DTO class (also needed for @Type)
  }),
);

whitelist: true flips the default: any property that has no validation decorator on the DTO is stripped off the object before it reaches your handler. The undecorated role and isVerified simply cease to exist. forbidNonWhitelisted: true goes one step further — instead of silently dropping the unknown field, the pipe throws a 400 Bad Request naming it (property role should not exist). Silent stripping is safer-by-default; the forbid variant is louder and catches clients (and your own frontend) sending fields they shouldn’t, which is what you want in a service where an unexpected field is a bug, not noise.

// RegisterDto — only these two fields survive whitelist; role/isVerified get stripped
export class RegisterDto {
  @IsEmail()
  email: string;

  @MinLength(8)
  password: string;
  // note: NO role, NO isVerified — so whitelist removes them from the body
}

This is mass assignment (a.k.a. over-posting) — OWASP API3:2023, Broken Object Property Level Authorization. The attacker doesn’t break your validation; they exploit a field your validation never modeled. whitelist strips it at the door.

Nested validation: the decorator that does nothing

class-validator does not recurse into nested objects by default. Decorate city inside an AddressDto, nest that AddressDto inside RegisterDto, and the validation on city is silently skipped. The parent sees address as an opaque value and never descends into it. Invalid nested data — a city that’s a number, a missing required field — sails through.

import { Type } from 'class-transformer';
import { ValidateNested, IsString, IsArray, ArrayMinSize } from 'class-validator';

class AddressDto {
  @IsString() city: string;   // ← validated ONLY if the parent opts in below
  @IsString() country: string;
}

export class RegisterDto {
  @IsEmail() email: string;

  @ValidateNested()           // recurse into the nested object
  @Type(() => AddressDto)     // class-transformer must instantiate AddressDto first
  address: AddressDto;

  @ValidateNested({ each: true }) // recurse into EACH element of the array
  @Type(() => RoleDto)
  @IsArray()
  @ArrayMinSize(1)
  roles: RoleDto[];
}

Two decorators make nested validation actually run, and both are required. @ValidateNested() tells the validator to descend. @Type(() => AddressDto) tells class-transformer to instantiate a real AddressDto from the plain JSON — without it, address stays a plain object, the validator finds no class metadata to check against, and the nested rules are a no-op. Forgetting @Type is the classic silent failure: no error, no warning, validation just quietly doesn’t happen. For arrays of objects, add { each: true } so the recursion applies to every element, and pair @IsArray() / @ArrayMinSize() to constrain the array itself.

Partial updates: PUT replaces, PATCH patches

A PUT replaces the resource — every field is expected. A PATCH updates some fields and the rest are absent by design. Reuse the create DTO for a PATCH handler and every @IsEmail(), @MinLength() now wrongly demands a field the client deliberately omitted: a partial update fails validation for being partial.

import { PartialType } from '@nestjs/mapped-types'; // or @nestjs/swagger

// every field of CreateUserDto becomes optional, decorators preserved
export class UpdateUserDto extends PartialType(CreateUserDto) {}

// PATCH /users/:id  — body { "email": "new@x.com" } alone now validates
@Patch(':id')
update(@Param('id') id: string, @Body() dto: UpdateUserDto) {
  return this.users.update(id, dto);
}

PartialType(CreateUserDto) builds a new DTO where every inherited field is wrapped as optional (it applies @IsOptional() semantics field-by-field) while keeping the original decorators for any field that is present. It’s surgical: absent fields are fine, present fields still validate. The tempting shortcut — new ValidationPipe({ skipMissingProperties: true }) — works but is a blunt instrument: it skips validation for any missing property across every DTO in the app, including required fields you never meant to make optional, so a genuinely-required-but-forgotten field now passes silently. PartialType scopes optionality to exactly the one update DTO. A related subtlety: @IsOptional() skips validation when the value is null/undefined, which is what makes “field absent” valid — but it also means you can’t distinguish “client didn’t send bio” from “client sent bio: null to clear it” without a separate @IsDefined()/@ValidateIf guard.