@lenne.tech/nest-server 11.27.3 → 11.27.5

package/docs/REQUEST-LIFECYCLE.md

@@ -460,8 +460,15 @@ if (!isCorsDisabled(envConfig.cors)) {
 | `cors: { allowAll: true }` | `origin: true` | `origin: true` | `trustedOrigins: undefined` |
 | `cors: { allowedOrigins: [...] }` | `origin: [merged list]` | `origin: [merged list]` | `trustedOrigins: [merged list]` |
 | `cors: { enabled: false }` | No CORS headers | No CORS headers | `trustedOrigins: []` |
+| `cors: { deriveAppUrl: false }` | `appUrl` not derived from `baseUrl` | same | same |
 
-> **Note:** GraphQL CORS is configured in `CoreModule.buildCorsConfig()` using raw config values. BetterAuth derives `trustedOrigins` using resolved URLs (auto-derived from `baseUrl`). In edge cases (no explicit `appUrl`), these may differ slightly. Set `appUrl` explicitly for consistent behavior across all layers.
+**URL resolution (since v11.27.5):** all three layers resolve `appUrl`/`baseUrl` through the single `resolveServerUrls()` helper in `cookies.helper.ts`, so they can no longer drift:
+
+1. `appUrl` set explicitly → used as-is
+2. `env: 'local' | 'ci' | 'e2e'` with a localhost `baseUrl` → `appUrl` defaults to `http://localhost:3001`
+3. otherwise derived from `baseUrl` by stripping a leading `api.` label (`https://api.example.com` → `https://example.com`), unless `cors.deriveAppUrl: false`
+
+> **Security:** step 3 grants the derived origin credentialed CORS. If the apex domain is not trusted (e.g. a third-party-hosted marketing site whose XSS surface you do not control), set `cors.deriveAppUrl: false` and list the frontend origin explicitly via `appUrl` or `cors.allowedOrigins`. The derivation never yields a bare TLD (`https://api.dev` stays unchanged) and never emits the opaque `null` origin.
 
 ### NestJS Middleware Chain (CoreModule)
 

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

@@ -0,0 +1,236 @@
+# Migration Guide: 11.27.3 → 11.27.4
+
+## Overview
+
+| Category | Details |
+|----------|---------|
+| **Breaking Changes** | None |
+| **New Features** | Opt-in `CHECK_LOW_RESOURCE` e2e mode (keeps parallel test runs stable under load); `check.mjs` now labels signal-killed steps (`SIGTERM`/`SIGKILL`) instead of showing a bare exit code. |
+| **Bugfixes** | Idle watchdog no longer false-kills output-buffering steps (build / typecheck / audit); a stray `SIGKILL` after PID reuse is prevented; an invalid `--idle-timeout` value now falls back to the default instead of silently disabling the watchdog. |
+| **Migration Effort** | 0 minutes for npm consumers (`pnpm update` is enough). Optional: projects that copied `scripts/check.mjs` / `vitest-e2e.config.ts` from the starter can adopt the updated files. |
+
+This is a **repo-internal tooling & test-infrastructure release**. It touches
+**no framework source** (`src/` is unchanged) — only `scripts/check.mjs` and
+`vitest-e2e.config.ts`. The npm package (`dist/`) is functionally identical to
+11.27.3; consuming projects need no code or config changes.
+
+---
+
+## Quick Migration
+
+No code changes required.
+
+```bash
+# Update package
+pnpm add @lenne.tech/nest-server@11.27.4
+
+# Verify build
+pnpm run build
+
+# Run tests
+pnpm test
+```
+
+> These files ship in the git repository / starter, **not** in the npm package.
+> An npm-mode consumer is unaffected. A project that copied `scripts/check.mjs`
+> and/or `vitest-e2e.config.ts` from the starter (11.27.1+) can copy the updated
+> versions to get the improvements below — see **Compatibility Notes**.
+
+---
+
+## What's New in 11.27.4
+
+### 1. Opt-in low-resource e2e mode (`CHECK_LOW_RESOURCE`)
+
+Running several full e2e suites at the same time on one machine (e.g. multiple
+parallel `lt dev` / `lt ticket` environments, or a second terminal) can saturate
+CPU and the shared MongoDB. Under that load individual requests exceed the 30s
+`testTimeout` and auth queries fail — surfacing as intermittent `401`s or
+per-file timeouts. Data isolation was never the cause (every run already gets a
+unique database); the cause is **physical resource contention**.
+
+`vitest-e2e.config.ts` now supports an **opt-in** throttle. It changes nothing
+by default — solo and moderately parallel runs stay at full speed:
+
+```bash
+# Full speed (default) — nothing changes
+pnpm test
+
+# Opt in when you deliberately run MANY suites in parallel
+CHECK_LOW_RESOURCE=1 pnpm test
+
+# Pin the fork cap explicitly (otherwise ~1/3 of CPU cores)
+CHECK_LOW_RESOURCE=1 CHECK_LOW_RESOURCE_FORKS=2 pnpm test
+```
+
+| `CHECK_LOW_RESOURCE` | Effect |
+|----------------------|--------|
+| unset / `0` / `false` (default) | No cap, no timeout change — full speed |
+| `1` / `true` | `poolOptions.forks.maxForks` capped (`~cores/3`, min 2), `testTimeout` 30s → 60s, `hookTimeout` 120s → 240s |
+| any value + `CHECK_LOW_RESOURCE_FORKS=<n>` | Fork cap pinned to `<n>` |
+
+When active it prints a one-line notice at startup:
+`[e2e] low-resource mode active: maxForks=…, timeouts raised`.
+
+### 2. Signal-exit labelling in `scripts/check.mjs`
+
+When a step's process is killed by a signal, the package manager surfaces it as
+a numeric `Command failed with exit code 143` (SIGTERM) / `137` (SIGKILL) line,
+while the outer shell reports only a generic exit `1`. The `check` report now
+detects that and appends a clear reason so it isn't mistaken for a test-assertion
+failure:
+
+```
+[check] step ended via SIGTERM (exit 143) — the process was killed, not an
+assertion failure. Usual cause: resource pressure (parallel checks/builds
+swapping) or an external kill. Re-run this project's check alone to confirm.
+```
+
+The hint is suppressed when the step was killed by the check's own idle
+watchdog (that path already carries its own `[watchdog]` note), and it only
+matches the package manager's own failure line — never an `exit code 143` a test
+happens to log — so real assertion failures are never mislabeled.
+
+---
+
+## What's Fixed in 11.27.4
+
+All fixes are in `scripts/check.mjs`, refining the idle watchdog introduced in
+11.27.x.
+
+### Watchdog now applies to test steps only
+
+The idle watchdog kills a step whose child produces no output for the timeout
+window (default 300s). It previously watched **every** step. But `build`,
+`typecheck` and `audit` legitimately buffer all their output to the end (and go
+silent under a non-TTY pipe) — watching them risked false-killing a slow but
+progressing run. The watchdog is now armed **only for test steps**, whose
+runners stream progress continuously, so prolonged silence genuinely means
+deadlocked workers. The run header reflects this: `watchdog: 5m 0s (tests)`.
+
+### No stray `SIGKILL` after PID reuse
+
+When the watchdog fires it sends `SIGTERM`, then escalates to `SIGKILL` after a
+5s grace window. That escalation timer is now tracked and cancelled once the
+child exits within the grace window — previously the stray timer could fire
+later and `SIGKILL` an **unrelated** process that had reused the freed PID.
+
+### Invalid `--idle-timeout` falls back to the default
+
+An unparseable, negative, or unit-suffixed value (e.g. `--idle-timeout=30s`)
+now keeps the watchdog at its default (300s) and prints a notice, instead of
+silently evaluating to `0` and disabling the protection. Only an explicit `0`
+disables the watchdog.
+
+```bash
+--idle-timeout=120     # 120s
+--idle-timeout=0       # explicitly disabled
+--idle-timeout=30s     # invalid → default 300s + "[check] ignoring invalid idle-timeout" notice
+CHECK_IDLE_TIMEOUT=90  # env equivalent
+```
+
+### Clearer watchdog reason
+
+The `[watchdog]` note now suggests re-running the **actual** failing command
+(`Re-run the step directly to debug: <cmd>`) instead of a hard-coded
+`pnpm run vitest`.
+
+---
+
+## Breaking Changes
+
+None.
+
+---
+
+## Compatibility Notes
+
+- **npm-mode consumers:** unaffected. `scripts/check.mjs` and
+  `vitest-e2e.config.ts` are not part of the npm package (`dist/`); no runtime
+  or API behavior changed. `pnpm update` is sufficient.
+- **`IServerOptions` / `CoreModule.forRoot()` / all Core classes:** unchanged.
+  No source, export, or method signature changed in this release.
+- **Starter-derived projects** (copied `scripts/check.mjs` / `vitest-e2e.config.ts`
+  from nest-server-starter 11.27.1+): copy the updated files to adopt the
+  test-only watchdog, the PID-reuse fix, the signal-exit hint, and the opt-in
+  `CHECK_LOW_RESOURCE` mode. All changes are backward compatible — the default
+  behavior (no env vars set) is unchanged, so an updated `check.mjs` /
+  `vitest-e2e.config.ts` is a drop-in replacement.
+- **Vendor-mode consumers:** not applicable — `scripts/` and
+  `vitest-e2e.config.ts` are repo/starter tooling, not part of the vendored
+  `src/core/` file set. Nothing to sync.
+- **`lt dev` / `lt ticket` parallel workflows:** the throttle is **manual**
+  (`CHECK_LOW_RESOURCE=1`). To have it apply automatically inside isolated
+  environments, the lt CLI can export it into the test env (the same way it
+  exports `LT_DEV_TEST_SHARDS` for the Playwright config). That is a CLI change,
+  not a framework change.
+- **Nuxt / Playwright side:** no equivalent needed. The Playwright config
+  already uses `workers: 1` plus a `LT_DEV_TEST_SHARDS`-driven relaxed mode for
+  load, so the same class of contention is already handled there.
+
+---
+
+## Troubleshooting
+
+### My `build` / `typecheck` / `audit` step is no longer killed after 300s
+
+Intended. Only **test** steps are watched now (they stream progress). Buffering
+steps that legitimately go silent are no longer at risk of a false watchdog
+kill. If such a step genuinely hangs, it still fails via its own tool timeout or
+the overall run.
+
+### The check aborted with "step ended via SIGTERM (exit 143)"
+
+That step's process was killed by a signal, not by a failed assertion. The usual
+cause is resource pressure (several heavy checks/builds/test suites running at
+once and swapping the machine) or an external kill. Re-run that project's check
+alone to confirm — it will typically pass.
+
+### e2e tests flake (401 / timeouts) only when I run many suites in parallel
+
+This is physical CPU/MongoDB contention, not a data-isolation bug (each run has
+its own database). Opt into the throttle for those sessions:
+`CHECK_LOW_RESOURCE=1 pnpm test`. It caps parallel forks and raises timeouts so
+the suites share the machine without starving each other.
+
+### `CHECK_LOW_RESOURCE` seems to have no effect
+
+Confirm the value is truthy (`1` / `true`) and not `0` / `false` / empty. When
+active, the run prints `[e2e] low-resource mode active: maxForks=…` at startup.
+
+---
+
+## Repo-Internal Tooling Changes (no consumer action)
+
+Summary of everything in this release, for projects that track the tooling
+(all listed above in detail):
+
+- `scripts/check.mjs`: idle watchdog restricted to test steps; stray-`SIGKILL`
+  (PID-reuse) fix; invalid `--idle-timeout` falls back to default instead of
+  disabling; watchdog reason shows the actual command; new `signalExitHint`
+  labelling `SIGTERM`/`SIGKILL` step exits.
+- `vitest-e2e.config.ts`: opt-in `CHECK_LOW_RESOURCE` mode (fork cap + raised
+  timeouts) for stable parallel e2e runs; default behavior unchanged.
+
+These carry forward the tooling introduced in
+[11.27.1 → 11.27.2](./11.27.1-to-11.27.2.md) (chain-faithful audit) and
+[11.27.2 → 11.27.3](./11.27.2-to-11.27.3.md) (idle watchdog + per-run test
+databases).
+
+---
+
+## Module Documentation
+
+No core module changed in this release. Relevant testing documentation:
+
+- **Testing rules:** [.claude/rules/testing.md](../.claude/rules/testing.md) —
+  test framework, per-run database lifecycle, parallel execution
+- **Reference implementation:** [nest-server-starter](https://github.com/lenneTech/nest-server-starter)
+  — carries the same `scripts/check.mjs` + `vitest-e2e.config.ts`
+
+---
+
+## References
+
+- [Migration Guide 11.27.2 → 11.27.3](./11.27.2-to-11.27.3.md) — Previous release (verification-email crash fix + idle watchdog + per-run test DBs)
+- [nest-server-starter](https://github.com/lenneTech/nest-server-starter) — reference implementation

package/migration-guides/11.27.4-to-11.27.5.md

@@ -0,0 +1,241 @@
+# Migration Guide: 11.27.4 → 11.27.5
+
+## Overview
+
+| Category | Details |
+|----------|---------|
+| **Breaking Changes** | None (API-compatible). One **behavior change**: a config that sets only `baseUrl` now also trusts the derived app origin in the REST/GraphQL CORS allowlist — see [Behavior Change](#behavior-change-cors-allowlist-derives-appurl). |
+| **New Features** | `cors.deriveAppUrl` opt-out; exported `resolveServerUrls()` and `deriveAppUrlFromBaseUrl()` helpers. |
+| **Bugfixes** | REST/GraphQL CORS blocked the frontend origin on `api.<host>` deployments and in `local`/`ci`/`e2e`; the `api.`-strip could produce a bare TLD or the opaque `null` origin; trailing-slash `baseUrl` produced a never-matching origin entry. |
+| **Security Updates** | `better-auth` + `@better-auth/passkey` `1.6.11` → `1.6.23` (GHSA-86j7-9j95-vpqj, High); `@xhmikosr/decompress` pinned to `11.1.3` via override (GHSA-mp2f-45pm-3cg9, Critical). |
+| **Migration Effort** | 0 minutes for most projects (`pnpm update`). ~2 minutes if your apex domain is untrusted — see below. |
+
+The three CORS layers (GraphQL/Apollo, REST/Express, BetterAuth `trustedOrigins`)
+previously each resolved `appUrl`/`baseUrl` on their own and had drifted. They now
+share a single `resolveServerUrls()` helper, so they cannot disagree.
+
+---
+
+## Quick Migration
+
+No code changes required for the common case.
+
+```bash
+# Update package
+pnpm add @lenne.tech/nest-server@11.27.5
+
+# Verify build
+pnpm run build
+
+# Run tests
+pnpm test
+```
+
+---
+
+## What's Fixed in 11.27.5
+
+### 1. `api.<host>` deployments: the frontend origin was blocked
+
+A deployment that sets only `baseUrl` (the typical `NSC__BASE_URL` /
+`BASE_URL` setup) got a CORS allowlist containing just the API's own origin.
+BetterAuth already derived `https://example.com` from
+`https://api.example.com` for its `trustedOrigins`, but the REST and GraphQL
+layers did not — so IAM endpoints worked cross-origin while every other
+endpoint failed preflight.
+
+Both layers now derive `appUrl` identically:
+
+```typescript
+// config.env.ts — no appUrl needed
+baseUrl: 'https://api.example.com',
+// → CORS allowlist: ['https://example.com', 'https://api.example.com']
+```
+
+### 2. `local` / `ci` / `e2e`: localhost defaults were not applied to CORS
+
+`resolveUrls()` in BetterAuth mapped these environments to
+`appUrl = http://localhost:3001` (API on `:3000`, app on `:3001`).
+`buildCorsConfig()` had no such branch, so the frontend was blocked. The
+shared resolver now applies the same defaults on every layer.
+
+> The framework's own `development` environment is **not** one of the
+> localhost-default environments. `src/config.env.ts` now sets
+> `appUrl: process.env.APP_URL || 'http://localhost:3001'` there explicitly.
+> Projects that copied the `development` block from the starter and run their
+> frontend on `:3001` should do the same.
+
+### 3. Hardened `api.`-label stripping
+
+| `baseUrl` | Before | After |
+|-----------|--------|-------|
+| `https://api.example.com` | `https://example.com` | unchanged |
+| `https://api.dev.example.com` | `https://dev.example.com` | unchanged |
+| `https://api.dev` | `https://dev` (bare TLD!) | `https://api.dev` (no strip) |
+| `https://api.` | `https://api.` (silent no-op) | `https://api.` (explicit no-op) |
+| `custom://api.example.com` | `"null"` (opaque origin!) | `custom://api.example.com` |
+| `https://api.example.com/` | `https://example.com` + dead `…/` entry | both entries origin-normalized |
+
+The `"null"` case was the most serious: `URL.origin` serializes opaque origins
+to the literal string `"null"`, which is exactly the `Origin` header a
+sandboxed iframe sends. In a `credentials: true` allowlist that would have
+granted credentialed access to any site able to frame a sandboxed document.
+Only `http:`/`https:` URLs are normalized to origins now.
+
+### 4. Security updates in dependencies
+
+| Package | Change | Advisory |
+|---------|--------|----------|
+| `better-auth` | `1.6.11` → `1.6.23` (direct) | [GHSA-86j7-9j95-vpqj](https://github.com/advisories/GHSA-86j7-9j95-vpqj) — High: stored XSS in the auth-server origin via a `javascript:` `redirect_uri` in `oidc-provider` and `mcp` |
+| `@better-auth/passkey` | `1.6.11` → `1.6.23` (direct) | Kept in lockstep — peers on `better-auth@^1.6.23` |
+| `@xhmikosr/decompress` | pinned to `11.1.3` via `pnpm.overrides` | [GHSA-mp2f-45pm-3cg9](https://github.com/advisories/GHSA-mp2f-45pm-3cg9) — Critical: archive extraction can create files/links outside the target directory |
+
+`@xhmikosr/decompress` is transitive via `@swc/cli > @xhmikosr/bin-wrapper > @xhmikosr/downloader`.
+`@swc/cli@0.8.1` is the latest release and still resolves the vulnerable range, so an override
+with a fixed target is the only available fix.
+
+Both `better-auth` bumps stay inside `1.6.x` — no BetterAuth API change. The full suite
+(2019 tests) passes unchanged.
+
+npm-mode consumers get all three fixes with a plain `pnpm update`. Vendor-mode consumers must
+bump `better-auth`/`@better-auth/passkey` in their own `package.json` and copy the
+`@xhmikosr/decompress` override — the vendored file set does not carry `package.json`.
+
+---
+
+## Behavior Change: CORS allowlist derives `appUrl`
+
+**Who is affected:** projects that configure `baseUrl` but neither `appUrl`
+nor `cors.allowedOrigins`, and whose apex domain is not under their control.
+
+Deriving `appUrl` means the apex origin (`https://example.com`) receives
+**credentialed** cross-origin access (`Access-Control-Allow-Credentials: true`).
+That is the intended, documented `appUrl` auto-detection and matches what
+BetterAuth's `trustedOrigins` has always done — but it now also applies to the
+REST and GraphQL layers.
+
+If your apex is a third-party-hosted marketing site (WordPress, Webflow,
+HubSpot) whose XSS surface you do not control, opt out:
+
+```typescript
+// config.env.ts
+{
+  baseUrl: 'https://api.example.com',
+  cors: {
+    // Do not trust https://example.com implicitly
+    deriveAppUrl: false,
+    // List the real frontend origin instead
+    allowedOrigins: ['https://app.example.com'],
+  },
+}
+```
+
+`deriveAppUrl: false` suppresses the derivation on **all three** layers
+(GraphQL, REST, BetterAuth `trustedOrigins`). It has no effect when `appUrl`
+is set explicitly, and it does not disable the `local`/`ci`/`e2e` localhost
+defaults.
+
+---
+
+## What's New in 11.27.5
+
+### `cors.deriveAppUrl`
+
+| Value | Effect |
+|-------|--------|
+| `true` (default) | `appUrl` is derived from `baseUrl` by stripping a leading `api.` label |
+| `false` | No derivation; configure `appUrl` / `cors.allowedOrigins` explicitly |
+
+### Exported URL helpers
+
+Both are exported from the package root (`cookies.helper.ts`):
+
+```typescript
+import { deriveAppUrlFromBaseUrl, resolveServerUrls } from '@lenne.tech/nest-server';
+
+deriveAppUrlFromBaseUrl('https://api.example.com'); // 'https://example.com'
+
+resolveServerUrls({ baseUrl: 'https://api.example.com' });
+// { appUrl: 'https://example.com', appUrlSource: 'derived',
+//   baseUrl: 'https://api.example.com', baseUrlSource: 'explicit' }
+```
+
+`appUrlSource` / `baseUrlSource` (`'explicit' | 'localhost-default' | 'derived' | 'none'`)
+let callers emit accurate startup diagnostics without re-deriving the resolution logic.
+
+---
+
+## Breaking Changes
+
+None. `ICorsConfig` gained an optional field; no signature, export, or Core
+class changed.
+
+---
+
+## Compatibility Notes
+
+- **npm-mode consumers:** `pnpm update` is sufficient. Review the
+  [behavior change](#behavior-change-cors-allowlist-derives-appurl) if your
+  apex domain is untrusted.
+- **Vendor-mode consumers:** the change touches `src/core/common/helpers/cookies.helper.ts`,
+  `src/core/common/interfaces/server-options.interface.ts` and
+  `src/core/modules/better-auth/better-auth.config.ts` — all inside the vendored
+  `src/core/` file set. Sync via `/lt-dev:backend:update-nest-server-core`.
+  `better-auth.config.ts` now imports `resolveServerUrls` from
+  `../../common/helpers/cookies.helper` (still inside `src/core/`, so the
+  self-containment rule holds).
+- **Projects that set `appUrl` explicitly:** unaffected. Explicit values are
+  never overridden by the derivation.
+- **Projects that set `cors.allowAll: true`:** unaffected. `allowAll` short-circuits
+  before URL resolution.
+- **Passkey / WebAuthn in `development`:** if you adopt the new
+  `appUrl: 'http://localhost:3001'` in the `development` block, the Passkey
+  `origin` becomes `http://localhost:3001` (where the browser actually runs)
+  instead of the API's `:3000`. This is a fix — WebAuthn ceremonies from the
+  frontend previously used the wrong origin.
+- **A duplicate private `deriveAppUrlFromBaseUrl()` was removed** from
+  `better-auth.config.ts`. It was never exported; nothing to migrate.
+
+---
+
+## Troubleshooting
+
+### My frontend is still blocked by CORS
+
+Check, in order:
+
+1. `cors.enabled` is not `false`.
+2. `cookies` is not disabled — `buildCorsConfig()` returns `{}` when cookies
+   are off (REST then falls back to permissive `enableCors()` without credentials).
+3. Your frontend origin is actually derivable. `baseUrl: 'https://my-api.example.com'`
+   has no `api.` label to strip, so `appUrl` resolves to the API's own origin.
+   Set `appUrl` explicitly.
+4. `env` is one of `local`/`ci`/`e2e` if you rely on the `localhost:3001` default.
+   `development` is not — set `appUrl` there.
+
+### My apex domain unexpectedly appears in the allowlist
+
+That is the `appUrl` derivation. Set `cors.deriveAppUrl: false` and list the
+frontend origin explicitly. See
+[Behavior Change](#behavior-change-cors-allowlist-derives-appurl).
+
+### `https://api.dev` no longer derives an app origin
+
+Intended. Stripping would leave the bare TLD `dev`, which is not a deployable
+host. Set `appUrl` explicitly for such domains.
+
+---
+
+## Module Documentation
+
+- **Request lifecycle & CORS:** [docs/REQUEST-LIFECYCLE.md](../docs/REQUEST-LIFECYCLE.md) — section `0b. CORS`
+- **Configurable features:** [.claude/rules/configurable-features.md](../.claude/rules/configurable-features.md) — `CORS` row
+- **BetterAuth:** [src/core/modules/better-auth/README.md](../src/core/modules/better-auth/README.md)
+
+---
+
+## References
+
+- [Migration Guide 11.27.3 → 11.27.4](./11.27.3-to-11.27.4.md) — Previous release (test tooling)
+- [Migration Guide 11.24.x → 11.25.0](./11.24.x-to-11.25.0.md) — Introduced the unified `cors` config
+- [nest-server-starter](https://github.com/lenneTech/nest-server-starter) — reference implementation

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenne.tech/nest-server",
-  "version": "11.27.3",
+  "version": "11.27.5",
   "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",
@@ -77,7 +77,7 @@
   "dependencies": {
     "@apollo/server": "5.5.1",
     "@as-integrations/express5": "1.1.2",
-    "@better-auth/passkey": "1.6.11",
+    "@better-auth/passkey": "1.6.23",
     "@getbrevo/brevo": "3.0.1",
     "@modelcontextprotocol/sdk": "1.29.0",
     "@nestjs/apollo": "13.4.2",
@@ -96,7 +96,7 @@
     "@tus/server": "2.4.1",
     "@types/supertest": "7.2.0",
     "bcrypt": "6.0.0",
-    "better-auth": "1.6.11",
+    "better-auth": "1.6.23",
     "class-transformer": "0.5.1",
     "class-validator": "0.15.1",
     "compression": "1.8.1",
@@ -216,7 +216,8 @@
       "hono@<4.12.25": "Security: multiple CVEs <4.12.25 (prototype pollution, bodyLimit/Vary bypass, JWT NumericDate) - transitive via @nestjs/terminus>prisma>@prisma/dev",
       "nodemailer@<9.0.1": "Security: email/header injection CVEs <9.0.1 - direct dependency",
       "multer@<2.2.0": "Security: unhandled multipart errors / DoS <2.2.0 - transitive via @nestjs/platform-express",
-      "js-yaml@<4.2.0": "Security: special-character handling / prototype pollution (patched in 4.2.0; 4.1.2 was never published) - transitive via @nestjs/swagger"
+      "js-yaml@<4.2.0": "Security: special-character handling / prototype pollution (patched in 4.2.0; 4.1.2 was never published) - transitive via @nestjs/swagger",
+      "@xhmikosr/decompress@<11.1.3": "Security: archive extraction can create files/links outside the target directory (GHSA-mp2f-45pm-3cg9, critical) - transitive via @swc/cli>@xhmikosr/bin-wrapper>@xhmikosr/downloader; @swc/cli 0.8.1 is already the latest release and still resolves the vulnerable range, so an override is the only fix"
     },
     "overrides": {
       "axios@<1.16.0": "1.16.0",
@@ -252,7 +253,8 @@
       "hono@<4.12.25": "4.12.25",
       "nodemailer@<9.0.1": "9.0.1",
       "multer@<2.2.0": "2.2.0",
-      "js-yaml@<4.2.0": "4.2.0"
+      "js-yaml@<4.2.0": "4.2.0",
+      "@xhmikosr/decompress@<11.1.3": "11.1.3"
     },
     "//peerDependencyRules": "allowedVersions: deps lag behind our newer majors (graphql-upload wants @types/express@^4, the deprecated apollo playground plugin wants @apollo/server@^4) — both work with our v5. ignoreMissing: browser-only vis-network peers pulled in transitively via yuml-diagram (server-side UML generation never renders, so these are not needed).",
     "peerDependencyRules": {

package/src/config.env.ts

@@ -170,6 +170,10 @@ const config: { [env: string]: IServerOptions } = {
   // Development environment
   // ===========================================================================
   development: {
+    // `development` is not one of the localhost-default environments (local/ci/e2e), so appUrl
+    // must be set explicitly: deriving it from baseUrl would yield the API's own :3000 origin
+    // and leave the frontend on :3001 outside the CORS allowlist.
+    appUrl: process.env.APP_URL || 'http://localhost:3001',
     auth: {
       legacyEndpoints: { enabled: true },
     },