Guards bepalen of een request mag doorgaan naar de route handler — het zijn het dedicated mechanism van NestJS voor autorisatie (en vaak ook authenticatiechecks). Een guard retourneert true om de request toe te staan of false/throws om deze te blokkeren.
@Injectable()
export class AuthGuard implements CanActivate {
canActivate(context: ExecutionContext): boolean {
const request = context.switchToHttp().getRequest();
return !!request.headers.authorization; // true = allow, false = block (403)
}
}
Een guard implementeert canActivate(), die een boolean retourneert (of een Promise/Observable daarvan). Het retourneren van false blokkeert de request met een 403; je kunt ook een specifieke exception gooien (bijv. UnauthorizedException).
@UseGuards(AuthGuard) // on a single route
@Get("profile")
getProfile() {}
@UseGuards(AuthGuard) // on a whole controller (all routes)
@Controller("admin")
export class AdminController {}
app.useGlobalGuards(new AuthGuard()); // globally (all routes)
Guards kunnen op method-, controller- of globaal niveau worden toegepast.
@Injectable()
export class JwtAuthGuard implements CanActivate {
constructor(private jwtService: JwtService) {}
async canActivate(context: ExecutionContext): Promise<boolean> {
const request = context.switchToHttp().getRequest();
const token = request.headers.authorization?.split(" ")[1];
if (!token) throw new UnauthorizedException();
try {
request.user = await this.jwtService.verifyAsync(token); // attach the user
return true;
} catch {
throw new UnauthorizedException("Invalid token");
}
}
}
// a @Roles decorator stores required roles as metadata
@Roles("admin")
@Get("users")
listUsers() {}
// the RolesGuard reads the metadata and checks the user's roles
@Injectable()
export class RolesGuard implements CanActivate {
constructor(private reflector: Reflector) {}
canActivate(ctx: ExecutionContext): boolean {
const roles = this.reflector.get<string[]>("roles", ctx.getHandler());
const { user } = ctx.switchToHttp().getRequest();
return roles.some(role => user.roles?.includes(role)); // allow if the user has a required role
}
}
Het combineren van een @Roles() decorator (metadata) met een guard die deze uitleest (via Reflector) is het standaardpatroon voor role-based access control.
The ExecutionContext gives guards rich info (the handler, class, request) — more
than plain middleware — which is why guards (not middleware) are the right place
for authorization decisions.
Guards zijn het dedicated, idiomatische NestJS mechanism voor autorisatie — controleren welke requests handlers mogen bereiken op basis van authenticatie en permissions.
Het begrijpen ervan is essentieel omdat vrijwel elke echte applicatie routes moet beschermen (login vereisen, rollen/permissions checken), en guards zijn het correcte tool hiervoor (veel schoner dan auth-logica in middleware of elke handler proppen).
De standaardpatronen — een JWT/auth guard die credentials verifieert en de user aan de request attacht, en role-based guards die een @Roles() decorator combineren met een Reflector-uitlezende guard voor RBAC — zijn fundamenteel voor het beveiligen van NestJS APIs.
De toegang van guards tot de rijke ExecutionContext (kennis van de target handler, class en request) is precies wat hen geschikt maakt voor autorisatiebeslissingen die middleware niet schoon kan maken.
Weten hoe je guards schrijft, toepast (method/controller/globaal) en combineert met metadata decorators is kernkennis voor het bouwen van veilige NestJS-applicaties en een veelvoorkomend, architecturaal-belangrijk onderwerp in het framework.