@lenne.tech/nest-server 11.42.11 → 11.42.12

package/migration-guides/11.42.10-to-11.42.11.md

@@ -6,7 +6,7 @@
 | -------------------- | -------------------------------------------------------------------------------------------------------- |
 | **Framework API**    | No change                                                                                                |
 | **Test tooling**     | e2e low-resource cap fixed for Vitest 4, e2e run governor hardened, two `check.mjs` false greens closed (§1–§3) — reaches your project only through this guide |
-| **Tests**            | A race in tests that upload to a route a role guard refuses (§4)                                         |
+| **Tests**            | A race in tests that upload to a route a role guard refuses (§4); a red unit file in starter-derived monorepos (§7) |
 | **Documentation**    | `lt dev` exports `NSC__MONGOOSE__URI`, never `MONGODB_URI`; two older guides corrected (§5)              |
 | **Dependencies**     | `nodemailer` 10.1.0 (minor, no API change); dev tooling (§6)                                             |
 | **Breaking Changes** | None                                                                                                     |
@@ -88,7 +88,9 @@ release.
 
 ## 4. Tests that upload to a refused route: send no file
 
-Already in projects generated from **starter 11.41.9 or later** (for the avatar upload test).
+For the avatar upload test, already in projects generated from **starter 11.41.9 or later**. The two upload
+refusals in `tests/modules/file-rest.e2e-spec.ts` (401 and 403 on `/files/upload`) still attached a file until
+**starter 11.42.11**.
 
 When a role guard refuses a multipart upload route, it answers before the file interceptor reads the body. A
 test that still attaches a file races that answer: the 401/403 arrives while the client is writing the
@@ -137,6 +139,20 @@ redoing unless you adapted a script to the wrong name.
 Unchanged on purpose: `express` stays 5.2.1, because `@nestjs/platform-express` 11.2.7 pins it exactly — a
 direct bump would put two copies of express into your tree. `better-auth` stays on 1.7.7, the current release.
 
+## 7. Starter-derived monorepos: a red `audit-suppression-scope.spec.ts`
+
+Fixed in **starter 11.42.11**; affects projects generated from **starter 11.41.7 or later** inside a
+fullstack monorepo.
+
+`tests/unit/audit-suppression-scope.spec.ts` read `pnpm-workspace.yaml` from the API project at COLLECTION
+time. In a monorepo the API has no `pnpm-workspace.yaml` of its own (it lives at the workspace root), so the
+whole file failed to load with `ENOENT` and the unit suite went red without a single test running. The
+starter now reads the file inside the test and guards the monorepo layout with
+`tests/unit/hoisted-layout.spec.ts`; copy both from the current starter.
+
+Optional, also new in starter 11.42.11: its `scripts/check.mjs` ends a hanging `pnpm audit` after a timeout
+(`CHECK_AUDIT_TIMEOUT`) and reports it as not checked, instead of stalling the whole `check`.
+
 ## Compatibility Notes
 
 | Pattern | Status |

package/migration-guides/11.42.11-to-11.42.12.md

@@ -0,0 +1,142 @@
+# Migration Guide: 11.42.11 → 11.42.12
+
+## Overview
+
+| Category             | Details                                                                                                  |
+| -------------------- | -------------------------------------------------------------------------------------------------------- |
+| **Security**         | Password-reset and verification links are no longer printed on deployed `develop` / `test` stages (§1); auth cookies carry `Secure` on every https deployment, whatever the environment is called (§2) |
+| **Framework API**    | Additive only: `isLocalEnv()`, `CoreBetterAuthService.usesSecureCookies()`, optional `secureTransport` / `baseUrl` arguments on the cookie helpers |
+| **Dependencies**     | None for the package. The repository's own audit suppression for GHSA-ch52-4w7c-c8xp is gone (§3)        |
+| **Breaking Changes** | None                                                                                                     |
+| **Migration Effort** | None for most projects. Check §1 if you read auth links from a log outside `local` / `ci` / `e2e`, and §2 if you override a cookie-writing method |
+
+## Quick Migration
+
+```bash
+pnpm update @lenne.tech/nest-server
+```
+
+Vendor-mode projects pick it up with the core update. No code or configuration change is required unless one
+of the checks in §1 or §2 applies to you.
+
+## 1. Auth links are printed only in local environments
+
+`CoreBetterAuthEmailVerificationService.logAuthUrlForDevelopment()` prints the verification and password-reset
+link to stdout so a developer can follow it without a mail server. The URL carries a live bearer token — a reset
+link changes the password outright.
+
+Until this release the link was printed everywhere except `production` and `staging`. The deployed `develop` and
+`test` stages of a starter-based project are neither, so they wrote live reset links into their log pipeline,
+where read access to the logs was enough to take over an account.
+
+| Environment (`env`, else `NODE_ENV`) | Before | After |
+| ------------------------------------ | ------ | ----- |
+| `local`, `ci`, `e2e`                 | printed | printed |
+| `develop`, `test`, `development`, any other name, none at all | printed | **not printed** |
+| `production`, `staging`, `NODE_ENV=production` | not printed | not printed |
+
+`LT_LOG_AUTH_URLS` gained a value:
+
+| Value | Effect |
+| ----- | ------ |
+| unset | the table above |
+| `1`   | also print in an environment that is not in the list — for a developer machine with a different environment name |
+| `0`   | print nowhere, not even locally |
+
+`production` and `staging` never print, whatever the variable says.
+
+**What to check:**
+
+- **Your local environment has another name** (e.g. `development`): set `LT_LOG_AUTH_URLS=1` in your local
+  `.env`. Never set it on a deployment.
+- **A script or CI job reads `[EMAIL VERIFICATION]` / `[PASSWORD RESET]` from the API log** — fine as long as it
+  runs the API as `local`, `ci` or `e2e` (`lt dev up`, `lt dev test` and the starter's e2e scripts do). Against a
+  deployed stage, read the mail instead (Hub mailbox, Mailpit), which is what that stage should have been doing.
+
+The decision uses the new exported helper `isLocalEnv(env)`, which reads the existing `LOCALHOST_URL_ENVS`
+(`local`, `ci`, `e2e`). The SSRF guard's private-target allowance (`privateOutboundTargetsAllowed()`) now reads
+the same helper; its behaviour is unchanged.
+
+## 2. Auth cookies carry `Secure` on every https deployment
+
+The session cookie is written by two paths: Better-Auth's own handlers (2FA, social callback, passkey) and the
+framework's cookie helper (sign-in and sign-up through `CoreBetterAuthController`, the API middleware, and the
+legacy `token` / `refreshToken` cookies). Better-Auth sets `Secure` from an `https://` base URL. The framework
+helper set it only for `production` / `staging` — so on an https `develop` or `test` stage the cookie that
+establishes the session went out without `Secure`, while Better-Auth's handlers set it on the same deployment.
+
+Now:
+
+| Cookie | `Secure` when |
+| ------ | ------------- |
+| Better-Auth session cookie written by the framework | Better-Auth's own cookies are secure (read off the instance: `CoreBetterAuthService.usesSecureCookies()`), or the environment is production-like |
+| Legacy `token` / `refreshToken` | `baseUrl` starts with `https://`, or the environment is production-like |
+
+`Secure` is only ever added, never removed. A project that switched it off on purpose
+(`betterAuth.options.advanced.defaultCookieAttributes.secure: false`) keeps that outside production and staging.
+
+**What to check:**
+
+- **A deployment whose `baseUrl` says `https://` but whose browsers reach the API over plain http** now loses the
+  framework-written session cookie too — browsers drop a `Secure` cookie received over http. Better-Auth's own
+  handlers already behaved this way, so such a deployment had broken 2FA and social sign-in before. Fix the
+  `baseUrl` or serve https.
+- **You override a cookie-writing method.** The new inputs reach the helpers only if the caller passes them:
+
+  ```typescript
+  // A CoreAuthController / CoreAuthResolver subclass that overrides processCookies()
+  const baseUrl = this.configService.getFastButReadOnly<string>('baseUrl');
+  return setLegacyAuthCookies(res, result, cookiesConfig, env, baseUrl);
+
+  // Code that builds its own Better-Auth cookie helper
+  createCookieHelper(basePath, { ...options, secureTransport: this.betterAuthService.usesSecureCookies() });
+  ```
+
+  Without the argument the helper keeps the previous, environment-only rule — nothing breaks, the fix just does
+  not reach that path.
+- **Your tests stub `CoreBetterAuthService`**: no change needed. The controller calls `usesSecureCookies()`
+  optionally, so a stub without it keeps the previous behaviour.
+
+## 3. Audit suppression GHSA-ch52-4w7c-c8xp removed (repository only)
+
+This repository no longer lists GHSA-ch52-4w7c-c8xp (`http-cache-semantics <= 4.2.0`, dev tooling only:
+`@swc/cli` > … > `cacheable-request`) in `auditConfig.ignoreGhsas`. Its lockfile now resolves 4.3.0, which
+`cacheable-request`'s `^4.2.0` takes on any fresh resolve. Nothing here reaches the published package.
+
+4.3.0 is **not a fix**: its max-stale code is identical to 4.2.0's. It only lies outside the advisory's declared
+range, because the advisory was written as "up to the newest release" and never followed. The maintainer disputes
+the report (kornelski/http-cache-semantics#56); a withdrawal request is open (github/advisory-database#10139),
+and an independent re-test there reproduces the behaviour through 4.3.0, so a range extension is possible.
+
+**For starter-derived projects** that carry the same entry (nest-server-starter 11.41.7 – 11.42.11):
+
+- Lockfile on 4.3.0 (`pnpm why http-cache-semantics`): remove the entry from `ignoreGhsas` together with its row in
+  `tests/unit/audit-suppression-scope.spec.ts`. On 4.3.0 the entry hides nothing and would swallow the advisory
+  unseen the day its range is extended; without it, that day turns `pnpm audit` red, which is the moment to
+  re-argue the dev-only case.
+- Lockfile still on 4.2.0: `pnpm update http-cache-semantics` first, then as above. Keep the entry instead if
+  your resolve cannot move.
+
+## Compatibility Notes
+
+| Pattern | Status |
+| ------- | ------ |
+| npm-mode and vendor-mode projects without cookie-related overrides | Nothing to do |
+| `lt dev up` / `lt dev test` / starter e2e scripts reading auth links from the log | Unchanged — they run as `local` / `e2e` |
+| Subclass overriding `processCookies()` (legacy) | Pass `baseUrl` (§2), otherwise unchanged behaviour |
+| Custom `createCookieHelper()` call | Pass `secureTransport` (§2), otherwise unchanged behaviour |
+| Test stubs of `CoreBetterAuthService` | Compatible |
+
+## Troubleshooting
+
+**The `[PASSWORD RESET]` / `[EMAIL VERIFICATION]` line disappeared from your local log**
+Your environment is not named `local`, `ci` or `e2e`. Set `LT_LOG_AUTH_URLS=1` locally (§1).
+
+**After the update, sign-in succeeds but the next request is anonymous on a non-production stage**
+The browser dropped the now-`Secure` session cookie because the page or API is served over http while `baseUrl`
+says https. Serve https or correct `baseUrl` (§2).
+
+## Module Documentation
+
+- [Better-Auth module README](../src/core/modules/better-auth/README.md) — `usesSecureCookies()`
+- [Configurable features](../.claude/rules/configurable-features.md) — Cookies row, Outbound URL Guard row

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenne.tech/nest-server",
-  "version": "11.42.11",
+  "version": "11.42.12",
   "description": "Modern, fast, powerful Node.js web framework in TypeScript based on Nest with a GraphQL API and a connection to MongoDB (or other databases).",
   "keywords": [
     "node",

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

@@ -51,23 +51,37 @@ export interface AuthCookieDefaultOptions {
  *
  * - `httpOnly: true` — prevents JavaScript access (XSS mitigation)
  * - `sameSite: 'lax'` — CSRF mitigation
- * - `secure: isProductionLikeEnv(env)` — HTTPS-only in production/staging
+ * - `secure` — HTTPS-only on an `https://` `baseUrl`, and always in production/staging
  *
- * Used by both Legacy Auth and BetterAuth cookie helpers for consistent security.
+ * Used by the Legacy Auth cookie helper. (The BetterAuth helper decides `secure` the same way, but
+ * reads the https half off the Better-Auth instance.)
  *
  * @param env - App-level environment from `IServerOptions.env` (e.g. `'production'`, `'staging'`, `'ci'`).
  *              Falls back to `process.env.NODE_ENV === 'production'` if absent.
+ * @param baseUrl - The server's `IServerOptions.baseUrl`. An `https://` value sets `secure` whatever
+ *              the environment is called — since 11.42.12, because the deployed `develop` / `test`
+ *              stages of a starter-based project are not production-like and got cookies without it.
  *
  * @since 11.25.0
  */
-export function getDefaultAuthCookieOptions(env?: string): AuthCookieDefaultOptions {
+export function getDefaultAuthCookieOptions(env?: string, baseUrl?: string): AuthCookieDefaultOptions {
   return {
     httpOnly: true,
     sameSite: 'lax',
-    secure: isProductionLikeEnv(env),
+    secure: isProductionLikeEnv(env) || isHttpsUrl(baseUrl),
   };
 }
 
+/**
+ * Whether a URL uses https, the transport signal for the `Secure` cookie attribute (Better-Auth
+ * derives its own the same way). Trimmed and case-insensitive; anything that is not a string is not.
+ *
+ * @since 11.42.12
+ */
+function isHttpsUrl(url: unknown): boolean {
+  return typeof url === 'string' && url.trim().toLowerCase().startsWith('https://');
+}
+
 /**
  * Asserts that the cookies configuration is safe for production/staging environments.
  *
@@ -114,6 +128,7 @@ export function assertCookiesProductionSafe(
  * @param result - Auth result containing `token` and `refreshToken` (modified in place)
  * @param cookies - The `cookies` config value from IServerOptions
  * @param env - App-level env from `IServerOptions.env` (used for `secure` flag derivation)
+ * @param baseUrl - `IServerOptions.baseUrl`; an `https://` value sets `secure` too (since 11.42.12)
  * @returns The (possibly modified) result object
  *
  * @since 11.25.0
@@ -123,12 +138,13 @@ export function setLegacyAuthCookies<T extends { refreshToken?: string; token?:
   result: T,
   cookies: boolean | ICookiesConfig | undefined,
   env?: string,
+  baseUrl?: string,
 ): T {
   if (!isCookiesEnabled(cookies)) {
     return result;
   }
 
-  const cookieOptions = getDefaultAuthCookieOptions(env);
+  const cookieOptions = getDefaultAuthCookieOptions(env, baseUrl);
 
   // If result is absent or not an object, clear any existing cookies (logout path)
   if (!result || typeof result !== 'object') {
@@ -261,12 +277,40 @@ export const LOCALHOST_URL_DEFAULTS = {
 } as const;
 
 /**
- * Environments that fall back to {@link LOCALHOST_URL_DEFAULTS} when no URLs are configured.
+ * The LOCAL environments: they run on a developer machine or in a test job, never as a deployment.
+ *
+ * They fall back to {@link LOCALHOST_URL_DEFAULTS} when no URLs are configured, and
+ * {@link isLocalEnv} reads this list for every other "local only" decision (the SSRF guard's
+ * private targets, the auth-link log). One list, so the decisions cannot drift apart.
+ *
+ * Deliberately NOT `development` or `test`: in projects built from nest-server-starter `test` is a
+ * DEPLOYED stage (often the customer's QA stage), and `develop`/`development` name a deployed dev
+ * stage as often as a laptop.
  *
  * @since 11.27.5
  */
 export const LOCALHOST_URL_ENVS: readonly string[] = ['ci', 'e2e', 'local'];
 
+/**
+ * Checks whether the given environment is local ({@link LOCALHOST_URL_ENVS}: `local`, `ci`, `e2e`),
+ * matched trimmed and case-insensitively.
+ *
+ * Not the complement of {@link isProductionLikeEnv}. That one answers "must this be hardened?" and
+ * names only the environments that obviously hold real users; everything it does not name counts
+ * as non-production, including the deployed `develop` and `test` stages of a starter-based project.
+ * Use this one when the question is the opposite — "may this run without protection?" — so that an
+ * environment nobody listed stays protected. An unknown or missing name answers `false`.
+ *
+ * @since 11.42.12
+ */
+export function isLocalEnv(env?: string): boolean {
+  return LOCALHOST_URL_ENVS.includes(
+    String(env ?? '')
+      .trim()
+      .toLowerCase(),
+  );
+}
+
 /**
  * The hostname label stripped from `baseUrl` to derive `appUrl`.
  */

package/src/core/common/helpers/outbound-url.helper.ts

@@ -3,6 +3,7 @@ import { BlockList, isIP } from 'node:net';
 import { Agent, buildConnector, fetch as undiciFetch } from 'undici';
 
 import { ConfigService } from '../services/config.service';
+import { isLocalEnv } from './cookies.helper';
 
 /**
  * Requests to a URL a USER entered — a webhook, an export target, an ERP address.
@@ -53,12 +54,6 @@ for (const [network, prefix] of [
   blocked.addSubnet(network, prefix, 'ipv6');
 }
 
-/**
- * Environments in which internal targets are allowed unless configured otherwise. Deliberately NOT
- * `test`: in projects built from nest-server-starter that is a DEPLOYED stage.
- */
-const LOCAL_ENVIRONMENTS = new Set(['ci', 'e2e', 'local']);
-
 /** Thrown for a target that is, or resolves to, an internal address. */
 export class OutboundUrlBlockedError extends Error {
   constructor(
@@ -93,10 +88,9 @@ export function privateOutboundTargetsAllowed(): boolean {
   if (flag === false || flag === 'false') {
     return false;
   }
-  const env = String(config?.env ?? process.env.NODE_ENV ?? '')
-    .trim()
-    .toLowerCase();
-  return LOCAL_ENVIRONMENTS.has(env);
+  // Internal targets are allowed only in the local environments (`isLocalEnv`), deliberately not
+  // in `test`: in projects built from nest-server-starter that is a DEPLOYED stage.
+  return isLocalEnv(config?.env ?? process.env.NODE_ENV);
 }
 
 /** Whether an IP address is internal. A hostname (not an IP) answers false — resolve it first. */

package/src/core/modules/auth/core-auth.controller.ts

@@ -192,6 +192,7 @@ export class CoreAuthController {
   protected processCookies(res: ResponseType, result: any) {
     const cookiesConfig = this.configService.getFastButReadOnly<boolean | ICookiesConfig>('cookies');
     const env = this.configService.getFastButReadOnly<string>('env');
-    return setLegacyAuthCookies(res, result, cookiesConfig, env);
+    const baseUrl = this.configService.getFastButReadOnly<string>('baseUrl');
+    return setLegacyAuthCookies(res, result, cookiesConfig, env, baseUrl);
   }
 }

package/src/core/modules/auth/core-auth.resolver.ts

@@ -174,6 +174,7 @@ export class CoreAuthResolver {
   protected processCookies(ctx: { res: ResponseType }, result: any) {
     const cookiesConfig = this.configService.getFastButReadOnly<boolean | ICookiesConfig>('cookies');
     const env = this.configService.getFastButReadOnly<string>('env');
-    return setLegacyAuthCookies(ctx.res, result, cookiesConfig, env);
+    const baseUrl = this.configService.getFastButReadOnly<string>('baseUrl');
+    return setLegacyAuthCookies(ctx.res, result, cookiesConfig, env, baseUrl);
   }
 }

package/src/core/modules/better-auth/README.md

@@ -1505,6 +1505,7 @@ export class MyService {
 | `getBasePath()`                      | Get the base path for endpoints            |
 | `getBaseUrl()`                       | Get the base URL                           |
 | `getCookieDomain()`                  | Get resolved cross-subdomain cookie domain |
+| `usesSecureCookies()`                | Whether Better-Auth's cookies carry Secure |
 | `getSession(req)`                    | Get current session from request           |
 | `revokeSession(token)`               | Revoke a session (logout)                  |
 | `isSessionExpiringSoon(session, t?)` | Check if session is expiring soon          |

package/src/core/modules/better-auth/core-better-auth-api.middleware.ts

@@ -172,6 +172,7 @@ export class CoreBetterAuthApiMiddleware implements NestMiddleware {
           env,
           legacyCookieEnabled: false, // Middleware doesn't need legacy cookie
           secret: config?.secret, // Required for cookie signing
+          secureTransport: this.betterAuthService.usesSecureCookies?.() === true, // Same `Secure` rule as Better-Auth
         },
         this.logger,
       );

package/src/core/modules/better-auth/core-better-auth-cookie.helper.ts

@@ -81,6 +81,16 @@ export interface BetterAuthCookieHelperConfig {
    * CRITICAL: Required for Passkey/2FA to work correctly.
    */
   secret?: string;
+  /**
+   * Whether Better-Auth's own handlers set `Secure` on the cookies they write
+   * (`CoreBetterAuthService.usesSecureCookies()`). `true` makes this helper set it too, whatever the
+   * environment, so one session cookie never carries two different transport rules.
+   *
+   * @since 11.42.12 Before, `secure` followed {@link isProductionLikeEnv} alone, so on the deployed
+   *                 `develop` / `test` stages of a starter-based project the cookie this helper wrote
+   *                 lacked `Secure` while Better-Auth's handlers set it on the same https deployment.
+   */
+  secureTransport?: boolean;
 }
 
 /**
@@ -146,9 +156,11 @@ export class BetterAuthCookieHelper {
   /**
    * Gets the default cookie options for authentication cookies.
    *
-   * The `secure` flag is `true` when either `config.env` is production-like
-   * (`production` / `staging`) or `NODE_ENV === 'production'`. This covers
-   * staging deployments where only one of the two signals is set.
+   * The `secure` flag is `true` when Better-Auth's own cookies are secure (`config.secureTransport`,
+   * i.e. an `https://` base URL unless the project opted out), when `config.env` is production-like
+   * (`production` / `staging`), or when `NODE_ENV === 'production'`. The first covers every https
+   * deployment whatever its environment name; the other two keep `Secure` where real users are
+   * certain even if a project switched it off in Better-Auth.
    *
    * @returns Cookie options with httpOnly, sameSite, and secure settings
    */
@@ -156,7 +168,7 @@ export class BetterAuthCookieHelper {
     const options: AuthCookieOptions = {
       httpOnly: true,
       sameSite: 'lax',
-      secure: isProductionLikeEnv(this.config.env),
+      secure: this.config.secureTransport === true || isProductionLikeEnv(this.config.env),
     };
 
     if (this.config.domain) {
@@ -403,7 +415,13 @@ export class BetterAuthCookieHelper {
  */
 export function createCookieHelper(
   basePath: string,
-  options?: { domain?: string; env?: string; legacyCookieEnabled?: boolean; secret?: string },
+  options?: {
+    domain?: string;
+    env?: string;
+    legacyCookieEnabled?: boolean;
+    secret?: string;
+    secureTransport?: boolean;
+  },
   logger?: Logger,
 ): BetterAuthCookieHelper {
   return new BetterAuthCookieHelper({
@@ -413,5 +431,6 @@ export function createCookieHelper(
     legacyCookieEnabled: options?.legacyCookieEnabled ?? false,
     logger,
     secret: options?.secret,
+    secureTransport: options?.secureTransport,
   });
 }

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

@@ -4,7 +4,7 @@ import ejs = require('ejs');
 import * as fs from 'fs';
 import * as path from 'path';
 
-import { isProductionLikeEnv, resolveAppUrlFromConfig } from '../../common/helpers/cookies.helper';
+import { isLocalEnv, isProductionLikeEnv, resolveAppUrlFromConfig } from '../../common/helpers/cookies.helper';
 import { maskEmail } from '../../common/helpers/logging.helper';
 import { IBetterAuthEmailVerificationConfig } from '../../common/interfaces/server-options.interface';
 import { BrevoService } from '../../common/services/brevo.service';
@@ -838,25 +838,35 @@ export class CoreBetterAuthEmailVerificationService {
    * Print an auth link (verification / password reset) to stdout for local development.
    *
    * The URL embeds a bearer token: the verification link confirms an address, the reset link
-   * changes a password outright. Neither may reach a deployment holding real accounts, so the gate
-   * is `isProductionLikeEnv()` — the same two-layer check `EmailService` and the cookie helpers
-   * already use. `NODE_ENV !== 'production'` alone is NOT enough: a staging deployment sets
-   * `NODE_ENV=staging` so `getEnvironmentConfig()` loads its config block, which passes that test
-   * while holding real users.
+   * changes a password outright. Neither may reach a deployment's logs, so the link is printed only
+   * in a LOCAL environment (`isLocalEnv()`: `local`, `ci`, `e2e`) — an allowlist, not "anything
+   * that is not production". Until 11.42.12 the gate was `!isProductionLikeEnv()`, which names only
+   * `production` and `staging`; the deployed `develop` and `test` stages of a starter-based project
+   * passed it and wrote live reset links into their log pipeline, where log access alone was
+   * enough to take over an account.
+   *
+   * `LT_LOG_AUTH_URLS=1` opts in for another environment that runs on a developer machine (this
+   * repository's own `development`, for one); `LT_LOG_AUTH_URLS=0` suppresses it everywhere. A
+   * production-like environment never prints, whatever the variable says: the opt-in exists for
+   * laptops, and a hard floor keeps it from being the thing that reopens a deployment.
    *
    * The address is masked (PII, and the rest of this file already masks it); the URL is printed in
-   * full because following it without a mail server is the whole point locally. Set
-   * `LT_LOG_AUTH_URLS=0` to suppress it even outside production.
+   * full because following it without a mail server is the whole point locally.
    *
    * `console.log` rather than the NestJS logger, deliberately and for two reasons: the logger
    * buffers, which makes interception unreliable under Vitest, and a logger call would route the
    * token into `HubLogBufferService`'s ring buffer, which is readable over HTTP by any ADMIN.
    */
   protected logAuthUrlForDevelopment(label: string, email: string, url: string): void {
-    if (process.env.LT_LOG_AUTH_URLS === '0') {
+    const optIn = process.env.LT_LOG_AUTH_URLS;
+    if (optIn === '0') {
+      return;
+    }
+    const env = this.configService?.getFastButReadOnly<string>('env') ?? process.env.NODE_ENV;
+    if (isProductionLikeEnv(env)) {
       return;
     }
-    if (isProductionLikeEnv(this.configService?.getFastButReadOnly<string>('env'))) {
+    if (!isLocalEnv(env) && optIn !== '1') {
       return;
     }
     // oxlint-disable-next-line no-console

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

@@ -268,6 +268,10 @@ export class CoreBetterAuthController {
         env: this.configService.getFastButReadOnly<string>('env'),
         legacyCookieEnabled: legacyAuthEnabled,
         secret: betterAuthConfig?.secret,
+        // Mirror Better-Auth's own `Secure` decision, so the cookie this controller writes and the
+        // one Better-Auth's handlers write follow the same transport rule on every https deployment.
+        // Optional call: a project's test stub of the service may predate the method.
+        secureTransport: this.betterAuthService.usesSecureCookies?.() === true,
       },
       this.logger,
     );

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

@@ -703,6 +703,30 @@ export class CoreBetterAuthService implements OnApplicationBootstrap, OnModuleIn
     return this.config.baseUrl || 'http://localhost:3000';
   }
 
+  /**
+   * Whether Better-Auth's own handlers set `Secure` on the cookies they write, read off the live
+   * instance.
+   *
+   * `createBetterAuthInstance()` pins `useSecureCookies: false` (for the cookie NAME) and restores
+   * the transport flag through `advanced.defaultCookieAttributes.secure` on an `https://` base URL;
+   * a project may override either. Reading the instance rather than re-deriving from a URL gives
+   * exactly the answer Better-Auth applies — including the base URL it actually uses, which
+   * {@link getBaseUrl} does not know when only the server's `baseUrl` is set.
+   *
+   * The framework's own cookie helper mirrors this, so a session cookie carries `Secure` no matter
+   * which path wrote it.
+   *
+   * @since 11.42.12
+   */
+  usesSecureCookies(): boolean {
+    const advanced = (
+      this.getInstance() as unknown as {
+        options?: { advanced?: { defaultCookieAttributes?: { secure?: unknown }; useSecureCookies?: unknown } };
+      } | null
+    )?.options?.advanced;
+    return advanced?.useSecureCookies === true || advanced?.defaultCookieAttributes?.secure === true;
+  }
+
   /**
    * Gets the resolved cookie domain for cross-subdomain cookie sharing.
    *