[Bccorb]

v0.20 hardening for the JS server adapters (core, Express, Fastify, Next.js). One commit per issue.

Fixes

#225 Refuse dot-segment params in hand-written passthroughs

• Core gains encodePathParam and InvalidPathParamError (400). They refuse empty, . and .. params, sharing the dot-segment rule (isDotSegment) with the manifest matcher.
• Used by the Express hand-written passthroughs, the Fastify and Next.js resolveUpstreamPath, and the core admin, session, organization switch, magic link verify and OAuth handlers. Next.js maps the error to 400 bad_request; Express and Fastify already did that for a 4xx error.
• Tests: packages/fastify/tests/dotSegmentParams.test.js sends raw %2e%2e paths over a real socket to both Fastify and Express (light-my-request and supertest resolve dot segments themselves). packages/core/tests/pathParam.test.js covers the helper and the core handlers. Next.js parses every request URL with the WHATWG parser, which already resolves %2e%2e, so it gets the shared core check but no route-level test.

#226 Check the token type in ensureCookies and verifyUpstreamSession

• ensureCookies now requires the access cookie's inner token to be typ: "access", using the guards' holdsAccessToken (now exported). Otherwise it answers 401 and clears the cookie, as for an invalid one.
• verifyUpstreamSession checks typ. It takes a new optional expectedType argument (default access). /login and the manifest's pre-auth and registration routes pass ephemeral.
• Tests: core ensureCookies and upstreamSession cases, plus a Fastify/Next.js parity scenario (an access cookie holding a pre-auth token gets 401 on both). Existing tests that put opaque strings like "access-token" in access cookies now use typed tokens.

#227 Do not follow redirects on upstream requests

• authFetch sends every upstream request with redirect: "manual", and a 3xx becomes 502 { "error": "upstream_redirect" } with one error log. The log names only the origin, because the path can carry a magic link token. The manifest fetch also uses redirect: "manual" and falls back to the bundled copy.
• Tests: a real two-server test proves that 301/302/307/308 never reach the redirect target. Also a manifest test, and a parity scenario (upstream 302 gives 502 on both adapters).

#228 Keep the API's framing and content-type headers on the console proxy

• All three console proxies forward Content-Security-Policy, X-Frame-Options and X-Content-Type-Options. When neither the API nor the application set the last two, the proxy falls back to X-Frame-Options: DENY and X-Content-Type-Options: nosniff.
• Tests: console parity scenarios in Fastify and Next.js, for headers forwarded and for the fallback.

#229 Least-privilege tokens and pinned actions

• Every workflow sets top-level permissions: contents: read. Release (contents/pull-requests/id-token: write) and prerelease (id-token: write) keep their job-level grants.
• actions/checkout, actions/setup-node, pnpm/action-setup and changesets/action are pinned to full commit SHAs, with a version comment. Each stays on its current major.
• .github/dependabot.yml adds weekly, grouped github-actions updates.
• Not done here: npm trusted publishing. Each package has to be configured on npmjs.com before NPM_TOKEN can go, so publishing still uses the token and stays working. The reusable conformance workflow stays on fells-code/seamless-cli@main (first-party).

#230 Check Origin against allowedOrigins even when Sec-Fetch-Site is present

• checkOrigin: cross-site is refused and same-origin passes. With allowedOrigins configured, a state-changing same-site request must now carry an Origin on the list (a missing Origin is refused).
• Default decision: without allowedOrigins, behavior is unchanged (a same-site request passes). This is documented in the Express, Fastify and Next.js READMEs.
• Tests: Express origin guard cases and a Fastify/Next.js parity matrix.

#231 Refuse known placeholder secrets at startup

• assertSecretStrength refuses dev-only-cookie-signing-key-replace-me, GRAB_FROM_SEAMLESS_AUTH_PORTAL_DEV and anything containing replace-me. It takes a new { allowPlaceholder } option. assertSecrets reads cookieSecure, so the Express router, the Fastify plugin and the Next.js handler refuse a placeholder at startup unless cookieSecure: false (the insecure local mode).
• Per-request and guard checks (ensureCookies, refresh, getSeamlessUser, createServiceToken, requireAuth, the Next.js session helpers) keep the length check only. They cannot tell local mode apart, and the adapter has already refused at startup.
• Defense in depth: authenticateRequest (behind requireAuth in Express and Fastify) now verifies a cookie's inner access token against JWKS when the guard has authServerUrl and audience, requires a matching sub, and takes the roles from the verified token. Without that configuration there is no JWKS to check against, so it still only decodes. The sync authenticateCookie and the Next.js getSeamlessClaims keep their local-only contract. getSeamlessSession sends the token to the API, which verifies it.
• Tests: core validateSecrets cases, Express startup cases, Fastify/Next.js parity startup cases, and Express/Fastify guard cases (forged inner token, sub mismatch, roles taken from the token).

Changesets

Patch for #225, #226, #227 and #228. Minor (pre-1.0 signal for a behavior change) for #230 and #231. Each covers core and the adapters it touches. None is major.

Checks (worktree root)

pnpm install --frozen-lockfile   ok
pnpm build                       exit 0
pnpm test                        exit 0
  core     Test Suites: 36 passed  Tests: 462 passed
  express  Test Suites: 33 passed  Tests: 228 passed
  nextjs   Test Suites: 7 passed   Tests: 191 passed
  fastify  Test Suites: 9 passed   Tests: 205 passed

pnpm check:types-current fails on main as well: @seamless-auth/types 0.31.0 is published and the packages pin ^0.29.0. That bump is a separate change, so it is not part of this PR.

Cross-repo notes

• fix(core): do not follow redirects on upstream requests #227 adds a new failure code (upstream_redirect, 502) that SDKs may see.
• fix(console): keep the API's framing and content-type headers on the console proxy #228, feat: check Origin against allowedOrigins even when Sec-Fetch-Site is present #230 and fix: refuse known placeholder secrets at startup in every adapter #231 also need the same change in seamless-auth-go, seamless-auth-python and seamless-auth-rust, per the issues.

Closes #225
Closes #226
Closes #227
Closes #228
Refs #229
Closes #230
Closes #231