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

Yes — a guard registered through the APP_GUARD token gives you the default-deny surface you want, and the three open points all have workable answers. The short version: global guards bind per route handler at registration time (so lazy modules and versioned routes are covered), guards run broadest-to-narrowest with an AND semantic (so a controller guard cannot undo a global denial), and metadata reflection can fail closed if you treat anything other than strict true as protected.

Coverage: lazy modules and versioned routes

An APP_GUARD registration is bound by the framework to every HTTP route handler as routes are registered, not per module import. That means routes in lazily loaded modules and routes produced by URI or header versioning are guarded the same way as eagerly loaded ones. The caveats that actually bite people are elsewhere:

• Non-HTTP entry points — WebSocket gateways, microservice transport patterns, GraphQL resolvers — bind guards through their own execution context. A global HTTP guard does not automatically protect them.
• Anything served outside Nest's router (middleware-mounted static assets, proxy middleware) bypasses guards entirely.
• Global guards run before pipes and interceptors, so don't depend on transformed bodies inside the guard.

Ordering: global vs controller guards

Guard execution order is broadest to narrowest: global first, then controller-scoped, then method-scoped. Every guard in the chain must allow the request — the semantics are AND, not override. A controller-level guard can add restrictions but can never rescue a request the global guard already denied. That is exactly the property you want for default-deny: no downstream annotation can accidentally re-open a route.

Failing closed on missing metadata

The standard pattern is a global guard that consults an IS_PUBLIC key via Reflector.getAllAndOverride, checking the handler first and falling back to the controller class:

const isPublic = this.reflector.getAllAndOverride<boolean>(IS_PUBLIC_KEY, [
  context.getHandler(),
  context.getClass(),
]);
if (isPublic !== true) {
  // enforce authentication
}

Your worry about "no marker" versus "marker set to false" is mostly unfounded: SetMetadata stores exactly the value given, and an unset key reflects as undefined. Comparing with !== true means both undefined (forgotten decorator) and false fail closed. The one real trap is the inverse case: getAllAndOverride prefers the handler-level value when the key exists there, so if a class is marked @Public() and one method must be authenticated, that method must explicitly set the key to false — relying on absence won't override the class-level true.

Verification before you trust it

1. Add a fresh controller with no decorators; confirm an unauthenticated request gets 401/403.
2. Repeat for a lazy-loaded module and a versioned controller.
3. Unit-test the guard with the reflector mocked to return undefined, false, and true; only true should activate.
4. Log invocation order with a global plus a controller guard on one handler to confirm global runs first.

One caveat: guard ordering and the Reflector API are version-sensitive across NestJS major releases, so confirm against the version pinned in your project before shipping.