@lenne.tech/nest-server 11.36.5 → 11.38.0

package/src/core/modules/better-auth/core-better-auth.service.ts

@@ -1,3 +1,4 @@
+import { createLocalAccountIssuer } from '@better-auth/core/db';
 import { BadRequestException, Inject, Injectable, Logger, OnModuleInit, Optional } from '@nestjs/common';
 import { InjectConnection } from '@nestjs/mongoose';
 import { Request } from 'express';
@@ -14,7 +15,15 @@ import { BetterAuthInstance } from './better-auth.config';
 import { isJwtShaped } from './core-better-auth-token.helper';
 import { BetterAuthSessionUser } from './core-better-auth-user.mapper';
 import { convertExpressHeaders, parseCookieHeader, signCookieValueIfNeeded } from './core-better-auth-web.helper';
-import { BETTER_AUTH_CONFIG, BETTER_AUTH_COOKIE_DOMAIN, BETTER_AUTH_INSTANCE } from './core-better-auth.constants';
+import {
+  ACCOUNT_ISSUER_BACKFILL_ID,
+  BACKFILL_MARKER_COLLECTION,
+  BETTER_AUTH_CONFIG,
+  BETTER_AUTH_COOKIE_DOMAIN,
+  BETTER_AUTH_INSTANCE,
+  DEFAULT_ACCOUNT_ISSUER_FIELD,
+  DEFAULT_ACCOUNT_MODEL_NAME,
+} from './core-better-auth.constants';
 
 /**
  * Result of a session validation
@@ -94,12 +103,31 @@ export class CoreBetterAuthService implements OnModuleInit {
   }
 
   /**
-   * Ensure performance indices exist on the session, users, account and verification collections.
-   * Indices are idempotent — calling createIndex on an existing index is a no-op.
+   * Boot steps for the better-auth integration.
+   *
+   * Two jobs live here and they are deliberately separate methods: ensuring indices is a
+   * PERFORMANCE concern that repeats forever and degrades gracefully (hence `warn`), while the
+   * issuer backfill is a CORRECTNESS concern that should happen once and locks users out when it
+   * does not (hence `error`). Keeping them in one method made those two severities look like one
+   * decision.
+   *
+   * Order matters: the backfill's update can use the `{ providerId: 1, userId: 1 }` index created
+   * below, so indices come first.
    */
   async onModuleInit(): Promise<void> {
     if (!this.isEnabled() || !this.connection?.db) return;
 
+    await this.ensureIndices();
+    await this.backfillAccountIssuers();
+  }
+
+  /**
+   * Ensure performance indices exist on the session, users, account and verification collections.
+   * Indices are idempotent — calling createIndex on an existing index is a no-op.
+   */
+  protected async ensureIndices(): Promise<void> {
+    if (!this.connection?.db) return;
+
     try {
       const db = this.connection.db;
 
@@ -130,6 +158,154 @@ export class CoreBetterAuthService implements OnModuleInit {
     }
   }
 
+  /**
+   * Backfills `account.issuer` on rows written before better-auth 1.7.
+   *
+   * From 1.7 an account is keyed by (issuer, accountId), and sign-in filters on
+   * it verbatim:
+   *
+   *   account.providerId === 'credential' && account.issuer === credentialIssuer
+   *
+   * A row written by 1.6 has no `issuer` at all, so that comparison can never
+   * hold: every existing password user would be locked out by the upgrade
+   * itself, with a 401 and nothing in the logs to explain it. This closes that
+   * gap on the first boot after the upgrade.
+   *
+   * Idempotent — the filter only matches rows still missing the field, so the
+   * second start updates nothing.
+   *
+   * Scope is deliberately limited to credential accounts, where the issuer is
+   * derivable without guessing. OAuth accounts are NOT touched: their issuer
+   * depends on the provider (a real OIDC issuer, or the synthetic
+   * `local:oauth:<id>` fallback), and writing the wrong one would not fail
+   * loudly — it would create a second account on the next social sign-in. Those
+   * rows are reported instead, so the decision stays with the project.
+   *
+   * ONE THING NOT TO "TIDY UP": this package's own reads of the `account`
+   * collection filter on `providerId` alone — `syncPasswordChangeToIam`,
+   * `migrateAccountToIam` and `getMigrationStatus` in
+   * core-better-auth-user.mapper.ts. Adding `issuer` to those filters looks like
+   * consistency and is a regression. This backfill is deliberately NON-FATAL: if
+   * it fails, the server still boots and logs an error. Reads that do not require
+   * the field keep working on un-backfilled rows — `getMigrationStatus` would
+   * otherwise report zero migrated users, and `syncPasswordChangeToIam` would
+   * stop finding the account it is meant to update. Only better-auth's own
+   * sign-in path needs the issuer, and that one is better-auth's code, not ours.
+   */
+  protected async backfillAccountIssuers(): Promise<void> {
+    if (!this.isEnabled() || !this.connection?.db) return;
+
+    const db = this.connection.db;
+
+    // The consumer can rename both of these through `betterAuth.options.account`, which
+    // better-auth.config.ts spreads onto the resolved config verbatim. Hardcoding them turns this
+    // whole method into a silent no-op on such a project: nothing matches, `modifiedCount` is 0,
+    // neither log line fires, and every password user is locked out while the operator's upgrade
+    // checklist is satisfied by silence in both directions.
+    const accountOptions = (this.authInstance as any)?.options?.account;
+    const modelName: string = accountOptions?.modelName ?? DEFAULT_ACCOUNT_MODEL_NAME;
+    const issuerField: string = accountOptions?.fields?.issuer ?? DEFAULT_ACCOUNT_ISSUER_FIELD;
+
+    try {
+      const accounts = db.collection(modelName);
+
+      // A completion marker, checked before anything expensive. Without it both queries below run
+      // on EVERY boot of EVERY replica, forever — and neither is indexable (`$exists: false` cannot
+      // appear in a partialFilterExpression, `$ne` is not selective), so each is a full pass over
+      // the account collection, awaited before the app starts listening. With the marker the steady
+      // state is a single `_id` lookup. `system-setup-locks` in CoreSystemSetupService is the
+      // precedent for this kind of once-per-deployment boot state.
+      const markers = db.collection(BACKFILL_MARKER_COLLECTION);
+      if (await markers.findOne({ _id: ACCOUNT_ISSUER_BACKFILL_ID as any })) {
+        this.logger.debug(`account.${issuerField} backfill already completed — skipping.`);
+        return;
+      }
+
+      if (modelName !== DEFAULT_ACCOUNT_MODEL_NAME || issuerField !== DEFAULT_ACCOUNT_ISSUER_FIELD) {
+        this.logger.warn(
+          `Backfilling the account issuer against a customised schema (collection "${modelName}", ` +
+            `field "${issuerField}"). Verify these match what better-auth actually writes.`,
+        );
+      }
+
+      const pending = await accounts
+        .find({ [issuerField]: { $exists: false }, providerId: 'credential' }, { projection: { _id: 1 } })
+        .toArray();
+
+      let backfilled = 0;
+
+      if (pending.length) {
+        // `ordered: false` is load-bearing. better-auth declares a UNIQUE index on
+        // (issuer, accountId); a single pre-existing duplicate would abort an ordered write and
+        // leave every row after it untouched — those users stay locked out, with one log line and
+        // a green boot. Unordered, one bad row costs only itself.
+        const result = await accounts.bulkWrite(
+          pending.map((doc) => ({
+            updateOne: {
+              filter: { _id: doc._id },
+              update: { $set: { [issuerField]: createLocalAccountIssuer('credential') } },
+            },
+          })),
+          { ordered: false },
+        );
+
+        backfilled = result.modifiedCount;
+
+        if (backfilled > 0) {
+          this.logger.log(
+            `Backfilled account.${issuerField} on ${backfilled} credential account(s) for better-auth >= 1.7. ` +
+              'Without it these users could not sign in.',
+          );
+        }
+
+        if (backfilled < pending.length) {
+          // Do NOT write the marker in this case — the next boot must retry the remainder.
+          this.logger.error(
+            `Backfilled ${backfilled}/${pending.length} credential accounts. ` +
+              `${pending.length - backfilled} user(s) CANNOT sign in until this is resolved manually. ` +
+              'The most likely cause is a duplicate (issuer, accountId) pair from an earlier partial migration.',
+          );
+          return;
+        }
+      } else {
+        this.logger.debug(`No account.${issuerField} backfill needed — no credential rows predate better-auth 1.7.`);
+      }
+
+      // Only a complete run earns the marker.
+      await markers.updateOne(
+        { _id: ACCOUNT_ISSUER_BACKFILL_ID as any },
+        { $set: { backfilled, completedAt: new Date(), issuerField, modelName } },
+        { upsert: true },
+      );
+
+      // Existence probe rather than a count: `$ne` cannot use an index, so counting to the end is a
+      // guaranteed collection scan for a log line. "At least one" is all the message needs to say.
+      const staleOther = await accounts.findOne(
+        { [issuerField]: { $exists: false }, providerId: { $ne: 'credential' } },
+        { projection: { _id: 1 } },
+      );
+
+      if (staleOther) {
+        this.logger.warn(
+          `At least one non-credential account has no "${issuerField}". better-auth >= 1.7 will not match it by ` +
+            '(issuer, accountId) — and such a sign-in does NOT simply fail: it falls back to matching the user by ' +
+            'the provider-asserted email and implicitly links a SECOND account row. If the provider-side email has ' +
+            'changed, a NEW user is created instead and the existing account is orphaned, together with the provider ' +
+            'tokens on the old row, which no unlink will ever remove. Set the issuer per provider BEFORE the first ' +
+            "social sign-in after this upgrade: the provider's real OIDC issuer, or the synthetic " +
+            '"local:oauth:<providerId>".',
+        );
+      }
+    } catch (error) {
+      // Correctness, not performance — say so loudly, but do not stop the boot:
+      // a server that starts with a warning beats one that will not start at all.
+      this.logger.error(
+        `Could not backfill the account issuer: ${error instanceof Error ? error.message : 'unknown'}. ` +
+          'Existing password users may be unable to sign in until this succeeds.',
+      );
+    }
+  }
+
   /**
    * Checks if better-auth is enabled and initialized
    * Returns true only if:

package/src/core/modules/system-setup/core-system-setup.service.ts

@@ -1,3 +1,4 @@
+import { createLocalAccountIssuer } from '@better-auth/core/db';
 import { ForbiddenException, Injectable, Logger, OnApplicationBootstrap } from '@nestjs/common';
 import { InjectConnection } from '@nestjs/mongoose';
 import { isEmail } from 'class-validator';
@@ -271,11 +272,32 @@ export class CoreSystemSetupService implements OnApplicationBootstrap {
       const normalizedPassword = this.userMapper.normalizePasswordForIam(input.password);
 
       // Create user via internalAdapter (bypasses disableSignUp)
-      const iamUser = await context.internalAdapter.createUser({
-        email: input.email,
-        emailVerified: true,
-        name: input.name || input.email.split('@')[0],
-      });
+      //
+      // better-auth >= 1.7 requires a provisioning source. Without it, `createUser` throws
+      // FORBIDDEN/validation_source_missing as soon as a project configures
+      // `betterAuth.options.user.validateUserInfo`. `admin` is the honest value — the system
+      // provisions the FIRST admin, nobody signs up — and it is what better-auth's own admin
+      // plugin passes.
+      //
+      // This does NOT bypass `validateUserInfo`. The hook still runs and receives
+      // `{ method: 'admin', action: 'create-user' }`, so a project gate can still reject the
+      // initial admin; branch on `method` there if the setup should be exempt.
+      //
+      // KNOWN LIMITATION, and the reason this is spelled out: when `validateUserInfo` is
+      // configured, better-auth additionally calls `getCurrentAuthContext()`, which throws outside
+      // an endpoint context. System setup runs from `OnApplicationBootstrap` / a plain controller,
+      // never inside better-auth's request pipeline, so the call fails with
+      // FORBIDDEN/validation_context_missing and no initial admin is created. Fail-closed, but
+      // opaque. A project using that hook must provision the first admin another way — see
+      // migration-guides/11.36.x-to-11.37.0.md §7.
+      const iamUser = await context.internalAdapter.createUser(
+        {
+          email: input.email,
+          emailVerified: true,
+          name: input.name || input.email.split('@')[0],
+        },
+        { method: 'admin' },
+      );
 
       if (!iamUser) {
         throw new Error('Failed to create IAM user');
@@ -283,8 +305,14 @@ export class CoreSystemSetupService implements OnApplicationBootstrap {
 
       // Hash password and create credential account
       const hashedPassword = await context.password.hash(normalizedPassword);
+      // better-auth >= 1.7 keys accounts by (issuer, accountId) and requires the
+      // issuer. Credential accounts have no real issuer, so better-auth derives a
+      // synthetic one — always via this helper, never a hand-written literal:
+      // the format is better-auth's to change, and a copy of it would silently
+      // stop matching the accounts better-auth writes itself.
       await context.internalAdapter.linkAccount({
         accountId: iamUser.id,
+        issuer: createLocalAccountIssuer('credential'),
         password: hashedPassword,
         providerId: 'credential',
         userId: iamUser.id,

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

@@ -5,6 +5,7 @@ import { sha256 } from 'js-sha256';
 import { Document, Model } from 'mongoose';
 
 import { looksLikeSystemRole, SYSTEM_ROLE_PREFIX } from '../../common/enums/role.enum';
+import { maskEmail } from '../../common/helpers/logging.helper';
 import { assignPlain, prepareServiceOptionsForCreate } from '../../common/helpers/input.helper';
 import { ServiceOptions } from '../../common/interfaces/service-options.interface';
 import { ConfigService } from '../../common/services/config.service';
@@ -185,12 +186,41 @@ export abstract class CoreUserService<
     // Get user
     const dbObject = await this.mainDbModel.findOne({ passwordResetToken: token }).exec();
     if (!dbObject) {
-      throw new NotFoundException(`No user found with password reset token: ${token}`);
+      // The token is NOT echoed. It is attacker-supplied so nothing secret leaks, but it lands
+      // in the response body and in every log line that records the exception — and this logger
+      // feeds the ADMIN-readable Hub log buffer. An unbounded caller-controlled string there is
+      // free log-stuffing, and the message is no more useful for it.
+      throw new NotFoundException('Invalid or expired password reset token');
     }
 
-    // Store the original plain password for IAM sync before any hashing
-    // We need the plain password because IAM uses scrypt, not bcrypt+sha256
-    const plainPasswordForIamSync = /^[a-f0-9]{64}$/i.test(newPassword) ? undefined : newPassword;
+    // Capture the submitted password for the IAM sync before the closure below
+    // reassigns `newPassword` to its sha256 form.
+    //
+    // It is passed on exactly as received, INCLUDING an already-sha256-hashed
+    // one. This used to skip the sync for a 64-hex value, on the reasoning that
+    // "IAM uses scrypt, not bcrypt+sha256" — but the sync does not need a plain
+    // password: `hashPasswordForBetterAuth` runs its input through
+    // `normalizePasswordForIam`, which passes a 64-hex string through unchanged
+    // by design, and `migrateAccountToIam` is fed the very same pre-hashed value
+    // when an account is created.
+    //
+    // The guard therefore disabled the sync for exactly the clients this stack
+    // ships. The lt frontends hash in the browser before sending — seven call
+    // sites in `nuxt-extensions/src/runtime/lib/auth-client.ts` (`signIn.email`,
+    // `resetPassword`, `changePassword` and the rest) run `ltSha256` on the
+    // password first. That is independent of the `sha256` config option, which
+    // only governs what the SERVER does with a plaintext password it happens to
+    // receive. So the value arriving here is 64-hex whatever that option says,
+    // and every such reset took the skipped branch.
+    //
+    // The legacy password was updated, the IAM credential was not, and sign-in —
+    // which goes through IAM — kept accepting the OLD password and refusing the
+    // new one. The endpoint reported success throughout, so the failure surfaced
+    // only at the next sign-in.
+    //
+    // A client that posts a plaintext password was never affected: the old guard
+    // let that one through, and the sync normalized it the same way IAM does.
+    const passwordForIamSync = newPassword;
 
     return this.process(
       async () => {
@@ -204,17 +234,38 @@ export abstract class CoreUserService<
         const updatedUser = await assignPlain(dbObject, {
           password: await bcrypt.hash(newPassword, 10),
           passwordResetToken: null,
+          // A reset is what somebody reaches for after a suspected takeover, so it must not
+          // leave the attacker's session live. Clearing the refresh tokens ends every legacy
+          // session; the IAM half is `betterAuth.emailAndPassword.revokeSessionsOnPasswordReset`,
+          // which is off by default because it is a behaviour change for existing deployments —
+          // the migration guide recommends turning it on.
+          //
+          // Without this, "the reset now lands in both stores" would still leave the account
+          // reachable with the credential the reset was meant to retire.
+          refreshTokens: {},
         }).save();
 
         // Sync password to Better-Auth (IAM) if mapper is available
         // This ensures users can sign in via IAM after password reset
-        if (this.options?.betterAuthUserMapper && plainPasswordForIamSync && dbObject.email) {
+        if (this.options?.betterAuthUserMapper && passwordForIamSync && dbObject.email) {
           try {
-            await this.options.betterAuthUserMapper.syncPasswordChangeToIam(dbObject.email, plainPasswordForIamSync);
+            // Same reasoning as in update(): a `false` return means the reset landed in the
+            // legacy store only, which is the shape of failure this whole path exists to
+            // prevent. It must not be indistinguishable from success.
+            const synced = await this.options.betterAuthUserMapper.syncPasswordChangeToIam(
+              dbObject.email,
+              passwordForIamSync,
+            );
+            if (!synced) {
+              this.userServiceLogger.warn(
+                `Password reset for ${maskEmail(dbObject.email)} was NOT synced to IAM (no credential account) — ` +
+                  'the legacy password now differs from the IAM credential.',
+              );
+            }
           } catch (error) {
             // Log but don't fail - Legacy Auth password was updated successfully
             this.userServiceLogger.warn(
-              `Failed to sync password reset to IAM for ${dbObject.email}: ${error instanceof Error ? error.message : 'Unknown error'}`,
+              `Failed to sync password reset to IAM for ${maskEmail(dbObject.email)}: ${error instanceof Error ? error.message : 'Unknown error'}`,
             );
           }
         }
@@ -226,13 +277,48 @@ export abstract class CoreUserService<
   }
 
   /**
-   * Set password rest token for email
+   * Set a password-reset token for an email address
+   *
+   * Returns `null` for an unknown address when `auth.passwordReset.preventUserEnumeration` is on
+   * (the default since 11.38.0) — the caller must then answer exactly as it would for a known one.
+   * With the option off it throws `NotFoundException`, the pre-11.38.0 behaviour.
+   *
+   * WHY THE DEFAULT CHANGED
+   *
+   * Throwing made the endpoint an account oracle: HTTP 404 for an unknown address, 201 for a known
+   * one, so anyone could test who has an account. In a multi-tenant product that also answers who
+   * works at which customer. The framework already answers this correctly on the IAM path —
+   * Better-Auth's `/request-password-reset` returns the same body either way — so the two halves
+   * of one framework disagreed about the same question.
+   *
+   * THE STATUS CODE IS THE SMALLER HALF
+   *
+   * Response TIME distinguishes the cases too, and by far more: the known path writes a token and
+   * (in the caller) sends mail, the unknown path returns immediately. This method equalises what it
+   * can — the token generation still happens, so the CPU cost matches — but the mail send lives in
+   * the caller. A `sendPasswordResetMail()` that AWAITS the send leaks the difference as latency,
+   * whatever this method does. `src/server/modules/user/user.service.ts` shows the shape that does
+   * not; the IAM path uses the same trick, with the reasoning recorded in `better-auth.config.ts`.
+   *
+   * Anything measuring this honestly should say so rather than claim the channel is closed.
    */
-  async setPasswordResetTokenForEmail(email: string, serviceOptions?: ServiceOptions): Promise<TUser> {
+  async setPasswordResetTokenForEmail(email: string, serviceOptions?: ServiceOptions): Promise<null | TUser> {
     // Get user
     const dbObject = await this.mainDbModel.findOne({ email }).exec();
     if (!dbObject) {
-      throw new NotFoundException(`No user found with email: ${email}`);
+      const preventEnumeration =
+        this.configService.getFastButReadOnly('auth')?.passwordReset?.preventUserEnumeration !== false;
+
+      if (!preventEnumeration) {
+        throw new NotFoundException(`No user found with email: ${email}`);
+      }
+
+      // Do the work the known path does, so the two do not differ in CPU cost. It is cheap next to
+      // a mail send, which is why this alone does not close the timing channel — see the note above.
+      crypto.randomBytes(32).toString('hex');
+
+      this.userServiceLogger.debug(`Password reset requested for an unknown address (${maskEmail(email)})`);
+      return null;
     }
 
     return this.process(
@@ -311,10 +397,14 @@ export abstract class CoreUserService<
     const oldUser = (await this.mainDbModel.findById(id).lean().exec()) as null | TUser;
     const oldEmail = oldUser?.email;
 
-    // Store plain password for IAM sync before any hashing occurs
-    // We need to capture this before super.update() which may hash it
-    const inputPassword = (input as any).password;
-    const plainPasswordForIamSync = inputPassword && !/^[a-f0-9]{64}$/i.test(inputPassword) ? inputPassword : undefined;
+    // Capture the submitted password for the IAM sync before super.update()
+    // hashes it in place.
+    //
+    // Passed on exactly as received, including an already-sha256-hashed one —
+    // see the note in `resetPassword`: the sync normalizes a 64-hex value
+    // through unchanged, so skipping it there disabled the sync for the
+    // standard setup, where the frontend hashes before sending.
+    const passwordForIamSync = (input as any).password;
 
     // Perform the update
     const updatedUser = await super.update(id, input, serviceOptions);
@@ -333,13 +423,28 @@ export abstract class CoreUserService<
     }
 
     // Sync password change to IAM if password was changed and mapper is available
-    if (this.options?.betterAuthUserMapper && plainPasswordForIamSync && oldUser?.email) {
+    if (this.options?.betterAuthUserMapper && passwordForIamSync && oldUser?.email) {
       try {
-        await this.options.betterAuthUserMapper.syncPasswordChangeToIam(oldUser.email, plainPasswordForIamSync);
-        this.userServiceLogger.debug(`Synced password change to IAM for user ${oldUser.email}`);
+        // Report what actually happened, not that the call was made. `syncPasswordChangeToIam`
+        // answers `false` — never throws — when there is no IAM credential to update, and
+        // logging success regardless is how a half-applied password change stays invisible:
+        // the endpoint reports success, the user is left with two different passwords, and
+        // nothing in the log says so.
+        const synced = await this.options.betterAuthUserMapper.syncPasswordChangeToIam(
+          oldUser.email,
+          passwordForIamSync,
+        );
+        if (synced) {
+          this.userServiceLogger.debug(`Synced password change to IAM for user ${maskEmail(oldUser.email)}`);
+        } else {
+          this.userServiceLogger.warn(
+            `Password change for ${maskEmail(oldUser.email)} was NOT synced to IAM (no credential account) — ` +
+              'the legacy password now differs from the IAM credential.',
+          );
+        }
       } catch (error) {
         this.userServiceLogger.warn(
-          `Failed to sync password change to IAM for ${oldUser.email}: ${error instanceof Error ? error.message : 'Unknown error'}`,
+          `Failed to sync password change to IAM for ${maskEmail(oldUser.email)}: ${error instanceof Error ? error.message : 'Unknown error'}`,
         );
         // Don't throw - password sync failure shouldn't block the update
       }

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

@@ -97,11 +97,26 @@ export abstract class CoreUserInput extends CoreInput {
 
   /**
    * Password of the user
+   *
+   * Restricted to ADMIN and the account owner since 11.38.0. It used to be `S_EVERYONE`, i.e.
+   * settable by whoever was allowed to update the record at all — and `updateUser` grants that to
+   * `S_CREATOR`, which in an invite or admin-provisioning flow is the INVITING ADMIN, permanently
+   * (see `.claude/rules/role-system.md`).
+   *
+   * That was largely inert before: the lt frontends hash client-side, and the 64-hex guard then
+   * routed such a write away from the IAM sync, so it only ever landed in the legacy store — which
+   * this release also turns off by default. Removing the guard makes the same write reach the LIVE
+   * IAM credential. A dormant privilege issue would have become an account-takeover path in the
+   * very release that closes the legacy door, so the field is narrowed in the same step.
+   *
+   * A user changing their own password is unaffected (`S_SELF`). A project that genuinely needs a
+   * third party to set a password should go through an invitation or reset flow, both of which
+   * prove possession of the mailbox.
    */
   @UnifiedField({
     description: 'Password of the user',
     isOptional: true,
-    roles: RoleEnum.S_EVERYONE,
+    roles: [RoleEnum.ADMIN, RoleEnum.S_SELF],
   })
   password?: string = undefined;
 }

package/src/core.module.ts

@@ -29,6 +29,7 @@ import {
   IServerOptions,
 } from './core/common/interfaces/server-options.interface';
 import { RequestContextMiddleware } from './core/common/middleware/request-context.middleware';
+import { SecurityHeadersMiddleware } from './core/common/middlewares/security-headers.middleware';
 import { MapAndValidatePipe } from './core/common/pipes/map-and-validate.pipe';
 import { ComplexityPlugin } from './core/common/plugins/complexity.plugin';
 import { mongooseIdPlugin } from './core/common/plugins/mongoose-id.plugin';
@@ -84,6 +85,13 @@ export class CoreModule implements NestModule {
   configure(consumer: MiddlewareConsumer) {
     // RequestContext middleware must run for all routes to provide AsyncLocalStorage context
     consumer.apply(RequestContextMiddleware).forRoutes('*');
+
+    // Security headers on EVERY response, guards' rejections included. Middleware rather than an
+    // interceptor for exactly that reason: an interceptor never runs for a request a guard turns
+    // away, and those are the ones an attacker generates most of. The middleware itself decides
+    // whether it is enabled — keeping the policy in one file rather than splitting it between a
+    // config read here and the values there.
+    consumer.apply(SecurityHeadersMiddleware).forRoutes('*');
     if (CoreModule.graphQlEnabled) {
       consumer.apply(graphqlUploadExpress()).forRoutes('graphql');
     }

package/src/index.ts

@@ -73,6 +73,7 @@ export * from './core/common/interfaces/server-options.interface';
 export * from './core/common/interfaces/service-options.interface';
 export * from './core/common/middleware/request-context.middleware';
 export * from './core/common/middlewares/to-lower-case.middleware';
+export * from './core/common/middlewares/security-headers.middleware';
 export * from './core/common/models/core-model.model';
 export * from './core/common/models/core-persistence.model';
 export * from './core/common/models/pagination-info.model';
@@ -133,11 +134,13 @@ export * from './core/modules/auth/core-auth.controller';
 export * from './core/modules/auth/core-auth.model';
 export * from './core/modules/auth/core-auth.module';
 export * from './core/modules/auth/core-auth.resolver';
+export * from './core/modules/auth/core-legacy-auth-deprecation.initializer';
 export * from './core/modules/auth/exceptions/expired-refresh-token.exception';
 export * from './core/modules/auth/exceptions/expired-token.exception';
 export * from './core/modules/auth/exceptions/invalid-token.exception';
 export * from './core/modules/auth/exceptions/legacy-auth-disabled.exception';
 export * from './core/modules/auth/guards/auth.guard';
+export * from './core/modules/auth/helpers/legacy-endpoints.helper';
 export * from './core/modules/auth/guards/legacy-auth-rate-limit.guard';
 export * from './core/modules/auth/guards/roles-guard-registry';
 export * from './core/modules/auth/guards/roles.guard';

package/src/server/modules/user/user.controller.ts

@@ -144,7 +144,13 @@ export class UserController {
   @Post('password/reset-request')
   @Roles(RoleEnum.S_EVERYONE)
   async requestPasswordResetMail(@Body('email') email: string): Promise<boolean> {
-    return !!(await this.userService.sendPasswordResetMail(email));
+    // Always `true`, whether or not the address exists. `sendPasswordResetMail` returns `null` for
+    // an unknown one (see CoreUserService.setPasswordResetTokenForEmail), and forwarding that as
+    // `false` would rebuild the account oracle one layer up: the status code is equal, the body
+    // is not. The caller is told the same thing either way — "if this address is known, mail is on
+    // its way" — which is the only honest answer that reveals nothing.
+    await this.userService.sendPasswordResetMail(email);
+    return true;
   }
 
   /**

package/src/server/modules/user/user.resolver.ts

@@ -125,7 +125,13 @@ export class UserResolver {
   @Mutation(() => Boolean, { description: 'Request new password for user with email' })
   @Roles(RoleEnum.S_EVERYONE)
   async requestPasswordResetMail(@Args('email') email: string): Promise<boolean> {
-    return !!(await this.userService.sendPasswordResetMail(email));
+    // Always `true`, whether or not the address exists. `sendPasswordResetMail` returns `null` for
+    // an unknown one (see CoreUserService.setPasswordResetTokenForEmail), and forwarding that as
+    // `false` would rebuild the account oracle one layer up: the status code is equal, the body
+    // is not. The caller is told the same thing either way — "if this address is known, mail is on
+    // its way" — which is the only honest answer that reveals nothing.
+    await this.userService.sendPasswordResetMail(email);
+    return true;
   }
 
   /**

package/src/server/modules/user/user.service.ts

@@ -74,19 +74,45 @@ export class UserService extends CoreUserService<User, UserInput, UserCreateInpu
 
   /**
    * Request password reset mail
+   *
+   * REFERENCE IMPLEMENTATION — the two details below are the ones that matter, and a project
+   * copying this method needs both. Either one alone leaves the endpoint an account oracle.
+   *
+   * 1. An unknown address yields `null` (since 11.38.0, unless
+   *    `auth.passwordReset.preventUserEnumeration` is off) and this method returns quietly, so the
+   *    caller answers the same way it would for a known one.
+   * 2. The mail send is NOT awaited. This is the half that actually closes the channel: the send
+   *    is a network round trip to SMTP or Brevo, orders of magnitude above everything else in the
+   *    request. Awaiting it would make the known path visibly slower whatever the status code says
+   *    — you would have given up the "unknown address" hint in the UI and kept the oracle.
+   *
+   * A failed send must still be reported rather than crash the process, which is why it carries
+   * its own `catch`. The user is told the mail is on its way either way; that is the same trade
+   * Better-Auth makes on the IAM path.
    */
-  async sendPasswordResetMail(email: string, serviceOptions?: ServiceOptions): Promise<User> {
+  async sendPasswordResetMail(email: string, serviceOptions?: ServiceOptions): Promise<null | User> {
     // Set password reset token
     const user = await super.setPasswordResetTokenForEmail(email, serviceOptions);
 
-    // Send email
-    await this.emailService.sendMail(user.email, 'Password reset', {
-      htmlTemplate: 'password-reset',
-      templateData: {
-        link: `${this.configService.configFastButReadOnly.email.passwordResetLink}/${user.passwordResetToken}`,
-        name: user.username,
-      },
-    });
+    if (!user) {
+      // Unknown address, enumeration protection on. Answer exactly as for a known one.
+      return null;
+    }
+
+    // Deliberately NOT awaited — see the note above.
+    void this.emailService
+      .sendMail(user.email, 'Password reset', {
+        htmlTemplate: 'password-reset',
+        templateData: {
+          link: `${this.configService.configFastButReadOnly.email.passwordResetLink}/${user.passwordResetToken}`,
+          name: user.username,
+        },
+      })
+      .catch((error: unknown) => {
+        this.userServiceLogger.error(
+          `Failed to send the password-reset mail: ${error instanceof Error ? error.message : String(error)}`,
+        );
+      });
 
     // Return user
     return user;