Bird
Raised Fist0
NestJSframework~5 mins

Why guards control access in NestJS

Choose your learning style10 modes available
Introduction

Guards help decide who can use parts of your app. They keep things safe by checking if someone is allowed before they get in.

When you want only logged-in users to see certain pages.
When you need to check if a user has special rights before doing an action.
When you want to block access to parts of your app for some users.
When you want to check a password or token before allowing access.
When you want to protect routes from unauthorized users.
Syntax
NestJS
import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';
import { Observable } from 'rxjs';

@Injectable()
export class MyGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean | Promise<boolean> | Observable<boolean> {
    // Your logic here
    return true; // or false
  }
}

The canActivate method decides if access is allowed.

Return true to allow, false to block.

Examples
This guard allows access only if the user is logged in.
NestJS
import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';

@Injectable()
export class AuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    return !!request.user; // allow if user exists
  }
}
This guard checks if the user has a specific role before allowing access.
NestJS
import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';

@Injectable()
export class RoleGuard implements CanActivate {
  constructor(private readonly role: string) {}

  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    return request.user?.role === this.role;
  }
}
Sample Program

This example shows a guard that only lets requests with ?allow=true access the route. Others are blocked.

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

@Injectable()
class SimpleGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    // Allow only if query has ?allow=true
    return request.query.allow === 'true';
  }
}

@Controller('test')
export class TestController {
  @Get()
  @UseGuards(SimpleGuard)
  getData() {
    return 'Access granted';
  }
}
OutputSuccess
Important Notes

Guards run before your route handler to protect it.

They can check anything: user info, tokens, request data.

Always return true or false to control access.

Summary

Guards control who can use parts of your app by allowing or blocking access.

They check conditions like login status or user roles before routes run.

Use guards to keep your app safe and organized.

Practice

(1/5)
1. What is the main purpose of guards in a NestJS application?
easy
A. To format the response data before sending it to the client
B. To control access by allowing or blocking requests based on conditions
C. To manage database connections and queries
D. To handle errors and exceptions globally

Solution

  1. Step 1: Understand the role of guards

    Guards are designed to check conditions before a route handler runs, deciding if access should be granted.
  2. Step 2: Compare with other responsibilities

    Formatting responses, managing database, and error handling are done by other parts of NestJS, not guards.
  3. Final Answer:

    To control access by allowing or blocking requests based on conditions -> Option B
  4. Quick Check:

    Guards control access = A [OK]
Hint: Guards decide if a request can proceed or not [OK]
Common Mistakes:
  • Confusing guards with interceptors or filters
  • Thinking guards handle data formatting
  • Assuming guards manage database logic
2. Which of the following is the correct way to apply a guard to a controller method in NestJS?
easy
A. @UseGuards(AuthGuard) before the method declaration
B. @Guard(AuthGuard) inside the method body
C. UseGuards(AuthGuard) as a function call in the constructor
D. Apply guard logic directly inside the controller constructor

Solution

  1. Step 1: Recall NestJS guard syntax

    Guards are applied using the @UseGuards() decorator placed before the method or class.
  2. Step 2: Evaluate options

    Only @UseGuards(AuthGuard) before the method declaration uses the correct decorator syntax before the method. Others misuse syntax or placement.
  3. Final Answer:

    @UseGuards(AuthGuard) before the method declaration -> Option A
  4. Quick Check:

    @UseGuards decorator = A [OK]
Hint: Use @UseGuards decorator above methods or classes [OK]
Common Mistakes:
  • Using @Guard instead of @UseGuards
  • Calling UseGuards as a function inside constructor
  • Placing guard logic inside constructor instead of decorator
3. Given this guard code snippet:
canActivate(context: ExecutionContext) {
  const request = context.switchToHttp().getRequest();
  return request.user && request.user.isAdmin;
}

What will happen if a user without isAdmin tries to access the guarded route?
medium
A. Access will be granted because the guard always returns true
B. The guard will ignore the user and allow access
C. An error will be thrown due to missing isAdmin property
D. Access will be denied because isAdmin is false or missing

Solution

  1. Step 1: Analyze the guard condition

    The guard returns true only if request.user exists and request.user.isAdmin is truthy.
  2. Step 2: Consider user without isAdmin

    If isAdmin is false or missing, the condition returns false, denying access.
  3. Final Answer:

    Access will be denied because isAdmin is false or missing -> Option D
  4. Quick Check:

    Guard returns false if not admin = B [OK]
Hint: Guard returns true only if user is admin [OK]
Common Mistakes:
  • Assuming missing property causes error
  • Thinking guard always returns true
  • Ignoring the boolean check on isAdmin
4. Identify the error in this guard implementation:
canActivate(context: ExecutionContext) {
  const request = context.getRequest();
  if (!request.user) {
    throw new Error('User not found');
  }
  return true;
}
medium
A. Throwing an error inside a guard instead of returning false
B. Missing async keyword for canActivate method
C. Using context.getRequest() instead of context.switchToHttp().getRequest()
D. Returning true without checking user roles

Solution

  1. Step 1: Check method usage for request

    While context.getRequest() is invalid, the main issue is guard behavior on failure.
  2. Step 2: Understand guard error handling

    Guards should return false to deny access, not throw errors which cause server crashes.
  3. Final Answer:

    Throwing an error inside a guard instead of returning false -> Option A
  4. Quick Check:

    Guards return false, not throw errors [OK]
Hint: Return false to block access, don't throw errors in guards [OK]
Common Mistakes:
  • Throwing errors instead of returning false
  • Using incorrect context method for request
  • Assuming async is required without async code
5. You want to restrict access to a route only to logged-in users with the role 'admin' or 'moderator'. Which guard logic correctly implements this?
hard
A. Return true if request.user does not exist
B. Return true if request.user exists and request.user.role === 'admin' && request.user.role === 'moderator'
C. Return true if request.user exists and request.user.role === 'admin' || request.user.role === 'moderator'
D. Return true if request.user exists and request.user.role !== 'admin' || request.user.role !== 'moderator'

Solution

  1. Step 1: Understand role conditions

    The user must be logged in and have role 'admin' OR 'moderator' to access.
  2. Step 2: Evaluate logical operators

    Return true if request.user exists and request.user.role === 'admin' || request.user.role === 'moderator' uses OR (||) correctly. Return true if request.user exists and request.user.role === 'admin' && request.user.role === 'moderator' uses AND (&&) which is impossible for one role. Return true if request.user exists and request.user.role !== 'admin' || request.user.role !== 'moderator' uses negations incorrectly. Return true if request.user does not exist allows access without user.
  3. Final Answer:

    Return true if request.user exists and request.user.role === 'admin' || request.user.role === 'moderator' -> Option C
  4. Quick Check:

    Use OR for multiple allowed roles = D [OK]
Hint: Use OR (||) to allow multiple roles [OK]
Common Mistakes:
  • Using AND (&&) instead of OR (||) for roles
  • Allowing access when user is missing
  • Incorrect negation logic in conditions
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard