@lenne.tech/nest-server 11.34.1 → 11.35.1

package/src/core/common/enums/role.enum.ts

@@ -60,3 +60,119 @@ export enum RoleEnum {
   // User must be logged in (see context user, e.g. @CurrentUser)
   S_USER = 's_user',
 }
+
+/**
+ * Prefix that marks a role as a system role (runtime-context check, never a stored role).
+ *
+ * This is the single source of truth for the prefix. Anything deriving the system-role rule —
+ * guards, the `@Restricted` evaluation, the storage guards — must build on it rather than
+ * hard-coding `'s_'` again.
+ */
+export const SYSTEM_ROLE_PREFIX = 's_';
+
+/**
+ * Is this role a system role, by the exact rule the runtime checks use?
+ *
+ * Case-SENSITIVE on purpose: `hasRole()` and `checkRoleAccess()` compare role strings exactly,
+ * so `'S_SELF'` is a different string from `'s_self'` and never grants anything. Widening this
+ * to case-insensitive would make the guards treat a legitimately-named project role such as
+ * `'S_Manager'` as a system role and change access decisions.
+ *
+ * Use this for RUNTIME checks. To decide whether a value may be STORED in `user.roles`, use
+ * {@link looksLikeSystemRole} — that question deserves the stricter, defensive answer.
+ *
+ * Declared as a hoisted `function` (not a `const` arrow) so it stays temporal-dead-zone immune
+ * on any import cycle — see `.claude/rules/architecture.md` → "DI Token Placement (SWC-Safe)".
+ */
+export function isSystemRole(role: string): boolean {
+  return typeof role === 'string' && role.startsWith(SYSTEM_ROLE_PREFIX);
+}
+
+/**
+ * Could this value be mistaken for a system role once stored in `user.roles`?
+ *
+ * Deliberately BROADER than {@link isSystemRole}: trims surrounding whitespace and ignores case.
+ * A stored `' s_self'` or `'S_SELF'` grants nothing today, because `hasRole()` compares exactly —
+ * but that is an accident of the comparison, not a decision. Both become live the moment anything
+ * normalizes roles (a Mongoose `trim: true`, a CSV/LDAP import, a project sanitizer), and both
+ * pass an eyeball review as legitimate roles in the meantime.
+ *
+ * This is the predicate the storage guards use. It is intentionally strict enough to also reject
+ * a project role that merely happens to start with `s_` (e.g. `'s_manager'`) — the framework
+ * cannot tell those apart from a system role, and a false rejection is recoverable by renaming
+ * while a false acceptance is a silent authorization hole.
+ */
+export function looksLikeSystemRole(role: unknown): boolean {
+  return typeof role === 'string' && role.trim().toLowerCase().startsWith(SYSTEM_ROLE_PREFIX);
+}
+
+/**
+ * Roles that carry GLOBAL, platform-wide authority and can therefore never be satisfied by a
+ * tenant membership role.
+ *
+ * The distinction exists because membership roles are customer-assigned free text: `addMember()`
+ * takes any non-empty string, and whoever may manage members is typically a tenant owner — a
+ * customer. If a membership role were compared by plain string equality against a framework role,
+ * that customer could mint platform-wide authority for themselves simply by naming their tenant
+ * role `'admin'`.
+ *
+ * The two levels are meant to be expressed separately:
+ * - **global admin** → `RoleEnum.ADMIN` in `user.roles` — access to every tenant
+ * - **tenant admin** → a membership role such as `'tenantAdmin'` / `'spaceAdmin'` — one tenant only
+ *
+ * Required roles from this set are always resolved against `user.roles`, never against
+ * `membership.role`, no matter what the tenant header says.
+ */
+export const GLOBAL_ONLY_ROLES: readonly string[] = [RoleEnum.ADMIN];
+
+/**
+ * Is this a role that only the platform may grant (never a tenant)?
+ *
+ * Hoisted `function` for the same temporal-dead-zone reason as {@link isSystemRole}.
+ */
+export function isGlobalOnlyRole(role: string): boolean {
+  return typeof role === 'string' && GLOBAL_ONLY_ROLES.includes(role);
+}
+
+/**
+ * Could this value be mistaken for a global-only role once stored?
+ *
+ * Stands to {@link isGlobalOnlyRole} exactly as {@link looksLikeSystemRole} stands to
+ * {@link isSystemRole}: the runtime rule is exact (so `'ADMIN'` never grants anything), while the
+ * storage rule is defensive, because `' Admin '` reads as legitimate in a members list and becomes
+ * live the moment anything normalizes role strings.
+ */
+export function looksLikeGlobalOnlyRole(role: unknown): boolean {
+  if (typeof role !== 'string') {
+    return false;
+  }
+  const normalized = role.trim().toLowerCase();
+  return GLOBAL_ONLY_ROLES.some((globalRole) => globalRole.toLowerCase() === normalized);
+}
+
+/**
+ * Is this value unusable as a tenant MEMBERSHIP role?
+ *
+ * True for system roles (which are runtime-context checks, not stored roles) and for global-only
+ * roles (which would cross the tenant boundary). Used to refuse such values at assignment time, so
+ * the dangerous membership never comes into existence in the first place.
+ *
+ * Uses the DEFENSIVE variant of both predicates — see {@link looksLikeSystemRole} and
+ * {@link looksLikeGlobalOnlyRole} for why storage deserves the stricter answer than runtime.
+ */
+export function isForbiddenMembershipRole(role: unknown): boolean {
+  return looksLikeSystemRole(role) || looksLikeGlobalOnlyRole(role);
+}
+
+/**
+ * `class-validator` `@Matches()` pattern that ACCEPTS everything {@link looksLikeSystemRole}
+ * rejects, and vice versa.
+ *
+ * A negative lookahead, so a value is valid exactly when it does NOT begin (after optional leading
+ * whitespace, case-insensitively) with the system-role prefix. Kept next to the predicate it
+ * mirrors so the two cannot drift; `@Matches` needs a pattern and cannot take a function.
+ *
+ * Anchored with no quantifier over the input, so it is linear in input length — a 100 KB value
+ * costs the same as a 10-character one, with no backtracking to exploit.
+ */
+export const SYSTEM_ROLE_REJECT_PATTERN = new RegExp(`^(?!\\s*${SYSTEM_ROLE_PREFIX})`, 'i');

package/src/core/common/helpers/execution-context-request.helper.ts

@@ -0,0 +1,102 @@
+/**
+ * The request-like object a guard decides on, for EVERY transport — including the GraphQL WebSocket.
+ *
+ * WHY THIS EXISTS: all three role guards resolved the request the same way, and all three got the
+ * WebSocket wrong in the same way:
+ *
+ * ```typescript
+ * ctx.getContext()?.req || context.switchToHttp().getRequest()
+ * ```
+ *
+ * A subscription's GraphQL context is the graphql-ws `extra` object, which has no `req`. The HTTP
+ * fallback then runs on a GraphQL context, where `switchToHttp().getRequest()` yields the resolver's
+ * ROOT value — `undefined` at subscribe time. So the guards were handed nothing, and what they did
+ * with nothing differed in the worst possible way:
+ *
+ * - `CoreTenantGuard` hit `if (!request) return true` and GRANTED access without deciding anything.
+ *   With multi-tenancy active the role guard PASSES non-system roles through to it, so `@Roles()` on a
+ *   subscription was checked by nobody at all: a plain `member` reached a `tenantAdmin`-gated
+ *   subscription and received its messages.
+ * - Without multi-tenancy the role guard found no token and refused EVERYONE, so the same decorator
+ *   silently meant "locked" instead of "open".
+ *
+ * Both are wrong, and the first is a hole. Everything a guard needs is present on the subscription
+ * context — `CoreModule`'s `onConnect` records the authenticated `user` and the client's
+ * `connectionParams` as `headers` — it was simply never looked at.
+ *
+ * DELIBERATELY IMPORT-FREE apart from the Nest types it is typed against, so it stays usable from
+ * `src/core/common/**` and from `src/core/modules/**` alike without adding an import edge between
+ * them. See `.claude/rules/architecture.md` → "DI Token Placement (SWC-Safe)".
+ */
+import type { ExecutionContext } from '@nestjs/common';
+
+/**
+ * The shape a guard reads and writes. It is deliberately loose: on HTTP this IS the Express request,
+ * and on a WebSocket it is the graphql-ws `extra` object, which a guard may annotate the same way
+ * (`tenantId`, `tenantRole`, …) — those writes are inert on that path, because the Mongoose plugins
+ * read the WebSocket's tenant scope from `RequestContext` instead (see `graphql-ws-context.helper`).
+ */
+export interface GuardRequestLike {
+  [key: string]: any;
+  headers?: Record<string, any>;
+  user?: any;
+}
+
+/**
+ * Is this object plausibly a request/subscription context rather than a resolver root value?
+ *
+ * The check is on the KEYS a guard actually reads. A payload object that happens to carry a `user`
+ * field would otherwise be mistaken for an authenticated request — and a subscription payload very
+ * plausibly does (`pubSub.publish('userCreated', user)`), which would turn the PUBLISHED user into
+ * the apparent caller. Requiring the graphql-ws marker (`socket` / `request` / `connectionParams`)
+ * rules that out: a payload does not carry those.
+ */
+function isSubscriptionContext(value: any): boolean {
+  return (
+    !!value && typeof value === 'object' && ('socket' in value || 'connectionParams' in value || 'request' in value)
+  );
+}
+
+/**
+ * Resolve the object a guard should decide on.
+ *
+ * Order matters:
+ *  1. `ctx.getContext().req` — HTTP GraphQL, and the shape every existing consumer expects.
+ *  2. The graphql-ws subscription context itself, when it looks like one (see above).
+ *  3. `switchToHttp().getRequest()` — REST controllers. On a GraphQL context this returns the
+ *     resolver root, which is why it comes LAST and why step 2 must not fall through to it.
+ *
+ * @returns the request-like object, or `undefined` when the context carries none. A guard must treat
+ *   `undefined` as "no information", never as "permitted" — that conflation is what this file fixes.
+ */
+export function resolveGuardRequest(
+  context: ExecutionContext,
+  gqlContextOf: (context: ExecutionContext) => any,
+): GuardRequestLike | undefined {
+  let gqlContext: any;
+  try {
+    gqlContext = gqlContextOf(context);
+  } catch {
+    gqlContext = undefined;
+  }
+
+  if (gqlContext?.req) {
+    return gqlContext.req;
+  }
+
+  if (isSubscriptionContext(gqlContext)) {
+    // Normalize the two names the transports use, so a guard reads `headers` unconditionally:
+    // `graphql-ws` gets them from CoreModule's onConnect, `subscriptions-transport-ws` from its own,
+    // and the raw upgrade request is the fallback for a custom onConnect that forwards neither.
+    if (!gqlContext.headers) {
+      gqlContext.headers = gqlContext.connectionParams ?? gqlContext.request?.headers ?? {};
+    }
+    return gqlContext;
+  }
+
+  try {
+    return context.switchToHttp().getRequest();
+  } catch {
+    return undefined;
+  }
+}

package/src/core/common/helpers/file.helper.ts

@@ -1,3 +1,4 @@
+import { BadRequestException } from '@nestjs/common';
 import { MulterOptions } from '@nestjs/platform-express/multer/interfaces/multer-options.interface';
 import { randomBytes } from 'crypto';
 import { diskStorage, memoryStorage } from 'multer';
@@ -147,9 +148,14 @@ function normalizeMimeType(value: string): string {
  * `options.allowScriptableTypes` is set — that is what closes the hole for
  * expressions that already exist in consumer projects.
  *
- * Rejections are reported as a real `Error`. Passing a bare string (as this
- * helper did before) leaves multer with an "error" that has no `message`, which
- * NestJS's `transformException` cannot map to a 4xx.
+ * Rejections are reported as a `BadRequestException`, so the caller gets a 400
+ * with a readable reason. An `HttpException` is required, not merely tidier:
+ * NestJS's `transformException` returns any NON-`HttpException` unchanged — its
+ * switch matches only multer's own message constants (`LIMIT_FILE_SIZE`,
+ * `LIMIT_UNEXPECTED_FILE`, …), and a message written here matches none of them.
+ * A bare `new Error()` therefore still surfaced to the client as a 500, which
+ * reads as "the server broke" for what is in fact a refused file. See
+ * `tests/unit/file-upload-rejection-status.spec.ts`.
  */
 export function multerFileFilter(
   accept: RegExp | UploadAllowList = IMAGE_UPLOAD_ALLOW_LIST,
@@ -163,7 +169,7 @@ export function multerFileFilter(
       !options?.allowScriptableTypes &&
       (SCRIPTABLE_UPLOAD_MIME_TYPES.includes(mimeType) || SCRIPTABLE_UPLOAD_EXTENSIONS.includes(extension))
     ) {
-      return cb(new Error(`File upload rejected: ${mimeType || 'unknown type'} may execute as script`));
+      return cb(new BadRequestException(`File upload rejected: ${mimeType || 'unknown type'} may execute as script`));
     }
 
     const accepted =
@@ -174,7 +180,7 @@ export function multerFileFilter(
     if (accepted) {
       return cb(null, true);
     }
-    cb(new Error(`File upload only supports the following filetypes - ${describeAccept(accept)}`));
+    cb(new BadRequestException(`File upload only supports the following filetypes - ${describeAccept(accept)}`));
   };
 }
 

package/src/core/common/helpers/graphql-ws-context.helper.ts

@@ -0,0 +1,192 @@
+// `require`, NOT an ESM import: `@nestjs/graphql` builds the schema with the instance Node's CJS
+// cache holds, and graphql REFUSES a schema "from another module or realm". An ESM import can resolve
+// to a second copy of the module (a bundler's interop namespace, or a duplicated install), and the
+// wrapper would then reject the very schema it was handed. The repo already uses this form for
+// `graphql-upload` and `lodash` for the same reason.
+import graphql = require('graphql');
+
+import { getTenantContextResolver } from '../services/core-tenant-context.registry';
+import { ConfigService } from '../services/config.service';
+import { IRequestContext, RequestContext } from '../services/request-context.service';
+
+/**
+ * A `RequestContext` for GraphQL operations that arrive over a WEBSOCKET.
+ *
+ * WHY THIS EXISTS — the gap it closes is a silent, complete tenant bypass:
+ *
+ * `RequestContextMiddleware` is Express middleware (`consumer.apply(...).forRoutes('*')`). A
+ * WebSocket UPGRADE is not a `request` event, so it traverses no middleware — and `CoreTenantGuard`
+ * cannot help either, because its `getRequest()` looks for `context.req`, which a subscription
+ * context (the graphql-ws `extra` object) does not have, so the guard returns `true` without
+ * deciding anything.
+ *
+ * The consequence was invisible from the query itself. `mongooseTenantPlugin.shouldBypass()` reads
+ * "no RequestContext" as "system operation, no filter" — correct for a cron job or a migration, and
+ * exactly wrong here. So a tenant-scoped read performed while delivering a subscription message
+ * returned EVERY tenant's rows, and the plugin's own safety net (which throws when a tenant-scoped
+ * schema is touched without a tenant) never fired, because there was no context to notice.
+ *
+ * WHERE IT HOOKS IN: `GqlSubscriptionService` reads `execute` and `subscribe` off the GraphQL module
+ * options and hands them to BOTH WebSocket transports (`graphql-ws` and `subscriptions-transport-ws`),
+ * defaulting to graphql-js's own. Those two functions are the only place where the whole WS operation
+ * — including every field resolver and the `resolve`/`filter` callbacks of a subscription — is
+ * reachable as one call. HTTP does not go through them (Apollo runs its own pipeline), so wrapping
+ * them touches the WS path only.
+ *
+ * THE ASYNC-ITERATOR PART IS LOAD-BEARING. `subscribe()` returns an AsyncIterator, and graphql-js
+ * runs the per-event execution — `resolve`, `filter`, every field resolver — inside that iterator's
+ * `next()`, which the transport pulls LONG AFTER `subscribe()` returned. Establishing the context
+ * only around the `subscribe()` call therefore covers the initial subscribe and nothing else: the
+ * store is gone by the time the first message is delivered. Wrapping `next()` (and `return`/`throw`)
+ * is what puts every delivered message inside the context.
+ */
+
+/** Minimal shape of what graphql-js `execute`/`subscribe` receive. */
+interface GraphQlArgs {
+  contextValue?: any;
+  [key: string]: any;
+}
+
+type ExecuteFn = (args: GraphQlArgs) => any;
+
+/**
+ * Read the tenant header out of whatever the transport left on the context.
+ *
+ * Both WS transports are covered, and the reason there are three sources is that they genuinely
+ * differ: `graphql-ws` gets `extra.headers` from `CoreModule`'s `onConnect` (the client's
+ * `connectionParams`), `subscriptions-transport-ws` returns `{ headers }` from its own `onConnect`,
+ * and the raw upgrade request is the fallback for a project with a custom `onConnect` that forwards
+ * neither. Header names are matched case-insensitively — `connectionParams` are client-supplied JSON
+ * and arrive with whatever casing the client used, unlike Node's lower-cased HTTP headers.
+ */
+function readTenantHeader(contextValue: any): string | undefined {
+  const headerName = (ConfigService.configFastButReadOnly?.multiTenancy?.headerName ?? 'x-tenant-id').toLowerCase();
+  const sources = [contextValue?.headers, contextValue?.connectionParams, contextValue?.request?.headers];
+  for (const source of sources) {
+    if (!source || typeof source !== 'object') {
+      continue;
+    }
+    for (const [key, value] of Object.entries(source as Record<string, unknown>)) {
+      if (key.toLowerCase() === headerName && typeof value === 'string' && value) {
+        return value;
+      }
+    }
+  }
+  return undefined;
+}
+
+/** The user the connection authenticated as, as `CoreModule`'s `onConnect` recorded it. */
+function readUser(contextValue: any): any {
+  return contextValue?.user ?? contextValue?.extra?.user ?? undefined;
+}
+
+/**
+ * Build the context for one WebSocket operation.
+ *
+ * Returns `undefined` when the operation is NOT a WebSocket one (an HTTP context carries `req`, and
+ * the middleware has already established a context for it) — wrapping that again would replace a
+ * live, lazily-evaluated context with a snapshot.
+ */
+export async function buildWsRequestContext(contextValue: any): Promise<IRequestContext | undefined> {
+  if (!contextValue || typeof contextValue !== 'object' || contextValue.req) {
+    return undefined;
+  }
+
+  const user = readUser(contextValue);
+  const context: IRequestContext = { currentUser: user };
+
+  // Language: same source as the HTTP path, when the transport carried it.
+  const acceptLanguage =
+    contextValue.headers?.['accept-language'] ??
+    contextValue.connectionParams?.['accept-language'] ??
+    contextValue.request?.headers?.['accept-language'];
+  if (typeof acceptLanguage === 'string') {
+    context.language = acceptLanguage;
+  }
+
+  const resolver = getTenantContextResolver();
+  if (resolver) {
+    // A failure here must NOT be answered with an unscoped context — that is the leak this file
+    // exists to close. Leaving the tenant fields unset makes the plugin's safety net refuse
+    // tenant-scoped reads, which is the safe direction.
+    try {
+      Object.assign(context, await resolver.resolve(user, readTenantHeader(contextValue)));
+    } catch {
+      // Intentionally swallowed: see above. Non-tenant operations keep working.
+    }
+  }
+
+  return context;
+}
+
+/**
+ * Run an AsyncIterator's pulls inside `context`.
+ *
+ * `next()` is where graphql-js executes the per-event selection set, so this is what carries the
+ * context into every delivered message rather than only into the initial subscribe.
+ */
+export function withRequestContextAsyncIterator<T>(
+  iterator: AsyncIterator<T> & { [Symbol.asyncIterator]?: () => AsyncIterator<T> },
+  context: IRequestContext,
+): AsyncIterableIterator<T> {
+  const wrapped: AsyncIterableIterator<T> = {
+    next: (...args: [] | [undefined]) => RequestContext.run(context, () => iterator.next(...(args as []))),
+    [Symbol.asyncIterator]() {
+      return wrapped;
+    },
+  };
+  if (iterator.return) {
+    wrapped.return = (value?: any) => RequestContext.run(context, () => iterator.return!(value));
+  }
+  if (iterator.throw) {
+    wrapped.throw = (error?: any) => RequestContext.run(context, () => iterator.throw!(error));
+  }
+  return wrapped;
+}
+
+/** Is this an AsyncIterator (a subscription source) rather than a plain execution result? */
+function isAsyncIterable(value: any): boolean {
+  return !!value && typeof value === 'object' && typeof value[Symbol.asyncIterator] === 'function';
+}
+
+/**
+ * Wrap graphql-js `execute` so a query/mutation sent over the WebSocket runs in a request context.
+ *
+ * Not only subscriptions: `graphql-ws` carries queries and mutations too, and those had the same gap.
+ */
+export function createRequestContextAwareExecute(execute: ExecuteFn): ExecuteFn {
+  return async (args: GraphQlArgs) => {
+    const context = await buildWsRequestContext(args?.contextValue);
+    if (!context) {
+      return execute(args);
+    }
+    return RequestContext.run(context, () => execute(args));
+  };
+}
+
+/** Wrap graphql-js `subscribe` so both the subscribe AND every delivered message run in a context. */
+export function createRequestContextAwareSubscribe(subscribe: ExecuteFn): ExecuteFn {
+  return async (args: GraphQlArgs) => {
+    const context = await buildWsRequestContext(args?.contextValue);
+    if (!context) {
+      return subscribe(args);
+    }
+    const result = await RequestContext.run(context, () => subscribe(args));
+    return isAsyncIterable(result) ? withRequestContextAsyncIterator(result as AsyncIterator<any>, context) : result;
+  };
+}
+
+/**
+ * The pair `CoreModule` installs — graphql's own `execute` / `subscribe`, wrapped.
+ *
+ * Zero-arg factories rather than pre-built constants so nothing is captured at module-evaluation
+ * time, and so `core.module.ts` needs no graphql import of its own (see the `require` note at the top
+ * of this file for why that import form matters).
+ */
+export function buildRequestContextAwareExecute(): (args: GraphQlArgs) => any {
+  return createRequestContextAwareExecute(graphql.execute as any);
+}
+
+export function buildRequestContextAwareSubscribe(): (args: GraphQlArgs) => any {
+  return createRequestContextAwareSubscribe(graphql.subscribe as any);
+}

package/src/core/common/helpers/gridfs.helper.ts

@@ -198,10 +198,26 @@ export class GridFSHelper {
   }
 
   /**
-   * Find file metadata by filename
+   * Find file metadata by filename — the MOST RECENT file with that name.
+   *
+   * The sort is load-bearing, not cosmetic. `bucket.find({ filename })` returns natural order,
+   * which in practice is the OLDEST document first, while `openDownloadStreamByName()` defaults to
+   * `revision: -1` — the NEWEST. Filenames are unique in no store and are client-supplied, so with
+   * two files of one name this method answered one document and the download served another: an
+   * ownership rule built on `getRawFileInfoByName()` approved the caller's own file and the stream
+   * handed over the other one.
+   *
+   * Newest-first (rather than oldest-first) because it is the BYTES semantics that must not move:
+   * GridFS treats a re-upload under the same name as a new revision and serves the latest, so
+   * aligning the metadata lookup with that keeps every existing download answering the same bytes
+   * and only corrects the document describing them. `_id` breaks the tie, so two files written in
+   * the same millisecond still order totally.
    */
   static async findFileByName(bucket: GridFSBucket, filename: string): Promise<GridFSFileInfo | null> {
-    const files = await bucket.find({ filename }).toArray();
+    // `uploadDate` FIRST: MongoDB applies sort keys in document order, so leading with `_id` would
+    // make the tie-break the primary key and could disagree with the driver's own by-name revision
+    // order (which sorts on `uploadDate` alone).
+    const files = await bucket.find({ filename }, { limit: 1, sort: { uploadDate: -1, _id: -1 } }).toArray();
     return files.length > 0 ? GridFSHelper.normalizeFileInfo(files[0]) : null;
   }
 

package/src/core/common/interceptors/check-security.interceptor.ts

@@ -3,6 +3,7 @@ import { Observable } from 'rxjs';
 import { map } from 'rxjs/operators';
 
 import { getContextData } from '../helpers/context.helper';
+import { hasRestrictionsCheckedMarker } from '../decorators/restrictions-checked.marker';
 import { getStringIds } from '../helpers/db.helper';
 import { processDeep } from '../helpers/input.helper';
 import { ConfigService } from '../services/config.service';
@@ -66,7 +67,9 @@ export class CheckSecurityInterceptor implements NestInterceptor {
       objectData = data;
 
       // Check if data already checked
-      if (this.config.noteCheckedObjects && data?._objectAlreadyCheckedForRestrictions) {
+      // Recognised by the framework MARKER, not by a truthy property of that name — see
+      // restrictions-checked.marker.ts for why a document must not be able to skip securityCheck().
+      if (this.config.noteCheckedObjects && hasRestrictionsCheckedMarker(data)) {
         return data;
       }
 

package/src/core/common/interceptors/response-model.interceptor.ts

@@ -6,6 +6,7 @@ import { resolveResponseModelClass } from '../helpers/interceptor.helper';
 import { CoreModel } from '../models/core-model.model';
 import { ConfigService } from '../services/config.service';
 import { ModelRegistry } from '../services/model-registry.service';
+import { hasRestrictionsCheckedMarker } from '../decorators/restrictions-checked.marker';
 
 /**
  * Interceptor that automatically converts plain objects and Mongoose documents
@@ -48,7 +49,7 @@ export class ResponseModelInterceptor implements NestInterceptor {
         }
 
         // Already processed by another interceptor
-        if (data._objectAlreadyCheckedForRestrictions) {
+        if (hasRestrictionsCheckedMarker(data)) {
           return data;
         }
 
@@ -90,7 +91,7 @@ export class ResponseModelInterceptor implements NestInterceptor {
     }
 
     // Already processed
-    if (item._objectAlreadyCheckedForRestrictions) {
+    if (hasRestrictionsCheckedMarker(item)) {
       return item;
     }