Why AI tools produce this: AI coding tools produce this regularly, typically when prompted for a shortcut or a quick fix.
Why this matters
A guard that unconditionally authorises every request removes access control from every route, controller, or handler it protects, so the endpoint is effectively public. This is the classic "stubbed out for now" guard that ships to production.
Implement the check: read the request from context.switchToHttp().getRequest(), verify the session/token/role, and return true only when it passes (return false or throw UnauthorizedException / ForbiddenException otherwise). If a route is meant to be public, apply a @Public() decorator and remove the guard rather than leaving one that reads as protected but is not.
import { CanActivate, ExecutionContext, Injectable, UnauthorizedException } from '@nestjs/common';@Injectable()export class AuthGuard implements CanActivate { // ok: auth.nestjs.guard-always-true -- inspects the request before allowing canActivate(context: ExecutionContext) { const request = context.switchToHttp().getRequest(); if (!request.headers.authorization) { throw new UnauthorizedException(); } return true; }}// ok: auth.nestjs.guard-always-true -- an unrelated class method named// canActivate that is not a NestJS guardexport class FeatureToggle { canActivate(name: string) { return true; }}
Suppressing this rule
If a finding is a genuine false positive, scope the suppression to the exact line and leave a reason, never disable the rule project-wide. Disable directives are line-scoped by design.