ValidationPipe whitelist default shift in NestJS 9 and the open question on forbidUnknownValues

Direct Answer

The framework default for forbidUnknownValues should remain false in NestJS 9 and later. Changing it to true globally would convert previously accepted payloads with extra fields into 400 validation errors, breaking existing clients, proxies, and test suites without code changes. Teams that want strict rejection should enable it explicitly on a per-pipe or per-route basis.

Confirmed Behavior

• whitelist: true (default since NestJS 9) strips properties that lack class-validator decorators from the DTO instance passed to the controller.
• forbidUnknownValues: true changes the outcome from silent stripping to throwing a BadRequestException listing the unknown keys.
• Both options operate after class-transformer plain-to-class conversion and before class-validator runs.

Why the Default Should Stay false

Making strict rejection the default would surface contract drift early, but it also rejects harmless metadata that gateways, CDNs, or older mobile clients routinely append (request IDs, tracing headers, feature flags). In a mature codebase, those extra fields are often ignored by business logic; turning them into hard errors forces a coordinated client-and-server deploy or a temporary rollback. The NestJS team documented the whitelist default shift in release notes precisely because it was a non-breaking change—silent stripping preserves response shape. A forbidUnknownValues default flip would be breaking.

Recommended Migration Strategy

1. Keep the global pipe compatible. Leave forbidUnknownValues: false (or omit it) in the app-wide ValidationPipe registration.
2. Enable strict mode in development and staging. Create a second pipe instance with forbidUnknownValues: true and attach it via @UsePipes() on new controllers or feature modules. This surfaces unknown fields during review without affecting production traffic.
3. Audit unknown-key logs per route. In staging, log the rejected keys per endpoint. If the list is empty or contains only known proxy fields, promote that route to strict mode in production.
4. Gradually expand scope. Once a critical mass of endpoints runs strict mode without incidents, consider a global flip behind a feature flag, but only after verifying that generated clients, integration tests, and exception filters handle the new error shape.

One Diagnostic Detail Needed

What is the exact @nestjs/common and class-validator version pair in the production deployment? The whitelist default changed in NestJS 9.0.0, but class-validator 0.14+ altered error message formatting; knowing the versions confirms whether the current silent-strip behavior matches the documented baseline.