Validation

It is best practice to validate the correctness of any data sent into a web application. To automatically validate incoming requests, Nest provides several pipes available right out-of-the-box:

  • ValidationPipe
  • ParseIntPipe
  • ParseBoolPipe
  • ParseArrayPipe
  • ParseUUIDPipe

The ValidationPipe makes use of the powerful class-validator package and its declarative validation decorators. The ValidationPipe provides a convenient approach to enforce validation rules for all incoming client payloads, where the specific rules are declared with simple annotations in local class/DTO declarations in each module.

Overview

In the Pipes chapter, we went through the process of building simple pipes and binding them to controllers, methods or to the global app to demonstrate how the process works. Be sure to review that chapter to best understand the topics of this chapter. Here, we’ll focus on various real world use cases of the ValidationPipe, and show how to use some of its advanced customization features.

Using the built-in ValidationPipe

Hint The ValidationPipe is imported from the @nestjs/common package.

Because this pipe uses the class-validator and class-transformer libraries, there are many options available. You configure these settings via a configuration object passed to the pipe. Following are the built-in options:

  1. export interface ValidationPipeOptions extends ValidatorOptions {
  2. transform?: boolean;
  3. disableErrorMessages?: boolean;
  4. exceptionFactory?: (errors: ValidationError[]) => any;
  5. }

In addition to these, all class-validator options (inherited from the ValidatorOptions interface) are available:

OptionTypeDescription
skipMissingPropertiesbooleanIf set to true, validator will skip validation of all properties that are missing in the validating object.
whitelistbooleanIf set to true, validator will strip validated (returned) object of any properties that do not use any validation decorators.
forbidNonWhitelistedbooleanIf set to true, instead of stripping non-whitelisted properties validator will throw an exception.
forbidUnknownValuesbooleanIf set to true, attempts to validate unknown objects fail immediately.
disableErrorMessagesbooleanIf set to true, validation errors will not be returned to the client.
errorHttpStatusCodenumberThis setting allows you to specify which exception type will be used in case of an error. By default it throws BadRequestException.
exceptionFactoryFunctionTakes an array of the validation errors and returns an exception object to be thrown.
groupsstring[]Groups to be used during validation of the object.
dismissDefaultMessagesbooleanIf set to true, the validation will not use default messages. Error message always will be undefined if its not explicitly set.
validationError.targetbooleanIndicates if target should be exposed in ValidationError
validationError.valuebooleanIndicates if validated value should be exposed in ValidationError.

Notice Find more information about the class-validator package in its repository.

Auto-validation

We’ll start by binding ValidationPipe at the application level, thus ensuring all endpoints are protected from receiving incorrect data.

  1. async function bootstrap() {
  2. const app = await NestFactory.create(ApplicationModule);
  3. app.useGlobalPipes(new ValidationPipe());
  4. await app.listen(3000);
  5. }
  6. bootstrap();

To test our pipe, let’s create a basic endpoint.

  1. @Post()
  2. create(@Body() createUserDto: CreateUserDto) {
  3. return 'This action adds a new user';
  4. }

Hint Since TypeScript does not store metadata about generics or interfaces, when you use them in your DTOs, ValidationPipe may not be able to properly validate incoming data. For this reason, consider using concrete classes in your DTOs.

Now we can add a few validation rules in our CreateUserDto. We do this using decorators provided by the class-validator package, described in detail here. In this fashion, any route that uses the CreateUserDto will automatically enforce these validation rules.

  1. import { IsEmail, IsNotEmpty } from 'class-validator';
  2. export class CreateUserDto {
  3. @IsEmail()
  4. email: string;
  5. @IsNotEmpty()
  6. password: string;
  7. }

With these rules in place, if a request hits our endpoint with an invalid email property in the request body, the application will automatically respond with a 400 Bad Request code, along with the following response body:

  1. {
  2. "statusCode": 400,
  3. "error": "Bad Request",
  4. "message": ["email must be an email"]
  5. }

In addition to validating request bodies, the ValidationPipe can be used with other request object properties as well. Imagine that we would like to accept :id in the endpoint path. To ensure that only numbers are accepted for this request parameter, we can use the following construct:

  1. @Get(':id')
  2. findOne(@Param() params: FindOneParams) {
  3. return 'This action returns a user';
  4. }

FindOneParams, like a DTO, is simply a class that defines validation rules using class-validator. It would look like this:

  1. import { IsNumberString } from 'class-validator';
  2. export class FindOneParams {
  3. @IsNumberString()
  4. id: number;
  5. }

Disable detailed errors

Error messages can be helpful to explain what was incorrect in a request. However, some production environments prefer to disable detailed errors. Do this by passing an options object to the ValidationPipe:

  1. app.useGlobalPipes(
  2. new ValidationPipe({
  3. disableErrorMessages: true,
  4. }),
  5. );

As a result, detailed error messages won’t be displayed in the response body.

Stripping properties

Our ValidationPipe can also filter out properties that should not be received by the method handler. In this case, we can whitelist the acceptable properties, and any property not included in the whitelist is automatically stripped from the resulting object. For example, if our handler expects email and password properties, but a request also includes an age property, this property can be automatically removed from the resulting DTO. To enable such behavior, set whitelist to true.

  1. app.useGlobalPipes(
  2. new ValidationPipe({
  3. whitelist: true,
  4. }),
  5. );

When set to true, this will automatically remove non-whitelisted properties (those without any decorator in the validation class).

Alternatively, you can stop the request from processing when non-whitelisted properties are present, and return an error response to the user. To enable this, set the forbidNonWhitelisted option property to true, in combination with setting whitelist to true.

Learn the right way!

  • Validation - 图1 60+ chapters
  • Validation - 图2 4+ hours of videos
  • Validation - 图3 Official certificate
  • Validation - 图4 Deep-dive sessions

Explore official courses

Transform payload objects

Payloads coming in over the network are plain JavaScript objects. The ValidationPipe can automatically transform payloads to be objects typed according to their DTO classes. To enable auto-transformation, set transform to true. This can be done at a method level:

cats.controller.ts

  1. @Post()
  2. @UsePipes(new ValidationPipe({ transform: true }))
  3. async create(@Body() createCatDto: CreateCatDto) {
  4. this.catsService.create(createCatDto);
  5. }

To enable this behavior globally, set the option on a global pipe:

  1. app.useGlobalPipes(
  2. new ValidationPipe({
  3. transform: true,
  4. }),
  5. );

With the auto-transformation option enabled, the ValidationPipe will also perform conversion of primitive types. In the following example, the findOne() method takes one argument which represents an extracted id path parameter:

  1. @Get(':id')
  2. findOne(@Param('id') id: number) {
  3. console.log(typeof id === 'number'); // true
  4. return 'This action returns a user';
  5. }

By default, every path parameter and query parameter comes over the network as a string. In the above example, we specified the id type as a number (in the method signature). Therefore, the ValidationPipe will try to automatically convert a string identifier to a number.

Explicit conversion

In the above section, we showed how the ValidationPipe can implicitly transform query and path parameters based on the expected type. However, this feature requires having auto-transformation enabled.

Alternatively (with auto-transformation disabled), you can explicitly cast values using the ParseIntPipe or ParseBoolPipe (note that ParseStringPipe is not needed because, as mentioned earlier, every path parameter and query parameter comes over the network as a string by default).

  1. @Get(':id')
  2. findOne(
  3. @Param('id', ParseIntPipe) id: number,
  4. @Query('sort', ParseBoolPipe) sort: boolean,
  5. ) {
  6. console.log(typeof id === 'number'); // true
  7. console.log(typeof sort === 'boolean'); // true
  8. return 'This action returns a user';
  9. }

Hint The ParseIntPipe and ParseBoolPipe are exported from the @nestjs/common package.

Parsing and validating arrays

TypeScript does not store metadata about generics or interfaces, so when you use them in your DTOs, ValidationPipe may not be able to properly validate incoming data. For instance, in the following code, createUserDtos won’t be correctly validated:

  1. @Post()
  2. createBulk(@Body() createUserDtos: CreateUserDto[]) {
  3. return 'This action adds new users';
  4. }

To validate the array, create a dedicated class which contains a property that wraps the array, or use the ParseArrayPipe.

  1. @Post()
  2. createBulk(
  3. @Body(new ParseArrayPipe({ items: CreateUserDto }))
  4. createUserDtos: CreateUserDto[],
  5. ) {
  6. return 'This action adds new users';
  7. }

In addition, the ParseArrayPipe may come in handy when parsing query parameters. Let’s consider a findByIds() method that returns users based on identifiers passed as query parameters.

  1. @Get()
  2. findByIds(
  3. @Query('id', new ParseArrayPipe({ items: Number, separator: ',' }))
  4. ids: number[],
  5. ) {
  6. return 'This action returns users by ids';
  7. }

This construction validates the incoming query parameters from an HTTP GET request like the following:

  1. GET /?ids=1,2,3

WebSockets and Microservices

While this chapter shows examples using HTTP style applications (e.g., Express or Fastify), the ValidationPipe works the same for WebSockets and microservices, regardless of the transport method that is used.

Learn more

Read more about custom validators, error messages, and available decorators as provided by the class-validator package here.