NestJS Guards Are Opt-In: Keeping New Routes From Shipping as Public Endpoints

NestJS guards implement CanActivate and deny a request when they return false or throw, which makes them the standard tool for route protection. The documented limitation is scope: a guard only runs on the controller or handler where it is bound, so any route that is never bound remains reachable without checks.

The goal is a default-deny HTTP surface: every route authenticated unless it is explicitly marked public. NestJS supports registering a guard globally through the APP_GUARD token, and the common pattern pairs that global guard with a metadata marker that exempts selected routes. What is not settled is how far that guarantee extends in practice.

Specific open points:

• Does a guard registered via APP_GUARD execute for every HTTP route in the application, including lazily loaded modules and versioned routes?
• When a global guard and a controller-scoped guard both apply to the same handler, which documented ordering rules decide the outcome?
• Can reflection-based metadata reliably distinguish "no marker present" from "marker set to false" so that a forgotten flag fails closed instead of open?