Guard binding levels in NestJS - Step-by-Step Execution

Concept Flow - Guard binding levels

Request Received

↓

Global Guards Check

↓

Controller Guards Check

↓

Route Handler Guards Check

↓

If All Guards Pass

↓

Execute Route Handler

↓

Send Response

This flow shows how NestJS checks guards at global, controller, and route levels in order before running the route handler.

Execution Sample

NestJS

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

@Injectable()
export class AuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    return true; // allow access
  }
}

This code defines a simple guard that always allows access.

Execution Table

Step	Guard Level	Guard Called?	Result	Next Action
1	Global	Yes	Pass	Check Controller Guards
2	Controller	Yes	Pass	Check Route Guards
3	Route	Yes	Pass	Execute Route Handler
4	Route	No more guards	N/A	Send Response

💡 All guards passed, so route handler executes and response is sent.

Variable Tracker

Variable	Start	After Global Guard	After Controller Guard	After Route Guard	Final
accessAllowed	undefined	true	true	true	true

Key Moments - 3 Insights

Why does NestJS check global guards before controller or route guards?

Global guards apply to every request, so they run first to quickly allow or deny access before more specific guards run, as shown in steps 1 and 2 of the execution_table.

What happens if a controller guard denies access?

If a controller guard returns false, NestJS stops checking further guards and denies the request immediately, skipping route guards and handler execution. This is implied by the flow and exit conditions.

Can route-level guards override global or controller guards?

No, route guards run last and cannot override earlier guards. If any previous guard denies access, route guards won't run. This order is clear in the concept_flow and execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, at which step are controller guards checked?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Check the 'Guard Level' column in execution_table rows.

According to variable_tracker, what is the value of accessAllowed after the route guard?

A true

B false

C undefined

D null

💡 Hint

Look at the 'After Route Guard' column for accessAllowed in variable_tracker.

If the global guard fails, what happens next according to the concept_flow?

A Controller guards run anyway

B Request is denied immediately

C Route handler executes

D Route guards run

💡 Hint

Refer to the concept_flow where failure at any guard level stops further processing.

Concept Snapshot

NestJS checks guards in this order:
1. Global guards run first for all requests.
2. Controller guards run next for specific controllers.
3. Route guards run last for specific routes.
If any guard denies access, request stops immediately.
Guards control access before route handler runs.

Full Transcript

In NestJS, guards are functions that decide if a request can continue. They run in a specific order: global guards first, then controller guards, then route guards. If any guard returns false, NestJS stops and denies the request. This ensures security checks happen from broad to specific. The example shows a guard that always allows access. The execution table traces each guard check step by step. The variable tracker shows how the accessAllowed flag stays true after each guard. Key moments clarify why the order matters and what happens if a guard denies access. The quiz tests understanding of guard order and outcomes.