@lenne.tech/nest-server 11.42.10 → 11.42.12

package/migration-guides/11.27.2-to-11.27.3.md

@@ -155,8 +155,10 @@ some projects copied `scripts/check.mjs` from 11.27.1+:
   no longer wipe each other's users/sessions mid-flight. A new reporter
   (`tests/db-lifecycle.reporter.ts`) drops the DB after a successful run and
   collects stale leftovers; after a failed run the DB is kept for debugging
-  until the next successful run. An externally set `MONGODB_URI` (CI) keeps
-  the previous behavior.
+  until the next successful run. An externally set `NSC__MONGOOSE__URI` (CI)
+  keeps the previous behavior. (This line originally said `MONGODB_URI`, the
+  variable the framework's own test setup reads; a starter-derived project's
+  `tests/global-setup.ts` reads `NSC__MONGOOSE__URI`.)
 
 ---
 

package/migration-guides/11.36.3-to-11.36.4.md

@@ -35,10 +35,15 @@ fix reaches an existing project.
 1. Your project's slug contains `ci`, `test`, `e2e` or `acctest` **as a substring** — including
    inside an ordinary word: `ci` hides in so**ci**al, spe**ci**al, finan**ci**al, invoi**ci**ng,
    pri**ci**ng, muni**ci**pal; `test` hides in la**test**, con**test**, **test**imonials.
-2. You use `lt dev up`, which exports `MONGODB_URI` pointing at `<slug>-local` — your **development**
-   database.
+2. You use `lt dev up`, which exports `NSC__MONGOOSE__URI` pointing at `<slug>-local` — your
+   **development** database, and the variable your `tests/global-setup.ts` drops when it is set.
 3. You started the e2e suite from that same shell.
 
+> **Correction (11.42.x):** earlier versions of this guide named `MONGODB_URI` throughout. That is
+> the variable the framework's OWN test setup reads; `lt dev` never sets it. A starter-derived
+> project's `tests/global-setup.ts` reads `NSC__MONGOOSE__URI`, which `lt dev` does export — so
+> the steps below are right for your project, only the variable name was wrong.
+
 Then `tests/global-setup.ts` dropped that database. The guard meant to prevent exactly this accepted
 it, because it matched the marker anywhere in the name rather than as a delimited segment.
 
@@ -82,7 +87,7 @@ cannot:
 
 **A second guard for the one drop site that has no other condition.** The startup sweep and the
 post-run collection both additionally require `isStaleTestDb()` — the name must belong to your own
-base. The externally-supplied-`MONGODB_URI` branch has no such backstop, and a project slug may
+base. The externally-supplied-`NSC__MONGOOSE__URI` branch has no such backstop, and a project slug may
 legitimately carry a marker as a *whole word*: `ci` is the ordinary German abbreviation for
 *Corporate Identity*, `test` a product noun for an exam. `ci-portal-local` passes the segment rule.
 
@@ -100,7 +105,7 @@ Then use `isDroppableTestDb(db.databaseName)` in place of `SAFE_TEST_DB_PATTERN.
 database into a leaked one.
 
 **Refuse a URI that names no database.** `mongodb://127.0.0.1` makes the driver fall back to its
-default database, `test` — a name the guard accepts, so a truncated `MONGODB_URI` dropped the
+default database, `test` — a name the guard accepts, so a truncated `NSC__MONGOOSE__URI` dropped the
 server's `test` database instead of failing. Note that this needs the `splitMongoUri()` fix too: the
 previous greedy form reported the **host** as the database name for such a URI, so the check could
 never fire.
@@ -125,7 +130,7 @@ refusal list *is* the specification, and reverting the anchoring turns 13 cases
 |---------|--------|
 | npm-mode projects | Unaffected by the package update; apply §1 to your own `tests/` |
 | Vendor-mode projects | Same — `tests/` is outside the vendor file set |
-| CI pipelines that pin `MONGODB_URI` | Unaffected, unless the pinned URI names no database or carries an environment suffix. A CI database called `myproject-ci` is fine; one called `myproject-ci-staging` is now refused |
+| CI pipelines that pin `NSC__MONGOOSE__URI` | Unaffected, unless the pinned URI names no database or carries an environment suffix. A CI database called `myproject-ci` is fine; one called `myproject-ci-staging` is now refused |
 | Projects not generated from `nest-server-starter` | Nothing to do |
 
 ---
@@ -133,11 +138,11 @@ refusal list *is* the specification, and reverting the anchoring turns 13 cases
 ## Troubleshooting
 
 **`Refusing to dropDatabase("…"): not a recognized disposable test database`**
-Your `MONGODB_URI` points at something the guard will not delete. That is the guard working. Check
+Your `NSC__MONGOOSE__URI` points at something the guard will not delete. That is the guard working. Check
 whether the URI is aimed at your development database — an `lt dev` shell exports it that way — and
 point it at a disposable test database instead. Do not loosen the pattern to get past this.
 
-**`Refusing to use MONGODB_URI="…": it names no database`**
+**`Refusing to use NSC__MONGOOSE__URI="…": it names no database`**
 The URI has no path (`mongodb://host` rather than `mongodb://host/mydb`). Add the database name.
 
 **`N stale database(s) skipped by the safety guard`**

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

@@ -0,0 +1,176 @@
+# Migration Guide: 11.42.10 → 11.42.11
+
+## Overview
+
+| Category             | Details                                                                                                  |
+| -------------------- | -------------------------------------------------------------------------------------------------------- |
+| **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); 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                                                                                                     |
+| **Migration Effort** | None for the package. Starter-derived projects older than starter 11.42.10 should port §1 and §2         |
+
+## 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 for the
+framework itself.
+
+**Why the rest of this guide exists:** `tests/`, `scripts/` and `vitest-e2e.config.ts` do not ship in the npm
+tarball and are not part of the vendor file set. They are template files: `nest-server-starter` ships them,
+and every project generated from it holds a private copy that no update channel touches. The sections below
+say which starter version already carries each fix, so you can tell whether your copy needs it.
+
+## 1. e2e low-resource mode: `maxWorkers` instead of `poolOptions` (Vitest 4)
+
+Already in projects generated from **starter 11.42.10 or later**.
+
+Vitest 4 removed `test.poolOptions`. The low-resource mode in `vitest-e2e.config.ts` still set
+`poolOptions.forks.maxForks`, so the worker cap was announced on stderr and then discarded — measured: a run
+logging `maxForks=2` used 8 workers on a 12-core machine, the same run with `maxWorkers` used 2. Low-resource
+mode only raised the timeouts, and overlapping e2e runs (several sessions, `lt dev test` next to `check`) kept
+starving each other into spurious 401s and timeouts.
+
+```typescript
+// Before
+...(LOW_RESOURCE ? { poolOptions: { forks: { maxForks: LOW_RESOURCE_FORKS, minForks: 1 } } } : {}),
+
+// After
+maxWorkers: LOW_RESOURCE ? LOW_RESOURCE_FORKS : undefined,
+```
+
+`undefined` leaves Vitest's default in place for a normal run. `minWorkers` does not exist in Vitest 4 — drop
+`minForks` rather than translating it. Also rename the option in the stderr announcement, so the one line that
+reports the cap names an option that exists.
+
+A type check does not catch this: under `module: commonjs`, Vitest's config type collapses to `any`, so a
+removed option compiles cleanly. The starter pins it with `tests/unit/vitest-e2e-config.spec.ts`.
+
+**Not for your project: the framework's GitHub-runner exception.** nest-server additionally skips the cap when
+the load signal is the only trigger and `RUNNER_ENVIRONMENT === 'github-hosted'`: a GitHub-hosted runner runs
+one job per VM, so the load it sees is the job's own unit step, and the cap measurably slowed every build
+(133 s → 198 s mean e2e time). A shared GitLab runner sets `CI` but not `RUNNER_ENVIRONMENT`, and there the
+load is real contention — keep the cap.
+
+## 2. e2e run governor (`tests/e2e-run-slots.ts`) hardened
+
+Already in projects generated from **starter 11.42.10 or later**.
+
+The slot directory under `os.tmpdir()` is shared by every lt project on the machine. Three fixes, each pinned
+by a test in `tests/unit/e2e-run-slots.spec.ts`:
+
+| Defect | Fix |
+| ------ | --- |
+| A slot whose PID was recycled by an unrelated long-lived process counted as an active run forever | Reclaim a slot older than six hours even when its PID answers |
+| On a multi-user Linux host (`/tmp` world-writable) a planted `<pid>.slot` symlink made the write follow it | Create the directory `0o700`, unlink the own path first, write with `flag: 'wx', mode: 0o600` |
+| An unwritable slot directory threw out of `acquireRunSlot()` and aborted the suite, despite the documented fail-open | Catch the claim; the run proceeds ungoverned |
+
+The easiest port is to copy `tests/e2e-run-slots.ts` and its spec from the current starter; the file has no
+project-specific content.
+
+## 3. `scripts/check.mjs`: two false greens
+
+Already in projects generated from **starter 11.40.0 or later**. nest-server's own copy caught up in this
+release.
+
+- **The "Vulnerabilities" summary line tested `audit.counts` before `audit.degraded`.** A silent audit outage
+  (exit 0, all-zero JSON, advisory service unreachable) keeps `counts` set, so the summary printed
+  `critical 0 · high 0 · …` for a run that never reached the service. Test `degraded` first.
+- **The CLI guard compared `resolve(process.argv[1])` with the module's own path.** Node resolves the main
+  module's symlinks for `import.meta.url` but keeps `argv[1]` as typed, so a start through a symlink — on macOS
+  any absolute path under `/tmp` — skipped the pipeline and exited 0. Compare both sides through
+  `realpathSync`, and exit 1 when the entry cannot be resolved.
+
+## 4. Tests that upload to a refused route: send no file
+
+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
+multipart body, and the write fails with `EPIPE` (observed 1 run in 14 in this repository with retries off).
+The file cannot change the guard's answer, so send none — an open route then answers 400 for the missing file,
+so the test still fails if the guard is gone:
+
+```typescript
+// Before
+await testHelper.rest('/files/upload', { attachments: { file: local }, statusCode: 401 });
+
+// After
+await testHelper.rest('/files/upload', { method: 'POST', statusCode: 401 });
+```
+
+Search your `tests/` for `attachments:` next to `statusCode: 401` or `403`.
+
+## 5. Documentation corrections: `NSC__MONGOOSE__URI`, not `MONGODB_URI`
+
+`lt dev` exports `NSC__MONGOOSE__URI` (and `DATABASE_URL`); it has never set `MONGODB_URI`. The guides
+[11.36.3 → 11.36.4](./11.36.3-to-11.36.4.md) and [11.27.2 → 11.27.3](./11.27.2-to-11.27.3.md) named
+`MONGODB_URI` where a starter-derived project's `tests/global-setup.ts` reads `NSC__MONGOOSE__URI`. Both are
+corrected. The steps in them were right for your project — only the variable name was wrong, so nothing needs
+redoing unless you adapted a script to the wrong name.
+
+## 6. Dependency updates
+
+- **`nodemailer` 10.0.16 → 10.1.0** — minor release: hardened message streams, SMTP connection and pool
+  handling, SMTP and encoding fixes. No API change; the framework's real-SMTP round-trip test passes. A project
+  that carries a lock-step `nodemailer` override (nest-server-starter does) should raise it:
+
+  ```yaml
+  # Before
+  overrides:
+    'nodemailer@<10.0.16': '10.0.16'
+
+  # After
+  overrides:
+    'nodemailer@<10.1.0': '10.1.0'
+  ```
+
+- **Development tooling only:** `@aws-sdk/*` 3.1149.0, `bullmq` 6.3.12, `smtp-server` 3.19.19, `vite` 8.3.4,
+  `@types/node` 26.6.5, `@types/lodash` 4.17.26. If your project pins `@types/node` exactly, raise it to 26.6.5
+  so a fresh install does not keep two copies.
+
+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 |
+| ------- | ------ |
+| npm-mode and vendor-mode projects | Unaffected by the package update; §1–§4 apply to your own `tests/` and `scripts/` |
+| Projects generated from starter ≥ 11.42.10 | §1–§4 already present |
+| Projects not generated from `nest-server-starter` | Nothing to do |
+| CI on a shared GitLab runner | Keep the low-resource cap; do not add a GitHub-runner exception |
+
+## Troubleshooting
+
+**`[e2e] low-resource mode: … -> maxForks=…` in your log**
+Your copy still sets `poolOptions` — the cap is not applied. Port §1.
+
+**`[e2e-governor] could not claim a slot (…) — proceeding without the governor.`**
+The slot directory is not writable (owned by another user, read-only tmpdir). The run continues, ungoverned.
+Point `LT_E2E_SLOT_DIR` at a writable directory to get the governor back.
+
+## Module Documentation
+
+- [`.claude/rules/testing.md`](../.claude/rules/testing.md) — run governor, low-resource mode, drop guard

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.10",
+  "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",
@@ -34,7 +34,7 @@
     "check:server-start": "cross-env NODE_ENV=local node scripts/check-server-start.mjs --entry=dist/main.js --port-env=NSC__PORT --ready=\"Server starte[dt] at\" --path=/",
     "check:swc-tdz": "nest build -b swc -p tsconfig.swc-tdz.json && node scripts/check-swc-tdz.mjs",
     "cnaf": "pnpm run check:naf",
-    "docs": "pnpm run docs:ci && open http://127.0.0.1:8080/ && open ./public/index.html && compodoc -p tsconfig.json -s ",
+    "docs": "pnpm run docs:ci && node scripts/open.mjs http://127.0.0.1:8080/ ./public/index.html && compodoc -p tsconfig.json -s",
     "docs:bootstrap": "node extras/update-spectaql-version.mjs && node scripts/run-spectaql.mjs",
     "docs:ci": "ts-node ./scripts/init-server.ts && pnpm run docs:bootstrap && compodoc -p tsconfig.json",
     "format": "oxfmt --write src/ scripts/",
@@ -59,7 +59,7 @@
     "start:prod": "cross-env NODE_ENV=production node dist/main.js",
     "test": "pnpm run vitest:unit && pnpm run vitest",
     "test:ci": "pnpm run vitest:unit && pnpm run vitest:ci",
-    "test:cleanup": "find tests -type f \\( -name '*.txt' -o -name '*.bin' -o -name '*.png' \\) -not -name '.gitkeep' -delete && echo 'Test artifacts cleaned up'",
+    "test:cleanup": "node scripts/clean-test-artifacts.mjs",
     "test:cov": "pnpm run vitest:unit:cov && pnpm run vitest:cov",
     "test:e2e": "pnpm run vitest",
     "test:infra": "node scripts/test-infra.mjs up",
@@ -129,7 +129,7 @@
     "mongoose": "9.10.4",
     "multer": "2.4.0",
     "node-mailjet": "6.0.11",
-    "nodemailer": "10.0.16",
+    "nodemailer": "10.1.0",
     "passport": "0.7.0",
     "passport-jwt": "4.0.1",
     "reflect-metadata": "0.2.2",
@@ -182,9 +182,9 @@
     }
   },
   "devDependencies": {
-    "@aws-sdk/client-s3": "3.1147.0",
-    "@aws-sdk/lib-storage": "3.1147.0",
-    "@aws-sdk/s3-request-presigner": "3.1147.0",
+    "@aws-sdk/client-s3": "3.1149.0",
+    "@aws-sdk/lib-storage": "3.1149.0",
+    "@aws-sdk/s3-request-presigner": "3.1149.0",
     "@better-auth/core": "1.7.7",
     "@better-auth/passkey": "1.7.7",
     "@compodoc/compodoc": "2.0.0",
@@ -198,13 +198,13 @@
     "@types/cookie-parser": "1.4.10",
     "@types/ejs": "3.1.5",
     "@types/express": "5.0.6",
-    "@types/lodash": "4.17.25",
+    "@types/lodash": "4.17.26",
     "@types/multer": "2.3.0",
-    "@types/node": "26.6.4",
+    "@types/node": "26.6.5",
     "@types/passport": "1.0.17",
     "@vitest/coverage-v8": "4.1.11",
     "better-auth": "1.7.7",
-    "bullmq": "6.3.11",
+    "bullmq": "6.3.12",
     "cross-env": "10.1.0",
     "ioredis": "6.0.0",
     "nodemon": "3.1.14",
@@ -213,14 +213,14 @@
     "oxfmt": "0.71.0",
     "oxlint": "1.87.0",
     "rimraf": "6.1.3",
-    "smtp-server": "3.19.17",
+    "smtp-server": "3.19.19",
     "ts-node": "10.9.2",
     "tsconfig-paths": "4.2.0",
     "tsx": "4.23.15",
     "tus-js-client": "4.3.1",
     "typescript": "5.9.3",
     "unplugin-swc": "2.0.0",
-    "vite": "8.3.3",
+    "vite": "8.3.4",
     "vite-plugin-node": "8.0.0",
     "vitest": "4.1.11"
   },

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,
       );