Protected routes with guards in NestJS - Mini Project: Build & Apply

Protected routes with guards

📖 Scenario: You are building a simple NestJS API that has some routes only accessible to logged-in users. You want to protect these routes using guards.

🎯 Goal: Create a NestJS guard to protect a route so only authorized users can access it.

📋 What You'll Learn

Create a basic NestJS controller with one public route and one protected route

Create a guard class that implements CanActivate

Use the guard to protect the protected route

Return true from the guard to allow access

💡 Why This Matters

🌍 Real World

Protecting routes in a web API to ensure only authorized users can access sensitive data or actions.

💼 Career

Understanding guards is essential for backend developers working with NestJS to implement security and access control.

1

Create a controller with two routes

Create a NestJS controller class called AppController with two routes: a GET route at /public that returns the string 'This is public', and a GET route at /protected that returns the string 'This is protected'.

NestJS

import { Controller, Get } from '@nestjs/common';

@Controller()
export class AppController {
  // Your code here
}

Hint

Use @Controller() to define the controller and @Get() decorators for routes.

2

Create a guard class implementing CanActivate

Create a guard class called AuthGuard that implements the CanActivate interface from @nestjs/common. Inside the canActivate method, return true to allow access.

NestJS

import { Controller, Get, CanActivate, ExecutionContext } from '@nestjs/common';

@Controller()
export class AppController {
  @Get('public')
  getPublic() {
    return 'This is public';
  }

  @Get('protected')
  getProtected() {
    return 'This is protected';
  }
}

// Create AuthGuard class below
// Your code here

Hint

Import CanActivate and ExecutionContext from @nestjs/common. Implement canActivate method returning true.

3

Apply the guard to the protected route

Import UseGuards from @nestjs/common and apply the AuthGuard to the /protected route using the @UseGuards(AuthGuard) decorator.

NestJS

import { Controller, Get, CanActivate, ExecutionContext, UseGuards } from '@nestjs/common';

@Controller()
export class AppController {
  @Get('public')
  getPublic() {
    return 'This is public';
  }

  // Add @UseGuards(AuthGuard) decorator here
  @Get('protected')
  getProtected() {
    return 'This is protected';
  }
}

export class AuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    return true;
  }
}

Hint

Use the @UseGuards(AuthGuard) decorator just above the @Get('protected') route.

4

Export the guard and controller for use

Add export keyword before the AppController class declaration to export it. Ensure the AuthGuard class is also exported.

NestJS

import { Controller, Get, CanActivate, ExecutionContext, UseGuards } from '@nestjs/common';

// Add export keyword to AppController
@Controller()
export class AppController {
  @Get('public')
  getPublic() {
    return 'This is public';
  }

  @UseGuards(AuthGuard)
  @Get('protected')
  getProtected() {
    return 'This is protected';
  }
}

export class AuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    return true;
  }
}

Hint

Make sure both AppController and AuthGuard have the export keyword.

Practice

1. What is the main purpose of a guard in NestJS when protecting routes?

easy

A. To decide if a request can access a route based on custom logic

B. To format the response data before sending it

C. To handle database connections automatically

D. To log every request made to the server

Solution

1. Step 1: Understand the role of guards

   Guards in NestJS are designed to control access to routes by running custom logic before the route handler executes.

2. Step 2: Identify the correct purpose

   Among the options, only deciding if a request can access a route matches the guard's role.

3. Final Answer:

   To decide if a request can access a route based on custom logic -> Option A

4. Quick Check:

   Guards control access = C [OK]

Hint: Guards allow or block access before route runs [OK]

Common Mistakes:

• Confusing guards with interceptors or middleware
• Thinking guards modify response data
• Assuming guards handle database tasks

2. Which of the following is the correct way to apply a guard to a route in NestJS?

easy

A. @UseGuards(AuthGuard) before the controller class

B. @UseGuards(AuthGuard) before the route handler method

C. @ApplyGuard(AuthGuard) inside the constructor

D. @Guard(AuthGuard) before the route handler

Solution

1. Step 1: Recall the decorator for guards

   The correct decorator to apply guards in NestJS is @UseGuards().

2. Step 2: Identify correct placement

   This decorator can be placed before a route handler method or a controller class. @UseGuards(AuthGuard) before the route handler method correctly shows it before a route handler method.

3. Final Answer:

   @UseGuards(AuthGuard) before the route handler method -> Option B

4. Quick Check:

   @UseGuards + route method = D [OK]

Hint: Use @UseGuards() decorator on methods or controllers [OK]

Common Mistakes:

• Using @Guard or @ApplyGuard which don't exist
• Placing decorators inside constructor
• Confusing middleware with guards

3. Given this guard implementation, what will happen when a request is made?

import { CanActivate, ExecutionContext } from '@nestjs/common';

export class AlwaysDenyGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    return false;
  }
}

Applied to a route, what is the result?

medium

A. The guard throws an error causing a server crash

B. The route handler runs and returns its response

C. The request is blocked and the route handler does not run

D. The guard logs the request but allows it

Solution

1. Step 1: Analyze the canActivate method

   The guard's canActivate method always returns false, meaning it denies access.

2. Step 2: Understand guard effect on route

   When canActivate returns false, NestJS blocks the request and does not run the route handler.

3. Final Answer:

   The request is blocked and the route handler does not run -> Option C

4. Quick Check:

   canActivate false blocks request = A [OK]

Hint: canActivate false means block access [OK]

Common Mistakes:

• Thinking false lets the route run
• Assuming guard throws error on false
• Confusing logging with blocking

4. Identify the error in this guard code snippet:

import { CanActivate, ExecutionContext } from '@nestjs/common';

export class MyGuard implements CanActivate {
  canActivate(context: ExecutionContext) {
    if (context.switchToHttp().getRequest().user) {
      return true;
    }
  }
}

medium

A. Incorrect import of ExecutionContext

B. Using switchToHttp() is not allowed in guards

C. canActivate should be async but is not

D. Missing return statement when user is not present

Solution

1. Step 1: Check canActivate return paths

   The method returns true if user exists, but returns nothing (undefined) otherwise.

2. Step 2: Understand guard return requirements

   canActivate must always return a boolean or Promise<boolean>. Missing return means undefined, which is invalid.

3. Final Answer:

   Missing return statement when user is not present -> Option D

4. Quick Check:

   All paths must return boolean = B [OK]

Hint: Always return true or false in canActivate [OK]

Common Mistakes:

• Forgetting else return false
• Assuming undefined is false
• Thinking async is always required

5. You want to protect a route so only users with role 'admin' can access it. Which guard implementation correctly enforces this?

import { CanActivate, ExecutionContext } from '@nestjs/common';

export class RolesGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    const user = request.user;
    // Which condition correctly checks for admin role?
  }
}

hard

A. return user && user.role === 'admin';

B. return user && user.roles.includes('admin');

C. return user && user.roles === 'admin';

D. return user && user.role.includes('admin');

Solution

1. Step 1: Understand user role structure

   Assuming user has a single role string in property role, not an array.

2. Step 2: Check each condition

   return user && user.role === 'admin'; correctly compares user.role === 'admin'. return user && user.roles.includes('admin'); assumes roles is an array, which may be incorrect. Options C and D misuse property types.

3. Final Answer:

   return user && user.role === 'admin'; -> Option A

4. Quick Check:

   Check user.role string equals 'admin' = A [OK]

Hint: Match exact role property type to check admin [OK]

Common Mistakes:

• Confusing roles array with single role string
• Using includes on a string property
• Checking wrong property name