security: reject download tokens without an expiry

[amal66]

Summary

Download links are HMAC-signed tokens, but a token never expired: anyone who ever obtained a link (old chat exports, forwarded messages, logs) could fetch the file forever, and there was no way to invalidate it short of rotating the signing secret. This PR ports the fork's hardening: every token now carries an expiry (30-day default TTL), verification rejects expired tokens, and — fail-closed — a well-signed token without an expiry field is rejected rather than treated as eternal.

Changes

• backend/src/core/downloadTokens.ts (new): pure sign/verify functions. Payload gains an e (expiry, unix seconds) field, default TTL 30 days; verifyDownloadPayload returns null when e is missing, non-numeric, or in the past. Also hardens the timing-safe compare against length differences.
• backend/src/lib/downloadTokens.ts: becomes a thin env-secret wrapper (signDownload / verifyDownload / buildDownloadUrl) delegating to the core module. Public API unchanged — no caller changes needed.
• backend/src/lib/__tests__/downloadTokens.expiry.test.ts (new): the fork's "token expiry" suite — future-exp accepted, past-exp rejected, well-signed legacy token without an exp field rejected.
• backend/tsconfig.json: excludes test files from tsc output (byte-identical to the exclusion in the test-harness PR, so both merge cleanly), keeping npm run build green before vitest lands.

Note on rollout: previously issued (non-expiring) tokens become invalid — deliberate, that is the vulnerability being closed. Fresh tokens are re-issued wherever download URLs are built.

Why

Fail-open token validation is the wrong default for a legal product: a leaked link is a permanent, unauthenticated-looking capability to the underlying document path. Expiring tokens bound that exposure, and rejecting exp-less tokens closes the legacy loophole instead of grandfathering it in.

Testing

• cd backend && npm install && npm run build — tsc green as committed (no vitest required).
• With the test-harness PR merged locally (git merge upstream-pr/test-harness, clean, no conflicts): cd backend && npm test — 2 files, 15/15 passed (12 from the harness's downloadTokens.test.ts + 3 expiry tests from this PR).
• Local merge of this branch + the harness branch + the production-cors branch: clean, 24/24 backend tests pass.

Provenance

All changes are mechanical ports of code in amal66/mike@origin/main (commit b3166dd); exceptions:

• The fork keeps its expiry tests inside apps/api/src/lib/__tests__/downloadTokens.test.ts; the harness PR already ships the non-expiry subset of that file at the same backend path, and git's add/add merge conflicts even on pure one-sided insertions (verified empirically), so the remaining suite lands as a sibling file downloadTokens.expiry.test.ts. Its contents are line-for-line from the fork's test file (only the unused beforeAll/afterAll imports trimmed).

Credits & prior art

• @bmersereau (upstream #77) — adapted from fix: add expiration to download tokens (30-day TTL) Open-Legal-Products/mike#77, which first added an expiry (exp field, 30-day default TTL) to the HMAC-signed download tokens. The fork's original expiry commit records fix: add expiration to download tokens (30-day TTL) Open-Legal-Products/mike#77 as its precedent, and this PR carries the same payload shape and TTL. The one deliberate difference: fix: add expiration to download tokens (30-day TTL) Open-Legal-Products/mike#77 accepted legacy tokens without an expiry for backward compatibility; this PR rejects them (fail-closed).

🤖 Generated with Claude Code

https://claude.ai/code/session_01CEguyEgXa9JjCciXCcVemC