@lenne.tech/nest-server 11.34.0 → 11.35.0

package/src/core/modules/tenant/core-tenant.helpers.ts

@@ -1,8 +1,8 @@
+import { isForbiddenMembershipRole, isGlobalOnlyRole, looksLikeSystemRole } from '../../common/enums/role.enum';
 import { ConfigService } from '../../common/services/config.service';
+import { RoleScope, roleScopeRegistry, RoleScopeSource } from './core-role-scope.registry';
 import { DEFAULT_ROLE_HIERARCHY } from './core-tenant.enums';
 
-const SYSTEM_ROLE_PREFIX = 's_';
-
 /**
  * Merge handler-level and class-level @Roles() metadata arrays into a single flat array.
  * Used by RolesGuard, BetterAuthRolesGuard, and CoreTenantGuard.
@@ -23,13 +23,145 @@ export function getRoleHierarchy(): Record<string, number> {
   return ConfigService.configFastButReadOnly?.multiTenancy?.roleHierarchy ?? DEFAULT_ROLE_HIERARCHY;
 }
 
+// `isSystemRole` used to be defined here. It now lives in `common/enums/role.enum.ts`, next to the
+// RoleEnum members it describes, so the storage guards and the runtime guards share ONE predicate
+// instead of drifting apart (they already disagreed on case). Re-exported below for compatibility.
+export {
+  GLOBAL_ONLY_ROLES,
+  isForbiddenMembershipRole,
+  isGlobalOnlyRole,
+  isSystemRole,
+  looksLikeGlobalOnlyRole,
+  looksLikeSystemRole,
+  SYSTEM_ROLE_PREFIX,
+} from '../../common/enums/role.enum';
+
+/**
+ * Feeds the role-scope registry from `multiTenancy` config.
+ *
+ * Reads the config lazily on every call rather than caching, so a `ConfigService.setConfig()` in a
+ * test (or a future runtime reload) is picked up without re-registering the source.
+ */
+export const configRoleScopeSource: RoleScopeSource = {
+  globalRoles: () => ConfigService.configFastButReadOnly?.multiTenancy?.globalOnlyRoles ?? [],
+  tenantRoles: () => {
+    const config = ConfigService.configFastButReadOnly?.multiTenancy;
+    return [
+      ...Object.keys(config?.roleHierarchy ?? DEFAULT_ROLE_HIERARCHY),
+      ...(config?.additionalMembershipRoles ?? []),
+    ];
+  },
+};
+
+/**
+ * Validate the configured role vocabulary. Throws when it cannot be enforced coherently.
+ *
+ * Called at boot (`CoreTenantModule`). Failing the boot is the right severity: every condition here
+ * describes a configuration whose access decisions would be ambiguous or silently wrong, and an
+ * ambiguous authorization rule is worse than a server that refuses to start.
+ */
+export function assertRoleVocabularyIsCoherent(): void {
+  const config = ConfigService.configFastButReadOnly?.multiTenancy;
+  if (!config || config.enabled === false) {
+    return;
+  }
+
+  const hierarchy = Object.keys(config.roleHierarchy ?? DEFAULT_ROLE_HIERARCHY);
+  const additional = config.additionalMembershipRoles ?? [];
+  const declaredGlobal = config.globalOnlyRoles ?? [];
+
+  // 1. A tenant role must never be named after a framework role.
+  const reserved = [...hierarchy, ...additional].filter((role) => isForbiddenMembershipRole(role));
+  if (reserved.length) {
+    throw new Error(
+      `multiTenancy: tenant role(s) [${reserved.join(', ')}] use a reserved framework role name. ` +
+        'A tenant role of that name would be compared against the framework role by exact string match, ' +
+        'letting a tenant owner grant themselves platform authority. Rename them (e.g. "tenantAdmin") ' +
+        'and declare platform-wide roles via multiTenancy.globalOnlyRoles.',
+    );
+  }
+
+  // 2. A role cannot be global and tenant-scoped at once — it would need two sources of truth.
+  const both = declaredGlobal.filter((role) => hierarchy.includes(role) || additional.includes(role));
+  if (both.length) {
+    throw new Error(
+      `multiTenancy: role(s) [${both.join(', ')}] are declared BOTH in globalOnlyRoles and as tenant roles. ` +
+        'Each role must resolve against exactly one source (user.roles for global, membership.role for tenant).',
+    );
+  }
+
+  // 3. A declared global role must not be a system role either.
+  const systemGlobals = declaredGlobal.filter((role) => looksLikeSystemRole(role));
+  if (systemGlobals.length) {
+    throw new Error(
+      `multiTenancy.globalOnlyRoles contains system role(s) [${systemGlobals.join(', ')}]. ` +
+        'System roles are runtime-context checks and are never stored or granted.',
+    );
+  }
+}
+
 /**
- * Check if a role is a system role (S_USER, S_EVERYONE, etc.).
- * System roles are checked by RolesGuard/BetterAuthRolesGuard for authentication
- * and by CoreTenantGuard as OR alternatives before real role checks.
+ * Split required roles into the ones only the PLATFORM can satisfy and the ones a TENANT can.
+ *
+ * This split is the tenant boundary. Membership roles are customer-assigned free text, and in
+ * tenant context they are compared against required roles by exact string match — so without the
+ * split, a member whose tenant role is literally `'admin'` satisfies `@Roles(RoleEnum.ADMIN)`, the
+ * global platform role. Anyone allowed to manage members (a tenant owner, i.e. a customer) could
+ * mint platform-wide access for themselves.
+ *
+ * Callers must resolve each half against its own source:
+ * - `global` → `user.roles` (never the membership role)
+ * - `tenant` → `membership.role` in tenant context, `user.roles` otherwise
+ *
+ * OR semantics across the two halves: satisfying either is enough, which keeps
+ * `@Roles(ADMIN, 'owner')` working as the alternative it reads as.
  */
-export function isSystemRole(role: string): boolean {
-  return role.startsWith(SYSTEM_ROLE_PREFIX);
+export function resolveGlobalAndTenantRoles(requiredRoles: string[]): { global: string[]; tenant: string[] } {
+  const global: string[] = [];
+  const tenant: string[] = [];
+  for (const role of requiredRoles ?? []) {
+    // The registry knows framework roles, project-declared global roles and configured tenant
+    // roles. `isGlobalOnlyRole` is kept as the floor so RoleEnum.ADMIN is global even before any
+    // source is registered (e.g. a unit test constructing the helper in isolation).
+    const scope = roleScopeRegistry.scopeOf(role);
+    (scope === RoleScope.GLOBAL || isGlobalOnlyRole(role) ? global : tenant).push(role);
+  }
+  return { global, tenant };
+}
+
+/**
+ * Which required roles may a TENANT MEMBERSHIP satisfy?
+ *
+ * Two tiers, and the distinction is the whole design:
+ *
+ * 1. **Unconditional** — roles with GLOBAL scope are never satisfiable by a membership. This is the
+ *    security fix: a customer-assigned role must not answer for the platform. Always on.
+ * 2. **Opt-in** (`multiTenancy.strictMembershipRoles`) — narrow further to roles the project
+ *    DECLARED as tenant-scoped, so an undeclared name cannot line up with a membership by
+ *    coincidence.
+ *
+ * Tier 2 is not the default on purpose. A project may legitimately use exact-match roles that
+ * appear only in `@Roles()` and in its membership data and never in `roleHierarchy`; denying those
+ * at the guard by default would be a silent, fleet-wide lockout — a worse failure than the case it
+ * guards against, which tier 1 already covers as soon as the role is declared global.
+ */
+export function tenantSatisfiableRoles(requiredRoles: string[]): string[] {
+  // Always excluded: roles whose authority is global. That is the security fix, and it is
+  // unconditional — a customer-assigned membership role must never answer for the platform.
+  const candidates = resolveGlobalAndTenantRoles(requiredRoles).tenant;
+
+  // Beyond that, opt-in. `strictMembershipRoles` narrows matching to roles the project actually
+  // DECLARED, so an undeclared name cannot line up with a membership by coincidence.
+  //
+  // It is deliberately NOT the default: a project may legitimately use exact-match roles that
+  // appear only in @Roles() and in its membership data, never in roleHierarchy. Denying those by
+  // default would break such setups at the guard — a silent, fleet-wide lockout — for a case the
+  // global/tenant split already covers as soon as the role is declared global.
+  if (!ConfigService.configFastButReadOnly?.multiTenancy?.strictMembershipRoles) {
+    return candidates;
+  }
+
+  return candidates.filter((role) => roleScopeRegistry.isTenantRole(role));
 }
 
 /**

package/src/core/modules/tenant/core-tenant.module.ts

@@ -3,8 +3,10 @@ import { APP_GUARD } from '@nestjs/core';
 import { MongooseModule, SchemaFactory, getModelToken } from '@nestjs/mongoose';
 import { Model } from 'mongoose';
 
+import { roleScopeRegistry } from './core-role-scope.registry';
 import { CoreTenantMemberModel } from './core-tenant-member.model';
 import { TENANT_MEMBER_MODEL_TOKEN } from './core-tenant.enums';
+import { assertRoleVocabularyIsCoherent, configRoleScopeSource } from './core-tenant.helpers';
 import { CoreTenantGuard } from './core-tenant.guard';
 import { CoreTenantService } from './core-tenant.service';
 
@@ -58,6 +60,16 @@ export interface CoreTenantModuleOptions {
 @Module({})
 export class CoreTenantModule {
   static forRoot(options: CoreTenantModuleOptions = {}): DynamicModule {
+    // Teach the role-scope registry which roles are global and which are tenant-scoped, then
+    // refuse to boot on a vocabulary that cannot be enforced coherently (a tenant role named after
+    // a framework role, or one role declared in both scopes). An ambiguous authorization rule is
+    // worse than a server that does not start, so this throws rather than warns.
+    //
+    // Registration is idempotent: forRoot() may run more than once across test module fixtures.
+    roleScopeRegistry.clear();
+    roleScopeRegistry.register(configRoleScopeSource);
+    assertRoleVocabularyIsCoherent();
+
     const MemberModel = options.memberModel || CoreTenantMemberModel;
     const Guard = options.guard || CoreTenantGuard;
     const Service = options.service || CoreTenantService;

package/src/core/modules/tenant/core-tenant.service.ts

@@ -2,6 +2,7 @@ import { BadRequestException, Injectable, Logger, NotFoundException, Optional }
 import { InjectModel } from '@nestjs/mongoose';
 import { Model } from 'mongoose';
 
+import { looksLikeGlobalOnlyRole, looksLikeSystemRole, SYSTEM_ROLE_PREFIX } from '../../common/enums/role.enum';
 import { ConfigService } from '../../common/services/config.service';
 import { RequestContext } from '../../common/services/request-context.service';
 import { CoreTenantMemberModel } from './core-tenant-member.model';
@@ -101,6 +102,7 @@ export class CoreTenantService {
       throw new BadRequestException('userId must not be empty');
     }
     const effectiveRole = role ?? this.getDefaultRole();
+    assertAssignableMembershipRole(effectiveRole);
 
     // Check for existing membership
     const existing = await this.getMembership(tenantId, userId);
@@ -188,6 +190,7 @@ export class CoreTenantService {
     if (!role?.trim()) {
       throw new BadRequestException('role must not be empty');
     }
+    assertAssignableMembershipRole(role);
     const highestRole = this.getHighestRole();
 
     // If demoting from highest role, ensure it's not the last one
@@ -242,3 +245,56 @@ export class CoreTenantService {
     });
   }
 }
+
+/**
+ * Refuse a membership role that would cross the tenant boundary.
+ *
+ * Membership roles are customer-assigned free text, and whoever may manage members is typically a
+ * tenant owner — a customer. Two families of name must never become one:
+ *
+ * - **system roles** (`s_*`) are runtime-context questions ("is this the owner of the record?"),
+ *   not stored roles. A membership named `s_self` used to satisfy `@Restricted(S_SELF)` on
+ *   arbitrary records.
+ * - **global-only roles** (`RoleEnum.ADMIN`) are platform authority. A membership named `admin`
+ *   used to satisfy `@Roles(RoleEnum.ADMIN)` — the global role — inside tenant context.
+ *
+ * This is the SECOND layer, not the protection itself. The guards resolve each required role
+ * against its own source (`user.roles` vs `membership.role`), so an already-stored dangerous name
+ * is inert even without this check — which matters, because a future `RoleEnum` addition would
+ * otherwise turn every pre-existing membership of that name into a hole retroactively. This check
+ * only stops new ones from being created, and gives a clear error instead of silent inertness.
+ */
+export function assertAssignableMembershipRole(role: string): void {
+  if (looksLikeSystemRole(role)) {
+    throw new BadRequestException(
+      `A system role (${SYSTEM_ROLE_PREFIX}*) must never be used as a tenant membership role: ${role}`,
+    );
+  }
+  if (looksLikeGlobalOnlyRole(role)) {
+    throw new BadRequestException(
+      `"${role}" is a global role and must never be used as a tenant membership role — ` +
+        'use a tenant-specific name such as "tenantAdmin" instead',
+    );
+  }
+
+  // Deny by default, when enabled: only roles the project actually declared.
+  //
+  // An undeclared role can never GRANT anything either way — the guards match only declared tenant
+  // roles — so this does not change access decisions. What it changes is WHEN the mistake surfaces:
+  // as a 400 at assignment time, instead of as a membership that silently authorizes nothing while
+  // looking perfectly fine in a members list.
+  const config = ConfigService.configFastButReadOnly?.multiTenancy;
+  if (config?.strictMembershipRoles) {
+    const declared = new Set([
+      ...Object.keys(config.roleHierarchy ?? DEFAULT_ROLE_HIERARCHY),
+      ...(config.additionalMembershipRoles ?? []),
+    ]);
+    if (!declared.has(role)) {
+      throw new BadRequestException(
+        `"${role}" is not a declared tenant role. Declared: [${[...declared].sort().join(', ')}]. ` +
+          'Add it to multiTenancy.roleHierarchy or multiTenancy.additionalMembershipRoles, ' +
+          'or disable multiTenancy.strictMembershipRoles.',
+      );
+    }
+  }
+}

package/src/core/modules/tus/README.md

@@ -380,13 +380,52 @@ query {
 
 The following metadata is stored with each GridFS file:
 
-| Field              | Source                            |
-| ------------------ | --------------------------------- |
-| `filename`         | From TUS `Upload-Metadata` header |
-| `contentType`      | From TUS `filetype` metadata      |
-| `tusUploadId`      | Original TUS upload ID            |
-| `originalMetadata` | All TUS metadata                  |
-| `uploadedAt`       | Completion timestamp              |
+| Field              | Source                                |
+| ------------------ | ------------------------------------- |
+| `filename`         | From TUS `Upload-Metadata` header     |
+| `contentType`      | From TUS `filetype` metadata          |
+| `tusUploadId`      | Original TUS upload ID                |
+| `originalMetadata` | All TUS metadata                      |
+| `ownerId`          | The authenticated uploader (11.35.0+) |
+| `uploadedAt`       | Completion timestamp                  |
+
+### Upload ownership (11.35.0+)
+
+`tus.roles` decides **who may reach the endpoint**. It says nothing about **which upload** a caller may
+touch — and the protocol is built around a per-upload URL: after `POST /tus` the client holds
+`/tus/<id>` and uses it for `HEAD` (offset), `PATCH` (append bytes) and `DELETE` (terminate). Until
+11.35.0 all three carried only that coarse gate, so any other authenticated caller who learned an id
+could resume, **overwrite** or destroy somebody else's upload. Overwriting is the sharp end: the bytes
+are migrated into the file store under the ORIGINAL uploader's filename.
+
+Two things changed:
+
+- **`onUploadCreate` records the creator** in the upload's own metadata under
+  `TUS_OWNER_METADATA_KEY` (`ltOwnerId`). It **overwrites** any client-supplied value — metadata
+  arrives in the `Upload-Metadata` header, so a merged value would let a caller name somebody else as
+  the owner.
+- **`onIncomingRequest` refuses a request naming an upload the caller does not own**, with **404** — the
+  same "a refusal is indistinguishable from a missing resource" policy the file module uses, so the
+  endpoint is not an existence oracle for upload ids.
+
+The finished file's metadata gains `ownerId`, which is the key
+`CoreFileService.checkRights()` documents — so a tus-uploaded file can finally satisfy a per-file
+ownership rule. Before this it could not: the rule failed closed for everyone but ADMIN, and a project
+following the documented pattern ended up with files nobody could download.
+
+**An owner-LESS upload stays reachable by anyone who may reach the endpoint.** Deliberately: uploads
+created before 11.35.0 carry no owner, and neither does an intentionally public form
+(`tus.roles: [RoleEnum.S_EVERYONE]`). Denying those would break in-flight uploads on upgrade and a
+documented configuration. What is closed is an upload that HAS an owner being touched by somebody else.
+
+Both `readRequestUserId()` and `assertUploadOwnership()` are `protected` — override to read the owner
+from elsewhere (an API key, a signed form token), or to let a support role resume any upload.
+
+> **Note for a custom service:** `@tus/server` v2 does NOT hand the Express request to its hooks. It
+> converts the Node request into a WHATWG `ServerRequest` first, so anything a guard attached lives on
+> the original request, reachable through `runtime.node.req` — which is why `readRequestUserId()` checks
+> there as well. Reading only `req.user` finds nothing and every upload silently becomes owner-less,
+> failing in the permissive direction.
 
 ---
 

package/src/core/modules/tus/core-tus.service.ts

@@ -18,6 +18,7 @@ import {
   FilesystemFileHelper,
 } from '../file/filesystem-file.helper';
 import { S3_FILES_COLLECTION, S3FileHelper } from '../file/s3-file.helper';
+import { TUS_OWNER_METADATA_KEY } from './tus.constants';
 import { TusRedisLocker } from './tus-redis-locker';
 import {
   DEFAULT_TUS_ALLOWED_HEADERS,
@@ -181,6 +182,11 @@ export class CoreTusService implements OnModuleDestroy, OnModuleInit {
       const contentType = metadata.filetype || 'application/octet-stream';
       const fileMetadata = {
         originalMetadata: metadata,
+        // The key `CoreFileService.checkRights()` documents for a per-file ownership rule. Without it
+        // a tus-uploaded file could never satisfy that rule — it failed CLOSED for everyone but
+        // ADMIN, so a project following the documented pattern ended up with undownloadable files.
+        // Written from the SERVER-recorded owner, never from the client's own metadata.
+        ...(metadata[TUS_OWNER_METADATA_KEY] ? { ownerId: metadata[TUS_OWNER_METADATA_KEY] } : {}),
         tusUploadId: upload.id,
         uploadedAt: new Date(),
       };
@@ -460,6 +466,79 @@ export class CoreTusService implements OnModuleDestroy, OnModuleInit {
     await this.deleteStagedUpload(upload.id);
   }
 
+  /**
+   * The authenticated caller's id, as the upstream role guard left it on the request.
+   *
+   * `CoreTusController.handleTus(req, res)` receives the Express request, so `req.user` is whatever
+   * the guard put there. But `@tus/server` v2 does NOT hand that object to its hooks: `handle()`
+   * converts the Node request into a WHATWG `ServerRequest` (srvx) first, and anything the guard
+   * attached lives on the ORIGINAL request, reachable through `runtime.node.req`. Reading only
+   * `req.user` therefore finds nothing and every upload silently becomes owner-less — which fails in
+   * the permissive direction, so it would not have shown up as an error anywhere.
+   *
+   * Returns `undefined` for an unauthenticated request, which is a legitimate state: a project may
+   * open the gate with `tus.roles: [RoleEnum.S_EVERYONE]` for a public form.
+   *
+   * Override to read the owner from somewhere else (an API key, a signed form token).
+   */
+  protected readRequestUserId(req: any): string | undefined {
+    const id = req?.user?.id ?? req?.runtime?.node?.req?.user?.id ?? req?.context?.user?.id;
+    return id === undefined || id === null || id === '' ? undefined : String(id);
+  }
+
+  /**
+   * Refuse a request that names an upload the caller does not own.
+   *
+   * `tus.roles` is the coarse gate — who may reach the endpoint at all. This is the fine one: HEAD
+   * (read the offset), PATCH (APPEND BYTES) and DELETE (terminate) all address an upload by its URL,
+   * and without this any authenticated caller who learns an id could resume, overwrite or destroy
+   * somebody else's upload. Appending is the sharpest: those bytes are then migrated into the file
+   * store under the ORIGINAL uploader's filename, so the attacker's content is served as the victim's.
+   *
+   * **Refuses with 404, never 403** — the same policy `CoreFileService.checkRights()` states: a
+   * refusal must be indistinguishable from an upload that does not exist, or the endpoint becomes an
+   * existence oracle for ids that are not secrets.
+   *
+   * **An OWNER-LESS upload stays reachable by anyone who may reach the endpoint.** That is deliberate
+   * and load-bearing for backward compatibility: uploads created before 11.35.0 carry no owner, and
+   * so does every upload of a project that deliberately runs the endpoint public. Denying those would
+   * turn an upgrade into a fleet-wide breakage of in-flight uploads and break a documented
+   * configuration. What is closed is the case that actually leaks: an upload that HAS an owner being
+   * touched by somebody else.
+   *
+   * Override to widen this — e.g. to let a support role resume any upload.
+   */
+  protected async assertUploadOwnership(req: any, uploadId: string): Promise<void> {
+    // No id: this is a creation (POST) or a server-capability request (OPTIONS). Nothing to own yet.
+    if (!uploadId) {
+      return;
+    }
+
+    let owner: string | undefined;
+    try {
+      const upload = await (this.tusServer as any)?.datastore?.getUpload?.(uploadId);
+      const recorded = upload?.metadata?.[TUS_OWNER_METADATA_KEY];
+      owner = recorded === undefined || recorded === null ? undefined : String(recorded);
+    } catch {
+      // Unknown id, or a store that cannot answer right now. Say nothing and let the tus server
+      // produce its own 404 — inventing a refusal here would also refuse legitimate retries during a
+      // transient store outage.
+      return;
+    }
+
+    if (!owner) {
+      return; // owner-less upload — see the note above
+    }
+
+    const caller = this.readRequestUserId(req);
+    if (caller && caller === owner) {
+      return;
+    }
+
+    this.logger.warn(`Refused tus request for upload ${uploadId}: caller is not its owner`);
+    throw Object.assign(new Error('Upload not found'), { body: 'Upload not found', status_code: 404 });
+  }
+
   /**
    * Validate file type against allowedTypes configuration
    *
@@ -519,11 +598,20 @@ export class CoreTusService implements OnModuleDestroy, OnModuleInit {
       datastore,
       ...(locker ? { locker } : {}),
       maxSize: this.config.maxSize,
-      onUploadCreate: async (_req, upload) => {
+      // Every request that names an upload — HEAD (offset), PATCH (append bytes), DELETE
+      // (terminate) — is checked against the upload's recorded owner. `tus.roles` alone cannot do
+      // this: it decides who may reach the endpoint, not which upload they may touch, and the tus
+      // protocol is built around a per-upload URL. Appending is the sharp end — bytes PATCHed into
+      // somebody else's upload are migrated into the file store under THEIR filename.
+      onIncomingRequest: async (req, uploadId) => this.assertUploadOwnership(req, uploadId),
+      onUploadCreate: async (req, upload) => {
+        // Record the creator FIRST, so the ownership check below has something to compare against.
+        // Overwrites rather than merges: see TUS_OWNER_METADATA_KEY.
+        const metadata = { ...upload.metadata, [TUS_OWNER_METADATA_KEY]: this.readRequestUserId(req) ?? null };
+
         // Validate file type if allowedTypes is configured
         if (this.config.allowedTypes && this.config.allowedTypes.length > 0) {
-          const metadata = this.parseMetadata(upload.metadata);
-          const filetype = metadata.filetype;
+          const filetype = this.parseMetadata(upload.metadata).filetype;
 
           if (!this.validateFileType(filetype)) {
             const allowedList = this.config.allowedTypes.join(', ');
@@ -541,8 +629,9 @@ export class CoreTusService implements OnModuleDestroy, OnModuleInit {
           }
         }
 
-        // Return empty object to proceed with upload
-        return {};
+        // Returning the metadata is what PERSISTS the owner — the tus server writes the returned
+        // value onto the upload. Returning `{}` here would keep the client's own metadata verbatim.
+        return { metadata };
       },
       onUploadFinish: async (_req, upload) => {
         try {

package/src/core/modules/tus/index.ts

@@ -2,4 +2,5 @@
 export * from './core-tus.controller';
 export * from './core-tus.service';
 export * from './interfaces/tus-config.interface';
+export * from './tus.constants';
 export * from './tus.module';

package/src/core/modules/tus/tus.constants.ts

@@ -1,5 +1,5 @@
 /**
- * Dependency-injection tokens of the TUS module.
+ * Dependency-injection tokens AND cross-file constants of the TUS module.
  *
  * They live in a dedicated, import-free leaf file — never in `tus.module.ts` or a service — so that
  * no file needing a token has to import the module (or vice versa) and close an import cycle.
@@ -23,3 +23,19 @@
  * Injected type: `Required<ITusConfig>`.
  */
 export const TUS_CONFIG = 'TUS_CONFIG';
+
+/**
+ * Metadata key recording WHO created a tus upload, in the upload's own (staged) metadata.
+ *
+ * Framework-owned and ALWAYS overwritten in `onUploadCreate` — metadata otherwise arrives from the
+ * client in the `Upload-Metadata` header, so a merged value would let a caller declare somebody else
+ * as the owner and hand themselves access to the victim's upload URL.
+ *
+ * Deliberately NOT `ownerId`: that is the key of the FINISHED FILE's metadata (the one
+ * `CoreFileService.checkRights()` documents), and keeping the two distinct means a project's own
+ * `ownerId` metadata on a file cannot be confused with the upload-time record.
+ *
+ * It lives here rather than in the service for the same reason the token above does — and because
+ * `tests/unit/import-cycle-invariants.spec.ts` enforces exactly that placement.
+ */
+export const TUS_OWNER_METADATA_KEY = 'ltOwnerId';

package/src/core/modules/user/core-user.service.ts

@@ -4,6 +4,7 @@ import crypto = require('crypto');
 import { sha256 } from 'js-sha256';
 import { Document, Model } from 'mongoose';
 
+import { looksLikeSystemRole, SYSTEM_ROLE_PREFIX } from '../../common/enums/role.enum';
 import { assignPlain, prepareServiceOptionsForCreate } from '../../common/helpers/input.helper';
 import { ServiceOptions } from '../../common/interfaces/service-options.interface';
 import { ConfigService } from '../../common/services/config.service';
@@ -263,6 +264,17 @@ export abstract class CoreUserService<
       throw new BadRequestException('Roles contains invalid values');
     }
 
+    // Reject system roles (s_*). This is the framework's canonical "assign roles" API and it writes
+    // straight through findByIdAndUpdate, so neither MapAndValidatePipe nor check() sees the values.
+    // mongooseSystemRolePlugin is the backstop below this; the explicit check here exists to fail
+    // before the DB round-trip and with a message naming the offending values.
+    const systemRoles = roles.filter((role) => looksLikeSystemRole(role));
+    if (systemRoles.length) {
+      throw new BadRequestException(
+        `System roles (${SYSTEM_ROLE_PREFIX}*) must never be stored in user.roles: ${systemRoles.join(', ')}`,
+      );
+    }
+
     // Update and return user
     return this.process(
       async () => {

package/src/core/modules/user/inputs/core-user.input.ts

@@ -1,10 +1,10 @@
 import { InputType } from '@nestjs/graphql';
-import { IsEmail } from 'class-validator';
+import { IsEmail, IsString, Matches } from 'class-validator';
 
 import { Restricted } from '../../../common/decorators/restricted.decorator';
 import { UnifiedField } from '../../../common/decorators/unified-field.decorator';
 import { ProcessType } from '../../../common/enums/process-type.enum';
-import { RoleEnum } from '../../../common/enums/role.enum';
+import { RoleEnum, SYSTEM_ROLE_PREFIX, SYSTEM_ROLE_REJECT_PATTERN } from '../../../common/enums/role.enum';
 import { CoreInput } from '../../../common/inputs/core-input.input';
 
 /**
@@ -50,12 +50,38 @@ export abstract class CoreUserInput extends CoreInput {
 
   /**
    * Roles of the user
+   *
+   * System roles (`s_*` prefix, see RoleEnum) are runtime-context checks and must NEVER be stored:
+   * `hasRole` is a plain string intersection, so a stored `s_self` would satisfy every S_SELF
+   * check (e.g. update/delete of ARBITRARY users) without the account carrying a real role.
+   * The @Restricted above limits WHO may send the field; this validator limits WHAT it may hold.
+   *
+   * A rejected value answers HTTP 400 (`Validation failed for 1 field: roles (matches)`, with the
+   * per-field message in the response body). `CoreUserCreateInput` inherits this field, so sign-up
+   * and user creation are covered too.
+   *
+   * This validator is the FIRST of three layers, not the only one — it gives the best error
+   * message, but a subclass that redeclares `roles` replaces it (MapAndValidatePipe walks the
+   * prototype chain child-first and skips a property once a child class has validated it), and
+   * `force: true` / direct Mongoose writes never reach it at all. `CoreUserService.setRoles()` and
+   * the unconditional `mongooseSystemRolePlugin` close those paths.
    */
   @Restricted({ processType: ProcessType.INPUT, roles: RoleEnum.ADMIN })
   @UnifiedField({
+    description: 'Roles of the user (system roles with s_ prefix are rejected)',
     isArray: true,
     isOptional: true,
     type: String,
+    // `opts` already carries `each: true` for array fields — do not hardcode it, or array-ness has
+    // two sources of truth. Note that supplying `validator` REPLACES the built-in `IsString`, so it
+    // is re-declared here explicitly rather than relying on `matches()` rejecting non-strings.
+    validator: (opts) => [
+      IsString(opts),
+      Matches(SYSTEM_ROLE_REJECT_PATTERN, {
+        ...opts,
+        message: `System roles (${SYSTEM_ROLE_PREFIX}*) must never be stored in user.roles`,
+      }),
+    ],
   })
   roles?: string[] = undefined;