Whitelist, вложенная валидация и частичные обновления

whitelist: поле, которого тут быть не должно

По умолчанию ValidationPipe валидирует декорированные свойства и оставляет всё остальное на объекте. Поле без декоратора не отвергается — валидатор его игнорирует и пропускает нетронутым. Это и есть весь механизм инцидента: недекорированный role невидим для валидации, но полностью присутствует в payload, который твой сервис передаёт в 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 переворачивает дефолт: любое свойство, у которого нет валидационного декоратора на DTO, срезается с объекта до того, как он дойдёт до твоего хендлера. Недекорированные role и isVerified просто перестают существовать. forbidNonWhitelisted: true идёт на шаг дальше — вместо тихого удаления неизвестного поля pipe бросает 400 Bad Request, называя его (property role should not exist). Тихое срезание безопаснее по умолчанию; вариант forbid громче и ловит клиентов (и твой собственный фронтенд), шлющих поля, которые им слать не следует, — а именно это и нужно в сервисе, где неожиданное поле это баг, а не шум.

// RegisterDto — только эти два поля проходят whitelist; role/isVerified срезаются
export class RegisterDto {
  @IsEmail()
  email: string;

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

Это mass assignment (он же over-posting) — OWASP API3:2023, Broken Object Property Level Authorization. Атакующий не ломает твою валидацию; он эксплуатирует поле, которое твоя валидация никогда не моделировала. whitelist срезает его на входе.

Вложенная валидация: декоратор, который ничего не делает

class-validator не рекурсирует во вложенные объекты по умолчанию. Декорируй city внутри AddressDto, вложи этот AddressDto внутрь RegisterDto — и валидация на city молча пропускается. Родитель видит address как непрозрачное значение и никогда внутрь не спускается. Невалидные вложенные данные — city, который число, отсутствующее обязательное поле — проходят насквозь.

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[];
}

Два декоратора заставляют вложенную валидацию реально работать, и нужны оба. @ValidateNested() велит валидатору спуститься. @Type(() => AddressDto) велит class-transformer инстанцировать настоящий AddressDto из простого JSON — без него address остаётся обычным объектом, валидатор не находит метаданных класса для проверки, и вложенные правила становятся no-op. Забыть @Type — классический тихий сбой: ни ошибки, ни предупреждения, валидация просто тихо не происходит. Для массивов объектов добавь { each: true }, чтобы рекурсия применялась к каждому элементу, и пара @IsArray() / @ArrayMinSize() ограничивает сам массив.

Частичные обновления: PUT заменяет, PATCH патчит

PUT заменяет ресурс — ожидается каждое поле. PATCH обновляет некоторые поля, а остальные отсутствуют by design. Переиспользуй create-DTO для PATCH-хендлера — и каждый @IsEmail(), @MinLength() теперь ошибочно требует поле, которое клиент намеренно опустил: частичное обновление падает на валидации за то, что оно частичное.

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) строит новый DTO, где каждое унаследованное поле обёрнуто как опциональное (он применяет семантику @IsOptional() поле за полем), сохраняя при этом исходные декораторы для любого поля, которое присутствует. Это хирургично: отсутствующие поля в порядке, присутствующие всё ещё валидируются. Соблазнительный шорткат — new ValidationPipe({ skipMissingProperties: true }) — работает, но это тупой инструмент: он пропускает валидацию для любого отсутствующего свойства во всех DTO приложения, включая обязательные поля, которые ты никогда не хотел делать опциональными, так что по-настоящему-обязательное-но-забытое поле теперь проходит молча. PartialType ограничивает опциональность ровно одним update-DTO. Связанная тонкость: @IsOptional() пропускает валидацию, когда значение null/undefined, — это и делает «поле отсутствует» валидным, — но это также значит, что ты не отличишь «клиент не прислал bio» от «клиент прислал bio: null, чтобы очистить» без отдельного стража @IsDefined()/@ValidateIf.