diff --git a/SECURITY-REVIEW.md b/SECURITY-REVIEW.md
new file mode 100644
index 000000000..5bb40cdd4
--- /dev/null
+++ b/SECURITY-REVIEW.md
@@ -0,0 +1,872 @@
+# VitNode security review
+
+**Date:** 2 September 2026
+**Scope:** the whole monorepo at `bd66817` — the Hono API (`packages/vitnode/src/api`), the
+Content Engine, the TanStack Start web app, the storage/SSO/search adapters, the
+plugins, the scaffolding templates and the CI workflows.
+**Branch:** `claude/vitnode-security-review-5ly6gw`
+
+## How this was done, and how far to trust it
+
+Fourteen parallel auditors covered one attack surface each — authentication, authorisation,
+password recovery, SSO, uploads, injection, XSS, CSRF/CORS/headers, rate limiting, SSRF,
+secrets, response shape, cron/queue/WebSocket, and dependencies/CI. They produced 47
+candidate findings. A completeness critic then went looking for surface none of them had
+covered and named eleven gaps, which were audited in turn for 16 more candidates. Each
+candidate was re-read by three independent verifiers with different briefs: one trying to
+refute it, one trying to write the exploit, one judging whether the proposed fix was right.
+
+**Every issue below I also read and confirmed in the source myself before changing anything**,
+and that — not the panel — is what each fix rests on. One caveat worth stating plainly,
+because it affects how the machine-generated verdicts read: the verifiers ran _after_ the
+first round of fixes was already committed, so they were reading patched code. Findings like
+the plaintext reset tokens and the broken rate limiter come back from that pass marked "not
+real" for exactly the reason you would hope — they had been fixed. Their evidence is the
+original auditors' reading of the pre-fix code, quoted in each entry below, plus my own.
+
+Where I could make a fix falsifiable I did. The open redirect (finding 9) is the clearest
+case: I reverted the patch, watched all five payloads redirect to `evil.example`, and put
+the patch back. Findings that depend on a live database or a real browser are argued from
+the code rather than demonstrated, and I have said so where that is true.
+
+---
+
+## Summary
+
+**24 issues fixed.** 2 critical, 4 high, 9 medium, 9 low.
+
+Two of them are worth reading first, because they are the ones an attacker reaches without
+help:
+
+- **Any administrator could make themselves root** by assigning a role in the field beside
+  the one that was guarded.
+- **Any installation that never set `CRON_SECRET`** would run every registered cron job for
+  anyone on the internet, using a password published in this repository.
+
+A third is not an attack but the absence of a defence: **the rate limiter never worked.** It
+was wired one line too early, so every request in the deployment shared a single bucket. That
+is both a one-host denial of service and the reason several other findings below are worse
+than they look — there was nothing throttling the attempts.
+
+Nothing here required a database migration, and no existing data or credential is
+invalidated by any of it.
+
+| #   | Severity | Issue                                                        | File                                       |
+| --- | -------- | ------------------------------------------------------------ | ------------------------------------------ |
+| 1   | Critical | Privilege escalation to root via `secondaryRoleIds`          | `admin/users/routes/update.route.ts`       |
+| 2   | Critical | World-runnable cron on the published default secret          | `middlewares/cron-auth.middleware.ts`      |
+| 3   | High     | Rate limiter keyed on `undefined` — one global bucket        | `api/config.ts`                            |
+| 4   | High     | Live password-reset links readable from the admin queue list | `admin/advanced/queue/routes/get.route.ts` |
+| 5   | High     | Reset tokens stored in plaintext                             | `users/routes/reset-passowrd.route.ts`     |
+| 6   | Medium   | Cross-site WebSocket hijacking                               | `apps/api/src/index.ts`                    |
+| 7   | Medium   | Client-chosen IP address                                     | `middlewares/global.middleware.ts`         |
+| 8   | Medium   | Stored XSS through the upload file extension                 | `api/models/storage.ts`                    |
+| 9   | Medium   | Open redirect off the origin                                 | `tanstack/i18n/request.ts`                 |
+| 10  | Medium   | Password reset left every old session alive                  | `users/routes/change-password.route.ts`    |
+| 11  | Medium   | Unguarded admin notification push                            | `admin/routes/notifications.route.ts`      |
+| 12  | Medium   | OpenAPI document and Swagger UI public in production         | `api/config.ts`                            |
+| 13  | Low      | Account enumeration by sign-in timing                        | `models/user/sign-in-with-passwords.ts`    |
+| 14  | Low      | Captcha token injected into the verification URL             | `middlewares/captcha.middleware.ts`        |
+| 15  | Low      | Auth cookies stated no `SameSite`                            | `api/lib/auth-cookie.ts`                   |
+| 16  | Low      | Unauthenticated debug route writing a log row per call       | `users/routes/test.route.ts`               |
+| 17  | High     | Start mount resolves every caller to one address             | `apps/web/src/vitnode.api.config.ts`       |
+| 18  | Medium   | No request body size limit, in front of scrypt               | `api/config.ts`                            |
+| 19  | Medium   | Discord SSO accepted an unverified provider email            | `adapters/sso/discord.ts`                  |
+| 20  | Medium   | Demotion did not take effect for a minute                    | `admin/users/routes/update.route.ts`       |
+| 21  | Low      | Unauthenticated requests wrote unbounded device rows         | `api/models/device.ts`                     |
+| 22  | Low      | Unvalidated search params became 500s and log rows           | `modules/search/routes/search.route.ts`    |
+| 23  | Low      | One role's full record readable without `roles:can_view`     | `admin/roles/routes/show.route.ts`         |
+| 24  | Low      | Dev databases published on every interface                   | `docker-compose.yml` (both)                |
+
+Eight further issues are **reported but deliberately not fixed** — they need a product
+decision or a deployment decision rather than a patch. They are in
+[Not fixed](#not-fixed-needs-a-decision) at the end.
+
+---
+
+## Critical
+
+### 1. Any administrator could escalate themselves to root
+
+`packages/vitnode/src/api/modules/admin/users/lib/assert-edit-user-permission.ts`
+`packages/vitnode/src/api/modules/admin/users/routes/update.route.ts:211`
+
+`PATCH /admin/users/{id}` takes both a primary `roleId` and a list of `secondaryRoleIds`.
+Only the primary one went through `assertCanAssignPrimaryRole`, the guard whose own doc
+comment explains that attaching an admin-granting role "must require the same
+`can_edit_admin` permission … otherwise a `can_edit`-only admin could escalate a non-admin
+user into an admin."
+
+Secondary roles are not a lesser kind of role. `loadStaffPermissions` resolves a user's
+powers from `getUserRoleIds`, which is the primary role **plus every secondary one**, and a
+`root` role there short-circuits the entire permission system to "yes":
+
+```ts
+const roleIds = await getUserRoleIds(c, user);   // primary + secondary
+const rootRoles = await db.select(...).where(
+  and(inArray(core_roles.id, roleIds), eq(core_roles.root, true)),
+);
+if (rootRoles.length > 0) return { root: true, permissions: [] };
+```
+
+**The attack.** An administrator holding nothing but `users:can_edit` sends:
+
+```http
+PATCH /api/@vitnode/core/admin/users/{their own id}
+{ "secondaryRoleIds": [4] }        # 4 = the seeded Administrator role
+```
+
+`assertCanEditAdminTarget` passes — it only fires when the _target_ is already an admin, and
+it reads the primary role. The route's own validation only rejects `guest` roles. The write
+lands, and on the next request their permission set resolves to `root`. They now hold every
+permission on the install, including the `can_edit_admin` they were denied a moment earlier.
+
+**Fixed.** Every role being attached — primary and secondary, in one query — now goes through
+the guard, which was also widened: it previously recognised only a role with a
+`core_admin_permissions` row, and now also catches `core_roles.root` in its own right and
+moderator-granting roles. Covered by `assert-edit-user-permission.test.ts`, including the
+"staff role hidden among ordinary ones" case that is the actual exploit.
+
+### 2. Cron jobs runnable by anyone, using a password published in this repository
+
+`packages/vitnode/src/lib/config.ts:51`
+`packages/vitnode/src/api/middlewares/cron-auth.middleware.ts`
+
+```ts
+get cronJobSecret(): string {
+  return process.env.CRON_SECRET ?? INSECURE_DEFAULT_CRON_SECRET;
+}
+```
+
+The middleware guarding `POST /api/@vitnode/core/cron/` began:
+
+```ts
+const cronSecret = c.get("core").cronSecret;
+if (!cronSecret)
+  throw new HTTPException(403, { message: "Cron access not configured" });
+```
+
+That check can never fire, because the fallback above means `cronSecret` is never empty. So
+on any installation that did not set `CRON_SECRET`, this works from anywhere:
+
+```http
+POST /api/@vitnode/core/cron/
+Authorization: Bearer default-cron-secret-change-in-production
+```
+
+and every registered cron job runs — search reindexing, queue draining, whatever plugins
+have added. Repeated, it is a free resource-exhaustion primitive on someone else's
+infrastructure.
+
+The admin panel does flag this ("cron is insecure while this value is in use"), but a
+warning is not a control. Worse, the scaffolded `.env.example` ships its own placeholder,
+`your-secure-cron-secret-key`, so an install that copied the file and never edited that one
+line reads as configured while being exactly as open.
+
+**Fixed.** Production refuses cron requests while any published placeholder is in use, with
+an error naming the variable to set; development still works out of the box. Two smaller
+faults in the same twenty lines went with it:
+
+- `providedSecret !== cronSecret` compared secrets with `!==`, which returns as soon as the
+  bytes differ. Now `timingSafeEqual`, with the length branch also doing a comparison so the
+  timing does not leak the secret's length either.
+- `authHeader?.replace("Bearer ", "")` removed the first occurrence of that substring
+  _anywhere_ in the header, so `Basic Bearer <secret>` parsed as a credential and a secret
+  containing the word "Bearer " lost part of itself. Now an anchored prefix match.
+
+Twelve tests in `cron-auth.middleware.test.ts`.
+
+---
+
+## High
+
+### 3. The rate limiter never limited anything
+
+`packages/vitnode/src/api/config.ts:77`
+
+```ts
+app.use("*", rateLimiterMiddleware(vitNodeApiConfig.rateLimiter, redisClient));  // reads ipAddress
+app.use("*", globalMiddleware({ ... }));                                        // sets ipAddress
+```
+
+Hono runs middleware in registration order, and the limiter reads its bucket key
+(`c.get("ipAddress")`) before calling `next()`. At that moment nothing has set it.
+`rate-limiter-flexible` stringifies whatever it is given, so every request made to the
+deployment — every visitor, every route, every SSR render — consumed points from one shared
+bucket named `vitnode-api-rate-limiter:undefined`.
+
+Two consequences, in opposite directions:
+
+- **No throttling.** There was no per-client limit on anything, including `POST /sign_in`,
+  which has no captcha either. Findings 5 and 13 below are both materially worse for it.
+- **A global kill switch.** At the default 80 points per 60 seconds, one host sending ~1.3
+  requests a second holds the entire site at `429` for everybody.
+
+The unit test did not catch it because it installs its own middleware setting `ipAddress`
+_before_ the limiter — the exact opposite of the real wiring.
+
+**Fixed.** IP resolution moved into its own `clientIpMiddleware`, registered ahead of the
+limiter. `globalMiddleware` keeps a fallback for anyone composing middleware by hand, so a
+missing address can no longer become a rate-limit key silently.
+
+### 4. Every outgoing email, including live password-reset links, readable from the admin queue
+
+`packages/vitnode/src/api/modules/admin/advanced/queue/routes/get.route.ts:79`
+
+`EmailModel.send` queues the _fully rendered_ message:
+
+```ts
+await this.c.get("queue").dispatch({
+  name: "send-email",
+  payload: {
+    to: email.to,
+    subject: email.subject,
+    html: email.html,
+    text: email.text,
+  },
+});
+```
+
+and the admin queue list selected the whole row:
+
+```ts
+.select({ ...getColumns(core_queue), ...cursorSelection })
+```
+
+`getColumns` includes `payload`. The route's declared response schema lists thirteen fields
+and `payload` is not among them — but nothing validates a response against its schema in
+`@hono/zod-openapi`, so the column simply travelled. The declared contract and the shipped
+behaviour disagreed, and the shipped one won.
+
+**The attack.** `queue:can_view` is the only permission in the `queue` module — a read-only
+"look at the job list" grant, the sort given to someone who watches the health of a
+deployment. Holding it:
+
+```http
+GET /api/@vitnode/core/admin/advanced/queue/?status=pending
+```
+
+returns the HTML of every queued email. Trigger a password reset for the root administrator,
+read the reset link out of the queue before the worker sends it, and take the account. It
+also exposes every address the install has ever mailed and the contents of every
+notification.
+
+**Fixed.** The handler selects exactly the columns its schema declares. The admin UI never
+read `payload`, so nothing changes for it.
+
+### 5. Password-reset tokens stored in plaintext
+
+`packages/vitnode/src/api/modules/users/routes/reset-passowrd.route.ts:57`
+
+`ForgotPasswordTokenModel` has had a `hashResetToken` method all along. Nothing called it.
+The reset route generated a token, wrote it to `core_users_forgot_password.token` as-is —
+under a variable helpfully named `hashToken` — and mailed the same value:
+
+```ts
+const hashToken = new ForgotPasswordTokenModel().generateResetToken(); // not hashed
+```
+
+So the table held a set of live, unexpired credentials in the clear. Any read of it is
+account takeover for every user with a pending reset: a SQL-injection primitive found later,
+a database backup, a read replica, a logged query, a support export. The token is what
+proves identity to `change-password`, and it was sitting next to the `userId` it unlocks.
+
+**Fixed.** The raw token goes in the email and nowhere else; only its SHA-256 digest is
+stored, and `change-password` hashes the incoming token before looking it up. The digest is
+64 characters and the column is `varchar(100)`, so **no migration is needed** — existing
+rows are simply stale and expire within thirty minutes.
+
+---
+
+## Medium
+
+### 6. Cross-site WebSocket hijacking
+
+`apps/api/src/index.ts:51` — new `packages/vitnode/src/api/middlewares/websocket-origin.middleware.ts`
+
+`app.get("/ws", upgradeWebSocket(handleVitNodeWebSocket()))` authenticates from the session
+cookie on the handshake and registers the connection against that user. It never looked at
+`Origin`.
+
+The same-origin policy does not apply to `new WebSocket(...)`. Any page may open a socket to
+any host, the browser attaches that host's cookies, and there is no preflight to refuse it
+and no CORS header that governs it. Hono's `csrf()` does not help: it inspects non-`GET`
+requests, and a WebSocket handshake is a `GET`.
+
+So any site a signed-in visitor has open could `new WebSocket("wss://your-site/api/ws")`,
+be registered as that visitor, receive everything the server pushes them — notifications,
+and whatever plugins send — and send messages handled with their identity.
+
+**Fixed.** An origin check ahead of the upgrade, allowing the configured web and API origins
+plus anything the app passes in. A handshake carrying **no** `Origin` is allowed: browsers
+always send one, so an originless handshake is a non-browser client, which has no ambient
+cookies to ride. Nine tests, including look-alike hosts, wrong scheme and wrong port.
+
+### 7. Callers could choose their own IP address
+
+`packages/vitnode/src/api/middlewares/global.middleware.ts:327`
+
+```ts
+const ipHeaderKeys = ["x-forwarded-for", "x-real-ip", "cf-connecting-ip", ... 16 of them];
+for (const key of ipHeaderKeys) { ipAddress = c.req.header(key); if (ipAddress) break; }
+```
+
+All sixteen are request headers, so all sixteen are attacker-controlled. Whatever the client
+put in the first one present became their identity. That identity is used for the rate-limit
+bucket and for the audit trail on password-reset rows, and it made both meaningless: a fresh
+`X-Forwarded-For` per request is a fresh bucket per request, and `userIpAddress` in a reset
+email said whatever the requester wanted it to say.
+
+**Fixed** in `api/lib/client-ip.ts`. The socket address is the default — the one value a
+caller cannot pick — and a forwarded header is read only when `trustProxy` says how many
+proxies are actually in front. It counts **from the right**, because a proxy appends the
+address it saw: behind one proxy, a client sending `X-Forwarded-For: 9.9.9.9` produces
+`9.9.9.9, <real client>`, and one entry from the right is the real client. Reading the
+leftmost entry, which is the usual way this is got wrong, returns the forgery.
+
+Seventeen tests cover forged chains of arbitrary length, multiple hops, and each of the
+sixteen old headers being ignored.
+
+> **Deployment note.** `trustProxy` defaults to _off_, which is correct for a directly
+> reachable API and safe everywhere. **If VitNode runs behind nginx, Traefik, Cloudflare or a
+> platform edge, set it** — otherwise every visitor resolves to the proxy's address and shares
+> one rate-limit bucket. On the TanStack Start mount there is no socket at all (the bridge
+> calls `app.fetch(request)` directly), so the API now prints a one-time warning at boot
+> naming the setting rather than degrading in silence.
+
+### 8. Stored XSS through the upload file extension
+
+`packages/vitnode/src/api/models/storage.ts:495` and `lib/api/upload.ts`
+
+Both halves of an upload come from the client and nothing made them agree. The media type
+was checked against the allowlist:
+
+```ts
+if (allowedMimeTypes && !allowedMimeTypes.includes(file.type)) throw ...
+```
+
+and then the stored extension was taken from the _filename_:
+
+```ts
+generateStorageFileName(file.name); // → `${randomUUID()}${getFileExtension(originalName)}`
+```
+
+`image/gif` and `image/svg+xml` are deliberately excluded from sharp's re-encode list, so for
+those the bytes are never inspected either. Upload a file announced as `image/gif`, named
+`payload.html`, containing script: it passes the type check, skips the image pipeline, and is
+written as `<uuid>.html`. `apps/api` serves the uploads directory with `serveStatic` from the
+API's own origin — the origin the session cookie belongs to — so the result is a page on the
+site. `POST /admin/debug/test-storage-upload` allows `image/gif` and hands back the URL; a
+Content Engine file field allows it wherever `allowedMimeTypes` is set without
+`allowedExtensions`.
+
+**Fixed**, in two layers:
+
+- The stored extension is bound to the validated media type: a known type may only be stored
+  under one of its own extensions, and an unknown type may not be stored under one a browser
+  executes (`.html`, `.php`, `.js`, `.xml`, `.svgz` and friends become `.bin`). The display
+  name in `core_files` is untouched, so downloads keep the name the user gave.
+- The uploads mount now sends `Content-Security-Policy: sandbox` and
+  `X-Content-Type-Options: nosniff`. `sandbox` applies only to documents, so images —
+  including SVG loaded through `<img>` — are unaffected, but anything _navigated to_ lands in
+  an opaque origin with no cookies and no same-origin API.
+
+`.svg` is still storable on purpose: it is a real image type a CMS should accept, and the
+sandbox header is the right place to neutralise script in one.
+
+### 9. Open redirect off the origin
+
+`packages/vitnode/src/tanstack/i18n/request.ts:108`
+
+Canonicalising a locale prefix strips it from the front of the path. `/en//evil.example`
+therefore becomes `//evil.example`, which is not a path — it is a protocol-relative URL, and
+a browser following that `Location` reads everything after the two slashes as a host.
+Verified directly:
+
+```
+GET /en//evil.example  →  308, Location: //evil.example  →  https://evil.example/
+```
+
+A phishing link genuinely hosted on the real domain, and a way past any allowlist that trusts
+a same-origin-looking path.
+
+**Fixed.** Leading slashes collapse to one, backslashes folded in — browsers treat those as
+separators here even though the URL parser does not. The new test fails on all five payloads
+without the fix, which was checked by reverting it.
+
+### 10. A password reset left every existing session alive
+
+`packages/vitnode/src/api/modules/users/routes/change-password.route.ts`
+
+The route set the new hash and deleted the reset row, and stopped. Sessions last ninety days
+by default, so an attacker holding one kept it — which inverts the meaning of the action.
+Somebody resetting a password after a compromise believes they have just locked the intruder
+out; they had locked them out of _signing in again_ and nothing else.
+
+**Fixed.** A completed reset revokes every session and admin session for that user and drops
+them from the session cache (new `api/models/session-revoke.ts`). It runs after the password
+write, so a failure there cannot sign somebody out without having changed anything.
+
+### 11. Unguarded admin notification push
+
+`packages/vitnode/src/api/modules/admin/routes/notifications.route.ts`
+
+`POST /admin/notifications/send` checked for _an_ admin session and no permission, so any
+administrator — including one restricted to a single unrelated screen — could push an
+arbitrary title and body to any user id. Notifications arrive inside the product wearing the
+product's own UI, which makes them a good phishing surface.
+
+`AGENTS.md` says "New admin APIs always require staff permissions", and the calling code
+already believed this one did: its comment reads "`POST /admin/admin/notifications/send`
+declares its own". It did not.
+
+**Fixed.** Gated on `dashboard:can_edit`, matching its sibling widget route — the
+send-notification dashboard widget is the only caller.
+
+### 12. OpenAPI document and Swagger UI public in production
+
+`packages/vitnode/src/api/config.ts:65`
+
+`app.doc("/swagger/doc", ...)` and `app.get("/swagger", swaggerUI(...))` ran unconditionally,
+publishing every route, parameter and response shape in the installation — the admin tree
+included — to anyone who asked. That is a map of the attack surface, and it is how several
+findings above would be located in the first place.
+
+**Fixed.** On in development, off in production unless an install opts in with
+`docs: { enabled: true }`.
+
+---
+
+## Low
+
+### 13. Account enumeration by sign-in timing
+
+`packages/vitnode/src/api/models/user/sign-in-with-passwords.ts:30`
+
+An unknown email returned `403` without hashing anything; a known one first spent a scrypt
+derivation. That difference is tens of milliseconds and measurable over a network, which
+makes the sign-in endpoint an oracle for which addresses hold accounts — the list a
+credential-stuffing run wants before it starts. With finding 3 in place there was nothing
+rate-limiting the questions.
+
+**Fixed.** The not-found path spends a derivation against a dummy hash, so both answers cost
+the same. Two smaller faults in the same class went with it:
+
+- `verifyPassword` called `reject(err)` without returning and then used the undefined
+  `derivedKey`; a stored hash without a `:` threw out of the promise executor and reached the
+  client as a `500` instead of a refused sign-in. Both are now a plain `false`.
+- The salt widens from 8 to 16 bytes. Existing hashes keep working — the salt is read back
+  out of the stored string — and there is a test pinning that.
+
+### 14. Captcha token injected into the verification URL
+
+`packages/vitnode/src/api/middlewares/captcha.middleware.ts:45`
+
+```ts
+fetch(
+  `https://www.google.com/recaptcha/api/siteverify?secret=${secretKey}&response=${token}&remoteip=${userIp}`,
+);
+```
+
+`token` is a client-supplied header, interpolated unencoded, so it could carry `&` and append
+parameters of its own to the request. The same line put the site's secret key in a URL —
+the part of a request that ends up in proxy logs and error reports.
+
+**Fixed.** Both travel in a form-encoded body. A missing secret key now fails closed
+explicitly rather than relying on the provider to reject a malformed request.
+
+### 15. Auth cookies stated no `SameSite`
+
+`packages/vitnode/src/api/lib/auth-cookie.ts`
+
+Chrome and Firefox default an omitted `SameSite` to `Lax`, but that is a default, not a rule
+— Safari and older engines differ, and a cookie whose cross-site behaviour depends on which
+browser is reading it cannot be reasoned about. CSRF here is otherwise covered by Hono's
+`csrf()`, which is why this is low rather than higher.
+
+**Fixed.** `Lax`, explicitly, on the session, admin, device and SSO-state cookies. Not
+`Strict`: the SSO round trip lands as a top-level cross-site `GET`, and `Strict` would drop
+the state cookie on the way back from the provider and break every social sign-in.
+
+### 16. Unauthenticated debug route
+
+`packages/vitnode/src/api/modules/users/routes/test.route.ts`
+
+`POST /api/@vitnode/core/users/test` shipped in production, required nothing, and wrote a row
+to `core_logs` on every call. With the rate limiter broken it was a cheap way to fill a disk.
+
+**Fixed.** Removed, along with its registration.
+
+---
+
+## Found by the completeness pass
+
+The critic that went looking for missed surface earned its keep: these eight are all things
+the fourteen dimension auditors walked past.
+
+### 17. On the TanStack Start mount, every caller resolved to the same address (high)
+
+`apps/web/src/server/api-bridge.ts:22`
+
+The bridge is one line, and deliberately so:
+
+```ts
+export const createApiBridge =
+  (app: FetchableApp): ApiBridge =>
+  async request =>
+    app.fetch(request);
+```
+
+Hono's signature is `fetch(request, env, executionCtx)`, so calling it with one argument
+leaves `c.env` undefined — and `socketAddress()` starts by checking exactly that, meaning it
+can never find a peer address on this mount. With `trustProxy` unset there is nothing else to
+fall back to, so **100% of requests through the web app resolved to `127.0.0.1`.**
+
+This is finding 3 again, arriving by a different road: one shared rate-limit bucket for the
+whole site, exhaustible by one host at ~1.3 requests a second, plus a password-reset audit
+trail that records `127.0.0.1` for everybody. `apps/api` is unaffected — `@hono/node-server`
+passes `{ incoming, outgoing }` as the env, so the Node branch of the probe resolves.
+
+**Fixed**, as far as it can be. There is no socket to read here — Start's handler is given a
+`Request` and nothing else — so this is a deployment fact rather than a bug to patch out:
+
+- Both reference apps now read `TRUST_PROXY` for the hop count, documented in both
+  `.env.example` files, so the operator has a switch and does not have to edit code.
+- The API prints a one-time warning at boot when it has neither a socket nor a trusted
+  header, naming the setting. Silently degrading to one bucket was the real defect; being
+  told is the fix.
+
+### 18. No request body size limit, in front of scrypt (medium)
+
+`packages/vitnode/src/api/config.ts`
+
+Nothing anywhere in the stack bounded a request body. `POST /sign_in` reads its JSON and then
+runs scrypt unconditionally, so an unauthenticated caller was choosing both how much memory
+the server buffers and how much CPU it then spends. The two compose: a handful of large
+bodies against an endpoint that always hashes is a cheaper denial of service than either half
+alone.
+
+**Fixed.** A 25 MB default via Hono's `bodyLimit`, answering `413`, with `maxBodySize` to move
+it. Uploads are unaffected — a Content Engine file field enforces its own `maxBytes` before a
+byte reaches storage — so this is the outer wall, not the upload rule.
+
+### 19. Discord SSO accepted an unverified provider email (medium)
+
+`packages/vitnode/src/api/adapters/sso/discord.ts:19`
+
+The Google adapter reads `verified_email` and refuses when it is false. Discord's user schema
+did not include `verified` at all, so an account whose email Discord has never confirmed
+could sign in and have a VitNode account created keyed on that address.
+
+The worst case is closed elsewhere — `SSOModel.callback` answers `409` rather than
+auto-linking when the email already exists, so this is not takeover of an existing account.
+What it does allow is registering under an address you cannot read, holding the account the
+real owner would have had, and being bound to it if the install ever adds email recovery.
+
+**Fixed.** Discord now refuses an unverified email, in the same shape as Google. Facebook is
+noted below: its Graph API exposes no equivalent flag, so there is nothing to check.
+
+### 20. A demotion did not take effect for about a minute (medium)
+
+`packages/vitnode/src/api/modules/admin/users/routes/update.route.ts`
+
+A role change expired the staff-permission cache — correctly — and stopped there. But
+`resolveStaffPermissions` is handed `c.get("user")`, which is the _session_ cache's copy of
+the user, and reads the primary role straight off it:
+
+```ts
+const roleIds = await getUserRoleIds(c, user); // [user.roleId, ...secondary]
+```
+
+So recomputing after the invalidation reached the same answer it had just thrown away, out of
+a stale `roleId`. Somebody demoted out of an administrator role kept its powers for up to the
+session cache's 60-second TTL — a minute in which the AdminCP said the demotion had been
+applied and it had not.
+
+**Fixed.** Both caches now go, on both write paths — and the second one matters more, because
+a request that changes only roles never reaches the branch the first invalidation sat in.
+
+### 21. Unauthenticated requests wrote unbounded device rows (low)
+
+`packages/vitnode/src/api/models/device.ts`
+
+`SessionModel.getUser` resolved the device _before_ it knew the session was real, and
+resolving created one if the device cookie named nothing. So any request carrying a made-up
+`vitnode_auth` cookie inserted a `core_sessions_known_devices` row and then discovered there
+was no session — one row per request, unauthenticated, for as long as anybody cared to keep
+sending them.
+
+**Fixed** by splitting the model in two, which also makes the intent legible:
+`getExistingDeviceId` is a read, used by session resolution — where a missing device already
+means no session, since a session row is tied to one — and `getOrCreateDeviceId` is used by
+sign-in and sign-up, where minting a device record is the point rather than a side effect.
+Five tests count the inserts.
+
+### 22. Unvalidated search parameters became 500s and log rows (low)
+
+`packages/vitnode/src/api/modules/search/routes/search.route.ts:94`
+
+```ts
+authorId: query.authorId ? Number(query.authorId) : undefined,
+dateFrom: query.from ? new Date(query.from) : undefined,
+```
+
+`Number("abc")` is `NaN` and `new Date("abc")` is an Invalid Date, and both went straight into
+the query builder, where Postgres rejects them. That reaches the caller as a `500` — and
+writes a `core_logs` row on the way out, on a public unauthenticated endpoint. So it was a
+log-flooding primitive as much as a wrong status code.
+
+**Fixed.** A filter nobody can parse is not an error; it is a filter that was not asked for.
+Also on the same endpoint's cursor: it becomes the query's `OFFSET` on the relevance path,
+where there is no stable key to seek on, so it is now a checked integer capped at 10,000.
+
+### 23. One role's full record readable without `roles:can_view` (low)
+
+`packages/vitnode/src/api/modules/admin/roles/routes/show.route.ts`
+
+`GET /admin/roles/{id}` was reachable on an admin session alone. `GET /admin/roles/list`
+is ungated _deliberately_ — the parity test documents why, and it is a good reason: a role
+picker has to work for an administrator who cannot open the roles screen. That reasoning does
+not extend to one role's full record, which only the edit screen reads.
+
+**Fixed.** Gated on `roles:can_view`, which `can_edit` already depends on, so nobody who could
+open the screen loses access. The parity test's pinned expectations move with it.
+
+### 24. Dev databases published on every interface (low)
+
+`apps/api/docker-compose.yml`, `packages/create-vitnode-app/copy-of-vitnode-app/docker/docker-compose.yml`
+
+```yaml
+ports:
+  - "5432:5432"
+```
+
+Docker's short form binds to `0.0.0.0`, and the password defaults to `root`. On a laptop that
+means whatever café or office network it is joined to; on a VPS it means the internet. This
+ships in the scaffolding, so it is the default every generated project starts from.
+
+**Fixed.** Both bound to `127.0.0.1`. These are development containers reached from the host,
+so loopback loses nothing.
+
+---
+
+## Not fixed — needs a decision
+
+These are real, and each needs a judgement that is not mine to make.
+
+### Rich-text HTML is never sanitised
+
+`packages/vitnode/src/components/ui/editor-content.tsx`
+
+```tsx
+<div className="tiptap" dangerouslySetInnerHTML={{ __html: content }} />
+```
+
+Tiptap output is stored and rendered with no sanitisation on write, on read, or at the sink,
+and the project has no sanitiser dependency. **Today this is latent, not exploitable:** the
+only caller in the repository is an admin test page passing a hardcoded string, and the blog
+plugin has no public article view yet. But it is a loaded gun pointed at whoever wires the
+first one up, and the first content type with a rich-text field published to a public page
+turns it into stored XSS on the site's own origin.
+
+I have not fixed it because doing so means adding a dependency and choosing an allowlist —
+which tags, which attributes, whether `style` and `class` survive, what happens to embeds.
+That is a product decision. The recommendation is to sanitise **on the server, on write**,
+with an allowlist, before the first public rich-text surface ships.
+
+### `Host` decides the SSR API origin
+
+`packages/vitnode/src/tanstack/fetcher/server.ts:54`
+
+`resolveApiOrigin()` reads the `Host` header of the request being rendered, and those calls
+carry the visitor's cookies. The code is deliberate and thoughtful about this — it explicitly
+refuses `x-forwarded-host`, and documents why — and reading `Host` is what makes per-branch
+preview deployments work at all. But it does place the burden on the deployment: a reverse
+proxy that passes an arbitrary `Host` through lets a request point this server's authenticated
+API calls at a host of the caller's choosing.
+
+Changing it would break the preview-deployment behaviour it exists for, so this is a
+documentation and deployment matter: **the proxy in front of VitNode must validate `Host`**
+(nginx `server_name` with a default-server reject, or the platform equivalent).
+
+### scrypt cost parameters
+
+`packages/vitnode/src/api/models/password.ts`
+
+`crypto.scrypt(password, salt, 64)` uses Node's defaults (N=16384, r=8, p=1), below the
+current OWASP recommendation. I deliberately did **not** raise it: the parameters are not
+recorded in the stored `salt:key` string, so changing them invalidates every existing
+password on every install — a lockout, not an upgrade. Doing it properly means a versioned
+hash format that records its own parameters and re-hashes on next successful sign-in. Worth
+doing; too large to slip into a security pass.
+
+### Sign-in has no captcha and no account lockout
+
+`packages/vitnode/src/api/modules/users/routes/sign-in.route.ts`
+
+`sign-up` and `reset-password` both declare `withCaptcha: true`. `sign-in` declares nothing,
+and there is no per-account lockout or backoff anywhere. With the rate limiter fixed
+(findings 3 and 17) there is now a real per-client limit in front of it, which is why this is
+here rather than higher up — but 80 attempts a minute per address is a credential-stuffing
+budget, not a lockout.
+
+Not fixed because adding `withCaptcha` to sign-in changes the client contract: the form must
+attach `x-vitnode-captcha-token`, and any install with a captcha configured would have
+sign-in break the moment this shipped without the matching frontend change. That is a
+coordinated change, not a patch. The recommendation is `withCaptcha: true` on sign-in plus
+the form change, and a per-account attempt counter with backoff.
+
+### Revoking sessions does not close live WebSockets
+
+`packages/vitnode/src/ws/registry.ts`
+
+A connection's identity is fixed at handshake and held in `wsRegistry`. Nothing closes it
+when the underlying session goes away, so after a password reset (finding 10) or a device
+revoke, an already-open socket keeps receiving that user's pushes until it disconnects on its
+own.
+
+Not fixed because it needs a registry API that does not exist yet — closing by user id, called
+from `revokeAllSessionsForUser`, with a decision about what a plugin's open handlers should
+see. Bounded in practice by how long a socket stays open, and it hands over no new data the
+holder was not already receiving, but it is a real gap in what "signed out everywhere" means.
+
+### Third-party GitHub Actions are pinned to mutable tags
+
+`.github/workflows/*`
+
+Actions are referenced by tag rather than commit SHA, in jobs that hold `NPM_TOKEN` and
+`pull-requests: write`. A tag is mutable, so an upstream compromise reaches this repository
+on its next run. I checked the higher-severity CI shapes and they are clean: no
+`pull_request_target` with a PR-head checkout, and no `${{ github.event.* }}` interpolated
+into a `run:` block.
+
+Not fixed because pinning to SHAs is a maintenance decision — it wants Dependabot configured
+to bump them, or the pins rot and nobody updates them.
+
+### Plugin routes are mounted before core's screens
+
+`apps/web/src/router.tsx`
+
+The anti-shadowing guard cannot see conflicts it is registered after, so a plugin can claim a
+path the core app also serves. Related: the routing manifest does not reserve the `/admin`
+URL namespace to the admin _area_, so a plugin page in the `main` area can answer at an
+`/admin/...` path and be rendered by the unguarded public shell.
+
+Neither is exploitable by an outside attacker — both require installing a hostile or careless
+plugin, which is already trusted code — but they are the kind of structural gap worth closing
+before a third-party plugin ecosystem exists.
+
+### The admin gate is a substring test on the path
+
+`packages/vitnode/src/api/config.ts:119`
+
+```ts
+if (c.req.path.includes("/admin/")) {
+  return await globalAdminMiddleware()(c, next);
+}
+```
+
+Whether a route is admin-gated depends on where its author happened to mount it, rather than
+on how it was registered. A route at an admin module's root (`path: "/"`, no trailing
+segment) misses the gate; a public route whose path happens to contain the substring gets it.
+In this repository every admin route also carries its own `adminStaffPermission` — which
+re-checks the staff tables and fails closed without an admin session — so nothing is
+currently exposed by it, and findings 11 and 23 were the two that had been relying on this
+alone.
+
+Not fixed because the right change is structural: derive the gate from route registration.
+Worth doing before a plugin author trips over it.
+
+---
+
+## Checked and found sound
+
+Recording what held up matters as much as what did not, and several of these are places the
+obvious guess would have been wrong.
+
+- **Session tokens.** 64 bytes from `crypto.getRandomValues`, SHA-256 hashed at rest, scoped
+  to a device id, with the cache TTL capped to the session's remaining lifetime. Sign-out
+  deletes the row and the cache entry.
+- **Admin sessions.** `createSessionByUserId` refuses a user who is not staff, and `getUser`
+  re-checks admin status on the cached path too, so a revoked admin loses access immediately
+  rather than at TTL.
+- **Password comparison.** `timingSafeEqual`, with the length-mismatch branch also comparing.
+- **SQL injection.** No `sql.raw` reaching request data anywhere. Every `orderBy` is a Zod
+  enum resolved to a column object, never a string; pagination is cursor-based and capped at
+  100 rows; `first=0` and `first=abc` are stable `400`s rather than silent defaults. The
+  search adapter's cursor was flagged as a "raw SQL `OFFSET`" and is not one — it goes through
+  Drizzle's parameter binding. It was unvalidated, which is finding 22, and that is a
+  different and much smaller problem than injection.
+- **Path traversal in storage keys.** `sanitizeFolder` validates per segment, so `..`, `a//b`,
+  `/a`, `a/` and backslashes all fail on the same rule; the filename is a fresh UUID, so the
+  user-supplied name never reaches the path.
+- **File ownership.** The user file list, download and delete routes all scope by `userId`;
+  no IDOR.
+- **SSO CSRF.** The `state` parameter is generated, stored in a cookie as a scrypt digest, and
+  verified and cleared on callback. A provider email matching an existing local account is
+  refused with a `409` rather than auto-linked, which is the takeover this usually is. On
+  email verification: Google checked its flag already and Discord now does too (finding 19);
+  Facebook's Graph API exposes no equivalent, so there is nothing there to check.
+- **Staff permission model.** Root and `unrestricted` short-circuits are consistent; the
+  permission cache has an epoch and is expired explicitly on every role and staff-entry write;
+  granted permissions are filtered against the catalog, so a forged permission key is dropped;
+  dependency chains collapse to stable.
+- **Staff self-edit.** The staff create/edit/delete routes already refuse to let an
+  administrator edit the entry governing their own access, primary or secondary role. That is
+  exactly the guard finding 1 was missing, which is why the gap stood out.
+- **Admin debug module.** Every route carries a specific permission; nothing is left on the
+  session alone.
+- **CORS and CSRF.** `apps/api` passes an explicit origin to both, and credentialed requests
+  are never paired with a wildcard.
+- **Error handling.** Stack traces and messages are returned only in development.
+- **CI.** No `pull_request_target` with a PR-head checkout, and no `${{ github.event.* }}`
+  interpolated into a `run:` block.
+
+---
+
+## Verifying the fixes
+
+```bash
+pnpm install
+cd packages/vitnode && npx vitest run     # 304 files, 6261 tests
+npx tsc -p tsconfig.json --noEmit
+npx eslint .
+```
+
+All green as of this review. 109 tests were added across eight files, each one written
+against the behaviour that was wrong rather than against the fix — the open-redirect test was
+checked by reverting the patch and confirming all five payloads escape the origin, and the
+device test counts inserts so the unauthenticated-row-flood case fails loudly if it returns.
+
+One test's expectations were deliberately changed rather than merely kept passing:
+`admin-permission-parity.test.ts` pins exactly which admin routes declare a permission, and
+finding 23 adds one. That is the test doing its job.
+
+**Three things to do after deploying**, none of which is code:
+
+1. **Set `CRON_SECRET`** to a random value on every install. Finding 2 now fails _closed_, so
+   an install still on the placeholder will find its cron endpoint returning `403` — that is
+   the fix working, and setting the variable is the answer.
+2. **Set `TRUST_PROXY`** if anything sits in front of the app — and on the TanStack Start
+   deployment, effectively always, because that mount has no socket to fall back to
+   (findings 7 and 17). The API warns at boot where it can tell.
+3. **Validate `Host` at the proxy** — nginx `server_name` with a default-server reject, or the
+   platform equivalent. See the `Host` entry under _Not fixed_.
+
+---
+
+## What this review did not cover
+
+Worth stating so the gaps are known rather than assumed away:
+
+- **No running instance.** Everything here is source analysis. The one exception is finding 9,
+  where the redirect behaviour was reproduced directly against the URL parser.
+- **No database.** Findings that depend on live data — the exact blast radius of the queue
+  payload leak, say — are argued from the schema and the query.
+- **No browser.** The XSS and CSWSH findings (8, 6) are argued from how browsers are specified
+  to behave, not from a demonstration.
+- **No dependency CVE scan.** `pnpm audit` was not run; the dependency work here was limited
+  to lifecycle scripts, install sources and CI shape.
+- **Plugins were covered lightly.** `plugins/blog` and `plugins/example` are small and mostly
+  admin-side today. The plugin _isolation_ model — what a hostile plugin could reach — is
+  called out under _Not fixed_ but was not audited as an attack surface in its own right.
diff --git a/apps/api/.env.example b/apps/api/.env.example
index 9726d3cbb..acf200149 100644
--- a/apps/api/.env.example
+++ b/apps/api/.env.example
@@ -9,6 +9,14 @@ NEXT_PUBLIC_WEB_URL=http://localhost:3000
 # storage adapter, so it must match where the server is reachable.
 NEXT_PUBLIC_API_URL=http://localhost:8000
 
+# === Reverse proxies ===
+# Number of proxies in front of this API. Unset = none, and the client address is
+# the socket's - correct when the API is reached directly. Behind
+# nginx/Traefik/Cloudflare, set the real hop count (usually 1) so
+# `X-Forwarded-For` is read; otherwise everyone behind the proxy shares one
+# rate-limit bucket. Too high a number reaches back into client-supplied text.
+# TRUST_PROXY=1
+
 # === CRON Secret for Internal API Calls ===
 CRON_SECRET=your-secure-cron-secret-key
 
diff --git a/apps/api/docker-compose.yml b/apps/api/docker-compose.yml
index 46e8c3f89..c50e79baa 100644
--- a/apps/api/docker-compose.yml
+++ b/apps/api/docker-compose.yml
@@ -13,7 +13,8 @@ services:
     volumes:
       - ../../docker/dev:/var/lib/postgresql/data
     ports:
-      - "5432:5432"
+      # Loopback only - these are development containers with a default password.
+      - "127.0.0.1:5432:5432"
     networks:
       - vitnode_dev
 
@@ -23,7 +24,7 @@ services:
     restart: unless-stopped
     command: redis-server --requirepass ${REDIS_PASSWORD-root}
     ports:
-      - "6379:6379"
+      - "127.0.0.1:6379:6379"
     networks:
       - vitnode_dev
 
diff --git a/apps/api/src/index.ts b/apps/api/src/index.ts
index 5d7ad7916..1b69f74ed 100644
--- a/apps/api/src/index.ts
+++ b/apps/api/src/index.ts
@@ -4,6 +4,8 @@ import { serve, upgradeWebSocket } from "@hono/node-server";
 import { serveStatic } from "@hono/node-server/serve-static";
 import { OpenAPIHono } from "@hono/zod-openapi";
 import { VitNodeAPI } from "@vitnode/core/api/config";
+import { storageStaticHeadersMiddleware } from "@vitnode/core/api/middlewares/storage-static.middleware";
+import { websocketOriginMiddleware } from "@vitnode/core/api/middlewares/websocket-origin.middleware";
 import { handleVitNodeWebSocket } from "@vitnode/core/ws/handle";
 import { mkdirSync } from "node:fs";
 import { WebSocketServer } from "ws";
@@ -24,6 +26,10 @@ if (staticStorage) {
   mkdirSync(staticStorage.root, { recursive: true });
   app.get(
     staticStorage.mountPath,
+    // Stored files are served from this origin - the one the session cookie
+    // belongs to - so anything the browser would treat as a document has to be
+    // stopped from executing in it. See the middleware.
+    storageStaticHeadersMiddleware(),
     serveStatic({
       root: staticStorage.root,
       rewriteRequestPath: path =>
@@ -48,7 +54,14 @@ VitNodeAPI({
 
 const wss = new WebSocketServer({ noServer: true });
 
-app.get("/ws", upgradeWebSocket(handleVitNodeWebSocket()));
+// The handshake is a cookie-authenticated GET, which Hono's `csrf()` does not
+// cover and the same-origin policy does not apply to. Without this any site
+// could open a socket as a visiting user - see the middleware.
+app.get(
+  "/ws",
+  websocketOriginMiddleware({ origin: [webOrigin] }),
+  upgradeWebSocket(handleVitNodeWebSocket()),
+);
 
 serve(
   {
diff --git a/apps/api/src/vitnode.api.config.ts b/apps/api/src/vitnode.api.config.ts
index 46134dd42..df0e57b9c 100644
--- a/apps/api/src/vitnode.api.config.ts
+++ b/apps/api/src/vitnode.api.config.ts
@@ -23,6 +23,19 @@ config({
 export const POSTGRES_URL =
   process.env.POSTGRES_URL ?? "postgresql://root:root@localhost:5432/vitnode";
 
+/**
+ * How many reverse proxies stand in front of this API, from `TRUST_PROXY`.
+ *
+ * Unset means none, and the client address is then the socket's - the only one a
+ * caller cannot choose. Behind nginx, Traefik, Cloudflare or a platform edge,
+ * set `TRUST_PROXY=1` (or the real hop count) so `X-Forwarded-For` is read
+ * instead; otherwise every visitor behind that proxy shares one rate-limit
+ * bucket and the audit trail records the proxy.
+ */
+const trustProxy = process.env.TRUST_PROXY
+  ? Number(process.env.TRUST_PROXY)
+  : undefined;
+
 export const vitNodeApiConfig = buildApiConfig({
   plugins: [blogApiPlugin(), exampleApiPlugin()],
   ai: {
@@ -157,4 +170,5 @@ export const vitNodeApiConfig = buildApiConfig({
     title: "VitNode API",
     shortTitle: "VitNode",
   },
+  trustProxy,
 });
diff --git a/apps/web/.env.example b/apps/web/.env.example
index dad9d0fa0..3d525d6f0 100644
--- a/apps/web/.env.example
+++ b/apps/web/.env.example
@@ -15,6 +15,13 @@ REDIS_URL=redis://localhost:6379
 NEXT_PUBLIC_WEB_URL=http://localhost:3000
 NEXT_PUBLIC_API_URL=http://localhost:3000
 
+# === Reverse proxies ===
+# Number of proxies in front of this app. Unset = none, and the client address is
+# read from the socket. This app serves its API through the Start runtime, which
+# exposes no socket - so behind nginx/Traefik/a platform edge, SET THIS (usually
+# 1), or every visitor shares one rate-limit bucket. The API warns at boot.
+# TRUST_PROXY=1
+
 # === CRON Secret for Internal API Calls ===
 CRON_SECRET=your-secure-cron-secret-key
 
diff --git a/apps/web/src/vitnode.api.config.ts b/apps/web/src/vitnode.api.config.ts
index 09a28ff97..f9cc0f358 100644
--- a/apps/web/src/vitnode.api.config.ts
+++ b/apps/web/src/vitnode.api.config.ts
@@ -26,6 +26,19 @@ export const POSTGRES_URL =
  * them exactly as `apps/api/src/vitnode.api.config.ts` does when this app needs
  * them - `buildApiConfig` treats all of them as optional.
  */
+/**
+ * How many reverse proxies stand in front of this app, from `TRUST_PROXY`.
+ *
+ * Unset means none, and the client address is then the socket's - the only one a
+ * caller cannot choose. Behind nginx, Traefik, Cloudflare or a platform edge,
+ * set `TRUST_PROXY=1` (or the real hop count) so `X-Forwarded-For` is read
+ * instead; otherwise every visitor shares one rate-limit bucket and the audit
+ * trail records the proxy.
+ */
+const trustProxy = process.env.TRUST_PROXY
+  ? Number(process.env.TRUST_PROXY)
+  : undefined
+
 export const vitNodeApiConfig = buildApiConfig({
   plugins: [blogApiPlugin(), exampleApiPlugin()],
   storage: {
@@ -74,4 +87,9 @@ export const vitNodeApiConfig = buildApiConfig({
     title: 'VitNode API',
     shortTitle: 'VitNode',
   },
+  // This mount has no socket to read: the bridge hands Hono a bare `Request`,
+  // so without this every caller resolves to the same fallback address and the
+  // rate limiter degrades to one bucket for the whole site. The API warns at
+  // boot when that is happening.
+  trustProxy,
 })
diff --git a/packages/create-vitnode-app/copy-of-vitnode-app/docker/docker-compose.yml b/packages/create-vitnode-app/copy-of-vitnode-app/docker/docker-compose.yml
index 0af0d0381..67650a851 100644
--- a/packages/create-vitnode-app/copy-of-vitnode-app/docker/docker-compose.yml
+++ b/packages/create-vitnode-app/copy-of-vitnode-app/docker/docker-compose.yml
@@ -12,7 +12,11 @@ services:
     volumes:
       - ./docker/dev:/var/lib/postgresql/data
     ports:
-      - '5432:5432'
+      # Loopback only. These are development containers with a default password
+      # of `root`, and `'5432:5432'` publishes them on every interface the host
+      # has - which on a laptop is whatever café or office network it is joined
+      # to, and on a VPS is the internet.
+      - '127.0.0.1:5432:5432'
     networks:
       - vitnode_dev
 
@@ -22,7 +26,7 @@ services:
     restart: unless-stopped
     command: redis-server --requirepass ${REDIS_PASSWORD-root}
     ports:
-      - '6379:6379'
+      - '127.0.0.1:6379:6379'
     networks:
       - vitnode_dev
 
diff --git a/packages/vitnode/src/api/adapters/search/postgres.ts b/packages/vitnode/src/api/adapters/search/postgres.ts
index 3a4ee863f..29babf00e 100644
--- a/packages/vitnode/src/api/adapters/search/postgres.ts
+++ b/packages/vitnode/src/api/adapters/search/postgres.ts
@@ -73,6 +73,16 @@ const buildFilters = (params: SearchQueryParams): SQL | undefined => {
   return conditions.length ? and(...conditions) : undefined;
 };
 
+/**
+ * The furthest into a relevance-ranked result set a caller may page.
+ *
+ * Relevance ordering has no stable key to seek on, so its cursor is an offset -
+ * and an offset is the one pagination shape whose cost grows with the page
+ * number. Nobody reaches page ten thousand of a search by reading; they reach it
+ * by editing the URL.
+ */
+const MAX_SEARCH_OFFSET = 10_000;
+
 export const PostgresSearchAdapter = (): SearchProviderApiPlugin => ({
   name: "postgres",
   // Two capabilities that are both true for the same reason: this provider's
@@ -126,7 +136,17 @@ export const PostgresSearchAdapter = (): SearchProviderApiPlugin => ({
       ? sql<number>`ts_rank("core_search_index"."search_vector", websearch_to_tsquery(${config}::regconfig, ${term}))`
       : sql<null | number>`NULL`;
 
-    const cursorValue = params.cursor ? Number(params.cursor) : undefined;
+    // Bounded and checked, because on the relevance path this becomes the
+    // query's `OFFSET`. `Number("abc")` is `NaN`, which Postgres rejects as a
+    // 500 rather than a bad request, and an unbounded one is a full scan a
+    // client can ask for by typing a big number into a URL.
+    const parsedCursor = params.cursor ? Number(params.cursor) : undefined;
+    const cursorValue =
+      parsedCursor !== undefined &&
+      Number.isSafeInteger(parsedCursor) &&
+      parsedCursor >= 0
+        ? Math.min(parsedCursor, MAX_SEARCH_OFFSET)
+        : undefined;
 
     const orderBy: SQL[] = [];
     let where = filters;
diff --git a/packages/vitnode/src/api/adapters/sso/discord.ts b/packages/vitnode/src/api/adapters/sso/discord.ts
index c9a650ab3..b03a968e5 100644
--- a/packages/vitnode/src/api/adapters/sso/discord.ts
+++ b/packages/vitnode/src/api/adapters/sso/discord.ts
@@ -20,6 +20,7 @@ export const DiscordSSOApiPlugin = ({
     id: z.string(),
     email: z.string(),
     username: z.string(),
+    verified: z.boolean(),
   });
   const tokenSchema = z.object({
     access_token: z.string(),
@@ -78,6 +79,16 @@ export const DiscordSSOApiPlugin = ({
         });
       }
 
+      // As the Google adapter does. An address Discord has not confirmed is an
+      // address the person signing in may not own, and VitNode keys an account
+      // on it - so accepting one lets somebody register under an address they
+      // cannot read, and hold the account the real owner would have had.
+      if (!data.verified) {
+        throw new HTTPException(400, {
+          message: "Email not verified",
+        });
+      }
+
       return data;
     },
     getUrl: ({ state }) => {
diff --git a/packages/vitnode/src/api/config.ts b/packages/vitnode/src/api/config.ts
index b3c54d4d0..09b90a8e7 100644
--- a/packages/vitnode/src/api/config.ts
+++ b/packages/vitnode/src/api/config.ts
@@ -2,6 +2,7 @@ import type { OpenAPIHono } from "@hono/zod-openapi";
 import type { Context, Env, Schema } from "hono";
 
 import { swaggerUI } from "@hono/swagger-ui";
+import { bodyLimit } from "hono/body-limit";
 import { cors } from "hono/cors";
 import { csrf } from "hono/csrf";
 import { HTTPException } from "hono/http-exception";
@@ -9,10 +10,12 @@ import { HTTPException } from "hono/http-exception";
 import type { VitNodeApiConfig } from "@/vitnode.config";
 
 import { createCacheClient } from "@/api/lib/cache-client";
+import { clientIpMiddleware } from "@/api/lib/client-ip";
 import { collectCronJobs } from "@/api/lib/cron";
 import { describeError } from "@/api/lib/error-details";
 import { newBuildPluginApiCore } from "@/api/plugin";
 import { CONFIG_PLUGIN } from "@/config";
+import { CONFIG } from "@/lib/config";
 import { initRealtimePubSub } from "@/ws/registry";
 
 import {
@@ -22,6 +25,9 @@ import {
 import { rateLimiterMiddleware } from "./middlewares/rate-limiter.middleware";
 import { registerCronJobs } from "./modules/cron/helpers/register-cron-jobs";
 
+/** 25 MB: room for an image upload, and nothing like enough to be a weapon. */
+const DEFAULT_MAX_BODY_SIZE = 25 * 1024 * 1024;
+
 interface CORSOptions {
   allowHeaders?: string[];
   allowMethods?: string[];
@@ -62,23 +68,51 @@ export function VitNodeAPI({
 
   const plugins = [newBuildPluginApiCore, ...vitNodeApiConfig.plugins];
 
-  app.doc("/swagger/doc", {
-    openapi: "3.0.0",
-    info: {
-      version: CONFIG_PLUGIN.version,
-      title: "VitNode API",
-    },
-    tags: plugins.flatMap(
-      plugin => plugin.openApiTags?.map(name => ({ name })) ?? [],
-    ),
-  });
+  // The generated document names every route, parameter and response shape in
+  // the install, including the admin tree - a map of the attack surface, handed
+  // out unauthenticated. Published in development, where it is the point, and
+  // in production only when an install asks for it via `docs: { enabled: true }`.
+  const docsEnabled = vitNodeApiConfig.docs?.enabled ?? CONFIG.node_development;
+
+  if (docsEnabled) {
+    app.doc("/swagger/doc", {
+      openapi: "3.0.0",
+      info: {
+        version: CONFIG_PLUGIN.version,
+        title: "VitNode API",
+      },
+      tags: plugins.flatMap(
+        plugin => plugin.openApiTags?.map(name => ({ name })) ?? [],
+      ),
+    });
+  }
+
   app.use(cors(corsOptions));
   app.use(csrf(csrfOptions));
+  // Before the rate limiter, which keys its buckets on `ipAddress`. Resolving it
+  // later - as `globalMiddleware` used to - left every request in the
+  // deployment sharing one bucket named after `undefined`.
+  app.use("*", clientIpMiddleware(vitNodeApiConfig.trustProxy));
+  // Nothing bounded a request body before this. `POST /sign_in` reads its JSON
+  // and then runs scrypt unconditionally, so a body the server is willing to
+  // buffer is memory *and* CPU an unauthenticated caller gets to choose the size
+  // of. Uploads are the one thing that legitimately needs room, and they are
+  // bounded per field by the Content Engine's own `maxBytes`; this is the outer
+  // wall, and `maxBodySize` moves it for an install that stores large media.
+  app.use(
+    "*",
+    bodyLimit({
+      maxSize: vitNodeApiConfig.maxBodySize ?? DEFAULT_MAX_BODY_SIZE,
+      onError: c => c.json({ error: "Payload Too Large" }, 413),
+    }),
+  );
   app.use(
     "*",
     rateLimiterMiddleware(vitNodeApiConfig.rateLimiter, redisClient),
   );
-  app.get("/swagger", swaggerUI({ url: "/api/swagger/doc" }));
+  if (docsEnabled) {
+    app.get("/swagger", swaggerUI({ url: "/api/swagger/doc" }));
+  }
   app.use(
     "*",
     globalMiddleware({
@@ -96,6 +130,7 @@ export function VitNodeAPI({
       storage: vitNodeApiConfig.storage,
       plugins,
       cacheClient: redisClient,
+      trustProxy: vitNodeApiConfig.trustProxy,
     }),
   );
   app.use(async (c, next) => {
diff --git a/packages/vitnode/src/api/lib/auth-cookie.ts b/packages/vitnode/src/api/lib/auth-cookie.ts
index f426a8a5e..f5b4af317 100644
--- a/packages/vitnode/src/api/lib/auth-cookie.ts
+++ b/packages/vitnode/src/api/lib/auth-cookie.ts
@@ -33,6 +33,14 @@ const authCookieOptions = (c: Context): CookieOptions => {
     domain: cookieDomain,
     httpOnly: true,
     path: "/",
+    // Stated rather than left to the browser. Chrome and Firefox default an
+    // omitted `SameSite` to `Lax`, but that is a default and not a rule: Safari
+    // and older engines have their own, and a cookie whose cross-site behaviour
+    // depends on which browser is reading it is one nobody can reason about.
+    // `Lax` and not `Strict` because the SSO round trip lands here as a
+    // top-level cross-site GET - `Strict` would drop the state cookie on the way
+    // back from the provider and break every social sign-in.
+    sameSite: "Lax",
     secure: cookieSecure,
   };
 };
diff --git a/packages/vitnode/src/api/lib/client-ip.test.ts b/packages/vitnode/src/api/lib/client-ip.test.ts
new file mode 100644
index 000000000..8f3c1b732
--- /dev/null
+++ b/packages/vitnode/src/api/lib/client-ip.test.ts
@@ -0,0 +1,176 @@
+import { Hono } from "hono";
+import { describe, expect, it } from "vitest";
+
+import type { TrustProxyConfig } from "./client-ip";
+
+import { clientIpMiddleware } from "./client-ip";
+
+interface Env {
+  Variables: { ipAddress: string };
+}
+
+/**
+ * Runs one request through the middleware and reports the address it settled
+ * on. `socket` stands in for the runtime's connection info, in the shape
+ * `@hono/node-server` exposes it.
+ */
+const resolve = async ({
+  headers,
+  socket,
+  trustProxy,
+}: {
+  headers?: Record<string, string>;
+  socket?: string;
+  trustProxy?: TrustProxyConfig;
+}): Promise<string> => {
+  const app = new Hono<Env>();
+  app.use("*", clientIpMiddleware(trustProxy));
+  app.get("/", c => c.text(c.get("ipAddress")));
+
+  const res = await app.request(
+    "/",
+    { headers },
+    socket === undefined
+      ? undefined
+      : { incoming: { socket: { remoteAddress: socket } } },
+  );
+
+  return await res.text();
+};
+
+describe("clientIpMiddleware", () => {
+  describe("with no proxy configured", () => {
+    it("uses the socket address", async () => {
+      await expect(resolve({ socket: "203.0.113.7" })).resolves.toBe(
+        "203.0.113.7",
+      );
+    });
+
+    it("ignores a forwarded header entirely", async () => {
+      // The regression this guards: the old resolver walked sixteen
+      // client-settable headers and took the first one present, so any caller
+      // could name themselves and get a fresh rate-limit bucket per request.
+      await expect(
+        resolve({
+          socket: "203.0.113.7",
+          headers: { "x-forwarded-for": "9.9.9.9" },
+        }),
+      ).resolves.toBe("203.0.113.7");
+    });
+
+    it.each([
+      "x-real-ip",
+      "cf-connecting-ip",
+      "true-client-ip",
+      "client-ip",
+      "forwarded",
+    ])("ignores %s", async header => {
+      await expect(
+        resolve({ socket: "203.0.113.7", headers: { [header]: "9.9.9.9" } }),
+      ).resolves.toBe("203.0.113.7");
+    });
+
+    it("falls back to localhost when the runtime exposes no socket", async () => {
+      await expect(resolve({})).resolves.toBe("127.0.0.1");
+    });
+  });
+
+  describe("behind one proxy", () => {
+    it("reads the address the proxy observed", async () => {
+      await expect(
+        resolve({
+          trustProxy: true,
+          socket: "10.0.0.1",
+          headers: { "x-forwarded-for": "203.0.113.7" },
+        }),
+      ).resolves.toBe("203.0.113.7");
+    });
+
+    it("steps over an address the client forged", async () => {
+      // The client sent `9.9.9.9`; the proxy appended what it actually saw. One
+      // hop means one entry from the right, which is the proxy's word and not
+      // the client's.
+      await expect(
+        resolve({
+          trustProxy: true,
+          socket: "10.0.0.1",
+          headers: { "x-forwarded-for": "9.9.9.9, 203.0.113.7" },
+        }),
+      ).resolves.toBe("203.0.113.7");
+    });
+
+    it("survives a forged chain of any length", async () => {
+      const forged = Array.from({ length: 20 }, (_, i) => `9.9.9.${i}`).join(
+        ", ",
+      );
+
+      await expect(
+        resolve({
+          trustProxy: 1,
+          socket: "10.0.0.1",
+          headers: { "x-forwarded-for": `${forged}, 203.0.113.7` },
+        }),
+      ).resolves.toBe("203.0.113.7");
+    });
+
+    it("falls back to the socket when the proxy sent no header", async () => {
+      await expect(
+        resolve({ trustProxy: true, socket: "10.0.0.1" }),
+      ).resolves.toBe("10.0.0.1");
+    });
+  });
+
+  describe("behind two proxies", () => {
+    it("reads past both of them", async () => {
+      await expect(
+        resolve({
+          trustProxy: 2,
+          socket: "10.0.0.1",
+          headers: { "x-forwarded-for": "203.0.113.7, 198.51.100.4" },
+        }),
+      ).resolves.toBe("203.0.113.7");
+    });
+
+    it("steps over a forgery, still", async () => {
+      await expect(
+        resolve({
+          trustProxy: 2,
+          socket: "10.0.0.1",
+          headers: {
+            "x-forwarded-for": "9.9.9.9, 203.0.113.7, 198.51.100.4",
+          },
+        }),
+      ).resolves.toBe("203.0.113.7");
+    });
+
+    it("takes the leftmost entry when the chain is shorter than the hop count", async () => {
+      await expect(
+        resolve({
+          trustProxy: 5,
+          socket: "10.0.0.1",
+          headers: { "x-forwarded-for": "203.0.113.7" },
+        }),
+      ).resolves.toBe("203.0.113.7");
+    });
+  });
+
+  it("trims whitespace around chain entries", async () => {
+    await expect(
+      resolve({
+        trustProxy: true,
+        socket: "10.0.0.1",
+        headers: { "x-forwarded-for": "  203.0.113.7  " },
+      }),
+    ).resolves.toBe("203.0.113.7");
+  });
+
+  it("ignores empty entries in the chain", async () => {
+    await expect(
+      resolve({
+        trustProxy: true,
+        socket: "10.0.0.1",
+        headers: { "x-forwarded-for": "203.0.113.7, , " },
+      }),
+    ).resolves.toBe("203.0.113.7");
+  });
+});
diff --git a/packages/vitnode/src/api/lib/client-ip.ts b/packages/vitnode/src/api/lib/client-ip.ts
new file mode 100644
index 000000000..de78418f5
--- /dev/null
+++ b/packages/vitnode/src/api/lib/client-ip.ts
@@ -0,0 +1,159 @@
+import type { Context } from "hono";
+
+/**
+ * How many reverse proxies sit between the internet and this API, or `false`
+ * when it is reached directly.
+ *
+ * `true` is shorthand for one hop, which is the ordinary "nginx / Traefik /
+ * platform edge in front of the app" deployment.
+ */
+export type TrustProxyConfig = boolean | number;
+
+/**
+ * Used when neither the socket nor a trusted header can name the peer - a test
+ * harness, or a runtime that exposes no connection info at all.
+ */
+const UNKNOWN_CLIENT_IP = "127.0.0.1";
+
+/**
+ * The peer address of the TCP connection, read from whichever runtime is
+ * hosting the app.
+ *
+ * This is the only address a client cannot choose for itself, which is what
+ * makes it the base case: every header below is something the *sender* wrote.
+ * Each runtime exposes it somewhere different and none of them are typed on
+ * `Context`, so the shapes are probed rather than imported - importing
+ * `@hono/node-server/conninfo` here would tie this package to Node and break
+ * the Bun and edge entry points.
+ */
+const socketAddress = (c: Context): string | undefined => {
+  const env: unknown = c.env;
+  if (typeof env !== "object" || env === null) return undefined;
+
+  // Node (`@hono/node-server`): the raw `IncomingMessage`.
+  const incoming = (env as { incoming?: unknown }).incoming;
+  if (typeof incoming === "object" && incoming !== null) {
+    const socket = (incoming as { socket?: unknown }).socket;
+    if (typeof socket === "object" && socket !== null) {
+      const address = (socket as { remoteAddress?: unknown }).remoteAddress;
+      if (typeof address === "string" && address.length > 0) return address;
+    }
+  }
+
+  // Bun: `server.requestIP(request)`.
+  const server = (env as { server?: unknown }).server;
+  if (typeof server === "object" && server !== null) {
+    const requestIP = (server as { requestIP?: unknown }).requestIP;
+    if (typeof requestIP === "function") {
+      const info: unknown = (
+        requestIP as (request: Request) => null | { address?: unknown }
+      )(c.req.raw);
+      const address =
+        typeof info === "object" && info !== null
+          ? (info as { address?: unknown }).address
+          : undefined;
+      if (typeof address === "string" && address.length > 0) return address;
+    }
+  }
+
+  // Deno: `Deno.ServeHandlerInfo`.
+  const remoteAddr = (env as { remoteAddr?: unknown }).remoteAddr;
+  if (typeof remoteAddr === "object" && remoteAddr !== null) {
+    const hostname = (remoteAddr as { hostname?: unknown }).hostname;
+    if (typeof hostname === "string" && hostname.length > 0) return hostname;
+  }
+
+  return undefined;
+};
+
+/**
+ * The address of the client that made this request.
+ *
+ * ## Why the headers are not simply read
+ *
+ * `X-Forwarded-For` and its sixteen cousins are request headers, so anybody can
+ * send any of them. Taking the first one present - which is what this used to do
+ * - hands every caller a free hand in choosing their own identity, and the two
+ * things that identity is *for* are the rate limiter's bucket key and the audit
+ * trail on a password-reset row. A limiter keyed on a value the attacker picks
+ * is not a limiter, and a reset email that reports "requested from 1.2.3.4"
+ * because the requester said so is worse than one that reports nothing.
+ *
+ * So the socket address is the default, and a forwarded header is read **only**
+ * when the install says it is behind a proxy, via `security.trustProxy`.
+ *
+ * ## Why it counts from the right
+ *
+ * A proxy *appends* the address it saw to `X-Forwarded-For`, so the chain reads
+ * oldest-first and the rightmost entry is the one written by the proxy closest
+ * to this server - the only entry in the list that a trusted machine vouched
+ * for. Anything the client sent arrives to its left, still in the header,
+ * indistinguishable from a real hop by content alone.
+ *
+ * Counting `hops` from the right is what makes that survivable. Behind one
+ * proxy, a client sending `X-Forwarded-For: 9.9.9.9` produces
+ * `9.9.9.9, <real client>` once the proxy appends, and the entry one from the
+ * right is the real client - the forgery is still in the header and is
+ * deliberately stepped over. Reading the leftmost entry instead would return
+ * `9.9.9.9`, which is the bug this shape exists to prevent.
+ */
+export const resolveClientIp = (
+  c: Context,
+  trustProxy: TrustProxyConfig | undefined,
+): string => {
+  const socket = socketAddress(c);
+
+  if (!trustProxy) return socket ?? UNKNOWN_CLIENT_IP;
+
+  const hops = trustProxy === true ? 1 : Math.max(1, Math.trunc(trustProxy));
+  const chain = (c.req.header("x-forwarded-for") ?? "")
+    .split(",")
+    .map(entry => entry.trim())
+    .filter(entry => entry.length > 0);
+
+  if (chain.length === 0) return socket ?? UNKNOWN_CLIENT_IP;
+
+  // A chain shorter than the configured hop count means a proxy did not append
+  // what it was expected to. The leftmost entry is then the least-worst answer,
+  // and it is still bounded by however many proxies really did write to it.
+  const index = Math.max(0, chain.length - hops);
+
+  return chain[index] ?? socket ?? UNKNOWN_CLIENT_IP;
+};
+
+/**
+ * Sets `ipAddress` for the rest of the request.
+ *
+ * Registered **before** the rate limiter rather than inside `globalMiddleware`,
+ * because the limiter reads `ipAddress` to build its bucket key and Hono runs
+ * middleware in registration order: resolving it later left the limiter keying
+ * every request in the deployment on `undefined`, i.e. one shared bucket for the
+ * whole site.
+ */
+export const clientIpMiddleware = (
+  trustProxy: TrustProxyConfig | undefined,
+) => {
+  let warned = false;
+
+  return async (c: Context, next: () => Promise<void>) => {
+    const ipAddress = resolveClientIp(c, trustProxy);
+
+    // Some hosts hand Hono a bare `Request` with no connection info at all - the
+    // TanStack Start mount calls `app.fetch(request)` directly, and there is no
+    // socket behind it. Without a socket *and* without `trustProxy`, every
+    // caller resolves to the same fallback, which quietly turns the rate limiter
+    // back into one shared bucket for the whole site. That is worth saying out
+    // loud once, because nothing else about it is visible.
+    if (!warned && !trustProxy && !socketAddress(c)) {
+      warned = true;
+      // eslint-disable-next-line no-console
+      console.warn(
+        `\x1b[34m[VitNode]\x1b[0m \x1b[33mCannot see the client's address:\x1b[0m this runtime exposes no connection info, so every request is being rate-limited as ${UNKNOWN_CLIENT_IP}. Set \`trustProxy\` in the API config to the number of proxies in front of this app so \`X-Forwarded-For\` is read instead.`,
+      );
+    }
+
+    c.set("ipAddress", ipAddress);
+
+    await next();
+  };
+};
diff --git a/packages/vitnode/src/api/middlewares/captcha.middleware.ts b/packages/vitnode/src/api/middlewares/captcha.middleware.ts
index 09628d4c5..40a0cc947 100644
--- a/packages/vitnode/src/api/middlewares/captcha.middleware.ts
+++ b/packages/vitnode/src/api/middlewares/captcha.middleware.ts
@@ -13,13 +13,22 @@ const getResFromReCaptcha = async ({
   token: string;
   userIp: string;
 }): Promise<{ "error-codes"?: string[]; score: number; success: boolean }> => {
+  // An install that configured a captcha but no secret key cannot verify
+  // anything. Said here rather than left to the provider to reject a malformed
+  // request: the answer is the same either way, but only one of them is a
+  // decision this code made on purpose.
+  const { secretKey } = captchaConfig;
+  if (!secretKey) {
+    return { success: false, score: 0, "error-codes": ["missing-secret-key"] };
+  }
+
   if (captchaConfig.type === "cloudflare_turnstile") {
     const res = await fetch(
       "https://challenges.cloudflare.com/turnstile/v0/siteverify",
       {
         method: "POST",
         body: JSON.stringify({
-          secret: captchaConfig.secretKey,
+          secret: secretKey,
           response: token,
           remoteip: userIp,
         }),
@@ -41,12 +50,22 @@ const getResFromReCaptcha = async ({
     };
   }
   if (captchaConfig.type === "recaptcha_v3") {
-    const res = await fetch(
-      `https://www.google.com/recaptcha/api/siteverify?secret=${captchaConfig.secretKey}&response=${token}&remoteip=${userIp}`,
-      {
-        method: "POST",
+    // Form-encoded body rather than a query string. Interpolating the
+    // client-supplied token straight into the URL let it carry `&` and add
+    // parameters of its own to the request - and it put the site's secret key in
+    // a URL, which is the part of a request that ends up in proxy logs and
+    // error reports.
+    const res = await fetch("https://www.google.com/recaptcha/api/siteverify", {
+      method: "POST",
+      headers: {
+        "Content-Type": "application/x-www-form-urlencoded",
       },
-    );
+      body: new URLSearchParams({
+        secret: secretKey,
+        response: token,
+        remoteip: userIp,
+      }),
+    });
 
     const data: {
       "error-codes"?: string[];
diff --git a/packages/vitnode/src/api/middlewares/cron-auth.middleware.test.ts b/packages/vitnode/src/api/middlewares/cron-auth.middleware.test.ts
new file mode 100644
index 000000000..f363ccf42
--- /dev/null
+++ b/packages/vitnode/src/api/middlewares/cron-auth.middleware.test.ts
@@ -0,0 +1,124 @@
+import { Hono } from "hono";
+import { afterEach, beforeEach, describe, expect, it, vi } from "vitest";
+
+import {
+  INSECURE_CRON_SECRETS,
+  INSECURE_DEFAULT_CRON_SECRET,
+} from "@/lib/config";
+
+import { cronAuthMiddleware } from "./cron-auth.middleware";
+
+interface Env {
+  Variables: { core: { cronSecret?: string } };
+}
+
+const buildApp = (cronSecret: string | undefined) => {
+  const app = new Hono<Env>();
+  app.use("*", async (c, next) => {
+    c.set("core", { cronSecret });
+
+    return next();
+  });
+  app.use("*", cronAuthMiddleware());
+  app.post("/", c => c.text("ran"));
+
+  return app;
+};
+
+const post = async (
+  cronSecret: string | undefined,
+  authorization?: string,
+): Promise<Response> =>
+  await buildApp(cronSecret).request("/", {
+    method: "POST",
+    headers: authorization === undefined ? {} : { authorization },
+  });
+
+describe("cronAuthMiddleware", () => {
+  beforeEach(() => {
+    vi.stubEnv("NODE_ENV", "production");
+  });
+
+  afterEach(() => {
+    vi.unstubAllEnvs();
+  });
+
+  it("runs the job for the configured secret", async () => {
+    const res = await post("s3cret-value", "Bearer s3cret-value");
+
+    expect(res.status).toBe(200);
+  });
+
+  it("refuses a wrong secret", async () => {
+    const res = await post("s3cret-value", "Bearer wrong");
+
+    expect(res.status).toBe(403);
+  });
+
+  it("refuses a missing authorization header", async () => {
+    const res = await post("s3cret-value");
+
+    expect(res.status).toBe(403);
+  });
+
+  it("refuses when no secret is configured at all", async () => {
+    const res = await post(undefined, "Bearer anything");
+
+    expect(res.status).toBe(403);
+  });
+
+  describe("the built-in default secret", () => {
+    it("is refused in production", async () => {
+      // The regression this guards: `CONFIG.cronJobSecret` falls back to a
+      // constant published in this repository, so an install that never set
+      // `CRON_SECRET` would run every registered cron job for anyone who read
+      // the source.
+      const res = await post(
+        INSECURE_DEFAULT_CRON_SECRET,
+        `Bearer ${INSECURE_DEFAULT_CRON_SECRET}`,
+      );
+
+      expect(res.status).toBe(403);
+      expect(await res.text()).toContain("CRON_SECRET");
+    });
+
+    it.each([...INSECURE_CRON_SECRETS])(
+      "refuses the published placeholder %s in production",
+      async secret => {
+        // The `.env.example` the scaffolder ships carries its own placeholder,
+        // so recognising only the code fallback left every install that copied
+        // that file and never edited the line just as open.
+        const res = await post(secret, `Bearer ${secret}`);
+
+        expect(res.status).toBe(403);
+      },
+    );
+
+    it("still works in development", async () => {
+      vi.stubEnv("NODE_ENV", "development");
+      const res = await post(
+        INSECURE_DEFAULT_CRON_SECRET,
+        `Bearer ${INSECURE_DEFAULT_CRON_SECRET}`,
+      );
+
+      expect(res.status).toBe(200);
+    });
+  });
+
+  describe("header parsing", () => {
+    it("does not accept `Bearer` appearing mid-header", async () => {
+      // `authHeader.replace("Bearer ", "")` used to strip the first occurrence
+      // wherever it sat, so this parsed as the secret.
+      const res = await post("s3cret-value", "Basic Bearer s3cret-value");
+
+      expect(res.status).toBe(403);
+    });
+
+    it("does not mangle a secret containing the scheme name", async () => {
+      const secret = "a Bearer b";
+      const res = await post(secret, `Bearer ${secret}`);
+
+      expect(res.status).toBe(200);
+    });
+  });
+});
diff --git a/packages/vitnode/src/api/middlewares/cron-auth.middleware.ts b/packages/vitnode/src/api/middlewares/cron-auth.middleware.ts
index 556f4b705..29c05d920 100644
--- a/packages/vitnode/src/api/middlewares/cron-auth.middleware.ts
+++ b/packages/vitnode/src/api/middlewares/cron-auth.middleware.ts
@@ -1,6 +1,44 @@
 import type { Context, Next } from "hono";
 
 import { HTTPException } from "hono/http-exception";
+import { timingSafeEqual } from "node:crypto";
+
+import { CONFIG, INSECURE_CRON_SECRETS } from "@/lib/config";
+
+/**
+ * Constant-time comparison of two secrets.
+ *
+ * `timingSafeEqual` throws on a length mismatch, so the lengths are compared
+ * first - and then both branches still run a comparison, because returning
+ * early on a length difference is itself a signal about the secret.
+ */
+const secretsMatch = (provided: string, expected: string): boolean => {
+  const a = Buffer.from(provided, "utf8");
+  const b = Buffer.from(expected, "utf8");
+
+  if (a.length !== b.length) {
+    timingSafeEqual(b, b);
+
+    return false;
+  }
+
+  return timingSafeEqual(a, b);
+};
+
+/**
+ * `Bearer <secret>`, or nothing.
+ *
+ * Matched as a *prefix* rather than stripped with `replace`, which removed the
+ * first `"Bearer "` found anywhere in the header - so `"x Bearer y"` parsed as a
+ * credential, and a secret that happened to contain the word lost part of
+ * itself.
+ */
+const bearerToken = (header: string | undefined): string | undefined => {
+  if (!header) return undefined;
+  const match = /^Bearer (.+)$/.exec(header);
+
+  return match?.[1];
+};
 
 export const cronAuthMiddleware = () => {
   return async (c: Context, next: Next) => {
@@ -9,10 +47,25 @@ export const cronAuthMiddleware = () => {
       throw new HTTPException(403, { message: "Cron access not configured" });
     }
 
-    const authHeader = c.req.header("authorization");
-    const providedSecret = authHeader?.replace("Bearer ", "");
+    // `CONFIG.cronJobSecret` falls back to a published constant so that a fresh
+    // checkout runs its cron jobs without configuration. Outside development
+    // that fallback is not a weak secret, it is *no* secret: the value is in the
+    // repository, so anyone could post to this endpoint and run every registered
+    // job. The admin panel flags it, but a warning nobody reads is not a control,
+    // so production refuses the request outright.
+    if (
+      INSECURE_CRON_SECRETS.includes(cronSecret) &&
+      !CONFIG.node_development
+    ) {
+      throw new HTTPException(403, {
+        message:
+          "Cron access is disabled because CRON_SECRET is still the built-in default. Set CRON_SECRET to a random value.",
+      });
+    }
+
+    const providedSecret = bearerToken(c.req.header("authorization"));
 
-    if (providedSecret !== cronSecret) {
+    if (!providedSecret || !secretsMatch(providedSecret, cronSecret)) {
       throw new HTTPException(403, { message: "Invalid cron authorization" });
     }
 
diff --git a/packages/vitnode/src/api/middlewares/global.middleware.ts b/packages/vitnode/src/api/middlewares/global.middleware.ts
index cdf2f15d6..157fcd3e3 100644
--- a/packages/vitnode/src/api/middlewares/global.middleware.ts
+++ b/packages/vitnode/src/api/middlewares/global.middleware.ts
@@ -34,6 +34,7 @@ import { collectLocaleCodes } from "@/lib/i18n/load-messages";
 import { buildApiMessagesSources } from "@/lib/i18n/sources";
 import { realtime } from "@/ws/registry";
 
+import type { TrustProxyConfig } from "../lib/client-ip";
 import type { BuildCronReturn } from "../lib/cron";
 import type { EventListenerConfig } from "../lib/events";
 import type { PermissionStaffCatalogEntry } from "../lib/permission-staff";
@@ -46,6 +47,7 @@ import type {
 } from "../models/search";
 import type { SSOApiPlugin } from "../models/sso";
 
+import { resolveClientIp } from "../lib/client-ip";
 import { collectCronJobs } from "../lib/cron";
 import {
   loggerMiddleware,
@@ -182,6 +184,7 @@ export const globalMiddleware = ({
   search,
   storage,
   cacheClient,
+  trustProxy,
 }: Pick<
   VitNodeApiConfig,
   | "ai"
@@ -197,7 +200,10 @@ export const globalMiddleware = ({
   | "search"
   | "storage"
 > &
-  Pick<VitNodeConfig, "metadata"> & { cacheClient: CacheClient | null }) => {
+  Pick<VitNodeConfig, "metadata"> & {
+    cacheClient: CacheClient | null;
+    trustProxy: TrustProxyConfig | undefined;
+  }) => {
   const pluginsMetadata = plugins.map(plugin => ({
     id: plugin.pluginId,
   }));
@@ -324,38 +330,14 @@ export const globalMiddleware = ({
     }),
   );
 
-  const ipHeaderKeys = [
-    "x-forwarded-for",
-    "x-real-ip",
-    "cf-connecting-ip",
-    "x-client-ip",
-    "x-forwarded",
-    "x-cluster-client-ip",
-    "forwarded-for",
-    "forwarded",
-    "via",
-    "remote-addr",
-    "client-ip",
-    "ip",
-    "x-ip",
-    "true-client-ip",
-    "fastly-client-ip",
-    "x-fastly-client-ip",
-  ];
-
   return async (c: Context, next: Next) => {
-    let ipAddress: string | undefined;
-
-    for (const key of ipHeaderKeys) {
-      ipAddress = c.req.header(key);
-      if (ipAddress) break;
-
-      ipAddress = c.req.raw.headers.get(key) ?? undefined;
-      if (ipAddress) break;
+    // Normally already resolved by `clientIpMiddleware`, which `VitNodeAPI`
+    // registers ahead of the rate limiter. Repeated here only so that composing
+    // this middleware by hand still yields an `ipAddress`, rather than leaving
+    // an `undefined` one to be used silently as a rate-limit key.
+    if (!c.get("ipAddress")) {
+      c.set("ipAddress", resolveClientIp(c, trustProxy));
     }
-
-    // Fallback to localhost if nothing found
-    c.set("ipAddress", ipAddress ?? "127.0.0.1");
     c.set("db", dbProvider);
     c.set("ai", new AIModel(c));
     c.set("cache", new CacheModel(cacheClient, c));
diff --git a/packages/vitnode/src/api/middlewares/storage-static.middleware.ts b/packages/vitnode/src/api/middlewares/storage-static.middleware.ts
new file mode 100644
index 000000000..73530f871
--- /dev/null
+++ b/packages/vitnode/src/api/middlewares/storage-static.middleware.ts
@@ -0,0 +1,33 @@
+import type { Context, Next } from "hono";
+
+/**
+ * Headers for the route that serves stored uploads off disk.
+ *
+ * Uploads are served from the API's own origin, which is the origin the session
+ * cookie belongs to. That makes any stored file the browser is willing to treat
+ * as a *document* - HTML, an SVG carrying a `<script>` - a page on the site
+ * rather than an attachment on it, able to read the signed-in visitor's API as
+ * them. `safeStorageExtension` stops a file being written under an extension its
+ * media type does not justify, and this is the other half: whatever does end up
+ * stored, it does not execute in this origin.
+ *
+ * - `Content-Security-Policy: sandbox` drops the response into an opaque origin
+ *   when it is navigated to, so script in it has no cookies, no same-origin API
+ *   and no storage. It applies only to documents, so an image fetched by an
+ *   `<img>` tag is completely unaffected - including an SVG, which never runs
+ *   script through that path anyway.
+ * - `X-Content-Type-Options: nosniff` stops the browser deciding for itself that
+ *   something declared `image/png` is really HTML.
+ *
+ * Deliberately no `Cross-Origin-Resource-Policy`: VitNode supports the web app
+ * and the API on separate origins, and `same-origin` there would blank every
+ * uploaded image on the site.
+ */
+export const storageStaticHeadersMiddleware = () => {
+  return async (c: Context, next: Next) => {
+    await next();
+
+    c.header("Content-Security-Policy", "sandbox");
+    c.header("X-Content-Type-Options", "nosniff");
+  };
+};
diff --git a/packages/vitnode/src/api/middlewares/websocket-origin.middleware.test.ts b/packages/vitnode/src/api/middlewares/websocket-origin.middleware.test.ts
new file mode 100644
index 000000000..35bc02e3e
--- /dev/null
+++ b/packages/vitnode/src/api/middlewares/websocket-origin.middleware.test.ts
@@ -0,0 +1,91 @@
+import { Hono } from "hono";
+import { afterEach, beforeEach, describe, expect, it, vi } from "vitest";
+
+import { websocketOriginMiddleware } from "./websocket-origin.middleware";
+
+const upgrade = async (
+  origin: string | undefined,
+  options?: { origin?: string[] },
+): Promise<Response> => {
+  const app = new Hono();
+  app.get("/ws", websocketOriginMiddleware(options), c => c.text("upgraded"));
+
+  return await app.request(
+    "/ws",
+    origin === undefined ? {} : { headers: { origin } },
+  );
+};
+
+describe("websocketOriginMiddleware", () => {
+  beforeEach(() => {
+    vi.stubEnv("NEXT_PUBLIC_WEB_URL", "https://web.example");
+    vi.stubEnv("NEXT_PUBLIC_API_URL", "https://api.example");
+  });
+
+  afterEach(() => {
+    vi.unstubAllEnvs();
+  });
+
+  it("allows the configured web origin", async () => {
+    const res = await upgrade("https://web.example");
+
+    expect(res.status).toBe(200);
+  });
+
+  it("allows the configured API origin", async () => {
+    const res = await upgrade("https://api.example");
+
+    expect(res.status).toBe(200);
+  });
+
+  it("allows an extra origin the app passes in", async () => {
+    const res = await upgrade("https://admin.example", {
+      origin: ["https://admin.example"],
+    });
+
+    expect(res.status).toBe(200);
+  });
+
+  it("refuses another site", async () => {
+    // The attack: `evil.example` opens `wss://api.example/ws`, the browser
+    // attaches the visitor's session cookie because the same-origin policy does
+    // not govern WebSockets, and the socket is registered as that visitor.
+    const res = await upgrade("https://evil.example");
+
+    expect(res.status).toBe(403);
+  });
+
+  it("refuses a look-alike prefix", async () => {
+    const res = await upgrade("https://web.example.evil.example");
+
+    expect(res.status).toBe(403);
+  });
+
+  it("refuses the right host on the wrong scheme", async () => {
+    const res = await upgrade("http://web.example");
+
+    expect(res.status).toBe(403);
+  });
+
+  it("refuses the right host on a different port", async () => {
+    const res = await upgrade("https://web.example:8443");
+
+    expect(res.status).toBe(403);
+  });
+
+  it("allows a handshake with no Origin at all", async () => {
+    // Browsers always send one, so this is a non-browser client - which carries
+    // no ambient cookies to be ridden.
+    const res = await upgrade(undefined);
+
+    expect(res.status).toBe(200);
+  });
+
+  it("normalises a configured origin given as a full URL", async () => {
+    const res = await upgrade("https://admin.example", {
+      origin: ["https://admin.example/admin/"],
+    });
+
+    expect(res.status).toBe(200);
+  });
+});
diff --git a/packages/vitnode/src/api/middlewares/websocket-origin.middleware.ts b/packages/vitnode/src/api/middlewares/websocket-origin.middleware.ts
new file mode 100644
index 000000000..747f4b962
--- /dev/null
+++ b/packages/vitnode/src/api/middlewares/websocket-origin.middleware.ts
@@ -0,0 +1,73 @@
+import type { Context, Next } from "hono";
+
+import { HTTPException } from "hono/http-exception";
+
+import { CONFIG } from "@/lib/config";
+
+/** `https://example.com/api/` -> `https://example.com`, or undefined. */
+const originOf = (value: string | undefined): string | undefined => {
+  if (!value) return undefined;
+
+  try {
+    return new URL(value).origin;
+  } catch {
+    return undefined;
+  }
+};
+
+/**
+ * Refuses a WebSocket upgrade from an origin this install does not serve.
+ *
+ * ## Why a WebSocket needs its own check
+ *
+ * The same-origin policy does not apply to `new WebSocket(...)`. Any page on the
+ * internet may open a socket to any host, and the browser attaches that host's
+ * cookies to the handshake exactly as it would for a same-site request - there
+ * is no preflight to refuse it and no CORS header that governs it. So a
+ * cookie-authenticated socket is, by default, reachable by every other site the
+ * visitor has open: `evil.example` opens `wss://your-site/api/ws`, VitNode reads
+ * the session cookie off the handshake, and the connection is registered as that
+ * visitor. Everything the server then pushes to them - notifications and
+ * whatever else a plugin sends - arrives at the attacker's page instead, and
+ * every message the attacker sends is handled as that user.
+ *
+ * Hono's `csrf()` does not cover this: it inspects non-`GET` requests, and a
+ * WebSocket handshake is a `GET`.
+ *
+ * The `Origin` header is the defence, and it is a sound one here precisely
+ * because the browser sets it and a page cannot override it. A handshake that
+ * carries **no** `Origin` is allowed through: browsers always send one, so an
+ * originless handshake is a non-browser client, which has no cookies to be
+ * ridden in the first place.
+ */
+export const websocketOriginMiddleware = ({
+  origin,
+}: {
+  /**
+   * Extra origins allowed to open a socket, beyond the configured web and API
+   * origins. Pass the front end's origin when it is not `NEXT_PUBLIC_WEB_URL`.
+   */
+  origin?: string[];
+} = {}) => {
+  const allowed = new Set(
+    [
+      originOf(CONFIG.web.href),
+      originOf(CONFIG.api.origin),
+      ...(origin ?? []).map(entry => originOf(entry) ?? entry),
+    ].filter((entry): entry is string => Boolean(entry)),
+  );
+
+  return async (c: Context, next: Next) => {
+    const requestOrigin = c.req.header("origin");
+
+    // No `Origin` at all: not a browser, so not a cross-site ride on somebody's
+    // cookies. See the note above.
+    if (requestOrigin && !allowed.has(requestOrigin)) {
+      throw new HTTPException(403, {
+        message: "WebSocket connections are not allowed from this origin.",
+      });
+    }
+
+    await next();
+  };
+};
diff --git a/packages/vitnode/src/api/models/device.test.ts b/packages/vitnode/src/api/models/device.test.ts
new file mode 100644
index 000000000..8f0c5f834
--- /dev/null
+++ b/packages/vitnode/src/api/models/device.test.ts
@@ -0,0 +1,168 @@
+// @vitest-environment node
+import type { Context } from "hono";
+
+import { Hono } from "hono";
+import { describe, expect, it } from "vitest";
+
+import type { EnvVariablesVitNode } from "@/api/middlewares/global.middleware";
+
+import { core_sessions_known_devices } from "@/database/sessions";
+
+import { DeviceModel } from "./device";
+
+type Authorization = EnvVariablesVitNode["core"]["authorization"];
+
+const AUTHORIZATION: Authorization = {
+  adminCookieExpires: 1000 * 60 * 60 * 24,
+  adminCookieName: "vitnode_auth_admin",
+  cookieDomain: undefined,
+  cookie_expires: 1000 * 60 * 60 * 24 * 90,
+  cookieName: "vitnode_auth",
+  cookieSecure: true,
+  deviceCookieExpires: 1000 * 60 * 60 * 24 * 365,
+  deviceCookieName: "vitnode_device",
+  ssoAdapters: [],
+};
+
+/**
+ * A Drizzle stand-in that records how many device rows were written.
+ *
+ * `storedDevice` is what a `select` on the devices table finds - `null` for "no
+ * such device", which is both the no-cookie case and the forged-cookie case.
+ */
+const fakeDb = (storedDevice: null | { id: number }) => {
+  const inserts: unknown[] = [];
+
+  const chain = (kind: string, table: unknown) => {
+    const op = { kind, table };
+    const rows = (): unknown[] => {
+      if (op.table !== core_sessions_known_devices) return [];
+      if (op.kind === "insert") return [{ id: 99 }];
+      if (op.kind === "select") return storedDevice ? [storedDevice] : [];
+
+      return [];
+    };
+
+    const self = {
+      from: (table: unknown) => {
+        op.table = table;
+
+        return self;
+      },
+      limit: () => self,
+      returning: () => self,
+      set: () => self,
+      then: async (onFulfilled: (value: unknown[]) => unknown) =>
+        await Promise.resolve(onFulfilled(rows())),
+      values: (value: unknown) => {
+        if (op.table === core_sessions_known_devices) inserts.push(value);
+
+        return self;
+      },
+      where: () => self,
+    };
+
+    return self;
+  };
+
+  return {
+    db: {
+      delete: (table: unknown) => chain("delete", table),
+      insert: (table: unknown) => chain("insert", table),
+      select: () => chain("select", undefined),
+      update: (table: unknown) => chain("update", table),
+    },
+    inserts,
+  };
+};
+
+const run = async <T>({
+  act,
+  cookie,
+  storedDevice = null,
+}: {
+  act: (c: Context) => Promise<T>;
+  cookie?: string;
+  storedDevice?: null | { id: number };
+}): Promise<{ inserts: number; result: T }> => {
+  const { db, inserts } = fakeDb(storedDevice);
+  let result: T | undefined;
+
+  const app = new Hono();
+  app.get("/", async c => {
+    c.set("core", {
+      authorization: AUTHORIZATION,
+    } as EnvVariablesVitNode["core"]);
+    c.set("db", db as unknown as EnvVariablesVitNode["db"]);
+    c.set("ipAddress", "203.0.113.7");
+    result = await act(c);
+
+    return c.body(null, 200);
+  });
+
+  await app.request("/", cookie ? { headers: { cookie } } : {});
+
+  return { inserts: inserts.length, result: result as T };
+};
+
+describe("DeviceModel", () => {
+  describe("getExistingDeviceId", () => {
+    it("writes nothing when there is no device cookie", async () => {
+      // The regression this guards: session resolution used to create a device
+      // here, so any request carrying a made-up `vitnode_auth` cookie inserted a
+      // `core_sessions_known_devices` row before discovering there was no
+      // session. Unauthenticated, one row per request, unbounded.
+      const { inserts, result } = await run({
+        act: async c => await new DeviceModel(c).getExistingDeviceId(),
+      });
+
+      expect(result).toBeNull();
+      expect(inserts).toBe(0);
+    });
+
+    it("writes nothing for a device cookie naming no known device", async () => {
+      const { inserts, result } = await run({
+        act: async c => await new DeviceModel(c).getExistingDeviceId(),
+        cookie: "vitnode_device=deadbeef",
+      });
+
+      expect(result).toBeNull();
+      expect(inserts).toBe(0);
+    });
+
+    it("returns the device a valid cookie names", async () => {
+      const { inserts, result } = await run({
+        act: async c => await new DeviceModel(c).getExistingDeviceId(),
+        cookie: "vitnode_device=known",
+        storedDevice: { id: 42 },
+      });
+
+      expect(result).toEqual({ id: 42, publicId: "known" });
+      expect(inserts).toBe(0);
+    });
+  });
+
+  describe("getOrCreateDeviceId", () => {
+    it("creates one when there is no cookie", async () => {
+      // Sign-in and sign-up still need this: a new device record is the point
+      // there, not a side effect.
+      const { inserts, result } = await run({
+        act: async c => await new DeviceModel(c).getOrCreateDeviceId(),
+      });
+
+      expect(result.id).toBe(99);
+      expect(inserts).toBe(1);
+    });
+
+    it("reuses a known device rather than creating a second", async () => {
+      const { inserts, result } = await run({
+        act: async c => await new DeviceModel(c).getOrCreateDeviceId(),
+        cookie: "vitnode_device=known",
+        storedDevice: { id: 42 },
+      });
+
+      expect(result).toEqual({ id: 42, publicId: "known" });
+      expect(inserts).toBe(0);
+    });
+  });
+});
diff --git a/packages/vitnode/src/api/models/device.ts b/packages/vitnode/src/api/models/device.ts
index d730c3c28..0c2e2e51b 100644
--- a/packages/vitnode/src/api/models/device.ts
+++ b/packages/vitnode/src/api/models/device.ts
@@ -48,45 +48,59 @@ export class DeviceModel {
     );
   }
 
-  async getDeviceId() {
+  /**
+   * The device this request already has a record for, or `null`.
+   *
+   * Reads only - and that distinction is the point. A session row is tied to a
+   * device row, so a request with no device on file cannot be carrying a valid
+   * session, and *reading* one is the only thing session resolution needs. It
+   * used to call {@link getOrCreateDeviceId} instead, which meant any request
+   * with a made-up `vitnode_auth` cookie inserted a `core_sessions_known_devices`
+   * row before discovering the session did not exist. Unauthenticated, and one
+   * row per request, for as long as anybody cared to keep sending them.
+   */
+  async getExistingDeviceId(): Promise<null | {
+    id: number;
+    publicId: string;
+  }> {
     const deviceIdFromCookie = getCookie(
       this.c,
       this.c.get("core").authorization.deviceCookieName,
     );
+    if (!deviceIdFromCookie) return null;
 
     try {
-      if (deviceIdFromCookie) {
-        const [device] = await this.c
-          .get("db")
-          .select({
-            id: core_sessions_known_devices.id,
-          })
-          .from(core_sessions_known_devices)
-          .where(eq(core_sessions_known_devices.publicId, deviceIdFromCookie));
+      const [device] = await this.c
+        .get("db")
+        .select({ id: core_sessions_known_devices.id })
+        .from(core_sessions_known_devices)
+        .where(eq(core_sessions_known_devices.publicId, deviceIdFromCookie));
 
-        if (!device) {
-          return await this.createDevice();
-        }
+      if (!device) return null;
 
-        await this.c
-          .get("db")
-          .update(core_sessions_known_devices)
-          .set({
-            ipAddress: this.c.get("ipAddress"),
-            userAgent: this.getUserAgent(),
-            lastSeen: new Date(),
-          })
-          .where(eq(core_sessions_known_devices.publicId, deviceIdFromCookie));
+      await this.c
+        .get("db")
+        .update(core_sessions_known_devices)
+        .set({
+          ipAddress: this.c.get("ipAddress"),
+          userAgent: this.getUserAgent(),
+          lastSeen: new Date(),
+        })
+        .where(eq(core_sessions_known_devices.publicId, deviceIdFromCookie));
 
-        return {
-          id: device.id,
-          publicId: deviceIdFromCookie,
-        };
-      }
+      return { id: device.id, publicId: deviceIdFromCookie };
     } catch {
-      /* empty */
+      return null;
     }
+  }
 
-    return await this.createDevice();
+  /**
+   * The device for this request, creating and cookie-ing one if there is none.
+   *
+   * For the paths that are *establishing* something - signing in, signing up -
+   * where a new device record is the correct outcome rather than a side effect.
+   */
+  async getOrCreateDeviceId() {
+    return (await this.getExistingDeviceId()) ?? (await this.createDevice());
   }
 }
diff --git a/packages/vitnode/src/api/models/password.test.ts b/packages/vitnode/src/api/models/password.test.ts
new file mode 100644
index 000000000..00949054e
--- /dev/null
+++ b/packages/vitnode/src/api/models/password.test.ts
@@ -0,0 +1,142 @@
+import { scryptSync } from "node:crypto";
+import { describe, expect, it } from "vitest";
+
+import { ForgotPasswordTokenModel, PasswordModel } from "./password";
+
+describe("PasswordModel", () => {
+  const passwords = new PasswordModel();
+
+  it("verifies a password against its own hash", async () => {
+    const hash = await passwords.encryptPassword("Test123!");
+
+    await expect(passwords.verifyPassword("Test123!", hash)).resolves.toBe(
+      true,
+    );
+  });
+
+  it("refuses a different password", async () => {
+    const hash = await passwords.encryptPassword("Test123!");
+
+    await expect(passwords.verifyPassword("Test123?", hash)).resolves.toBe(
+      false,
+    );
+  });
+
+  it("salts each hash, so the same password hashes differently", async () => {
+    const [a, b] = await Promise.all([
+      passwords.encryptPassword("Test123!"),
+      passwords.encryptPassword("Test123!"),
+    ]);
+
+    expect(a).not.toBe(b);
+  });
+
+  it("uses a 16-byte salt", async () => {
+    const [salt] = (await passwords.encryptPassword("Test123!")).split(":");
+
+    expect(salt).toHaveLength(32);
+  });
+
+  it("still verifies hashes written with the previous 8-byte salt", async () => {
+    // The salt is read back out of the stored string, so widening it applies to
+    // new hashes only - every existing row has to keep working, or the change
+    // locks out every account on the install.
+    const salt = "ab".repeat(8);
+    const key = scryptSync("Test123!", salt, 64).toString("hex");
+
+    await expect(
+      passwords.verifyPassword("Test123!", `${salt}:${key}`),
+    ).resolves.toBe(true);
+    await expect(
+      passwords.verifyPassword("Test123?", `${salt}:${key}`),
+    ).resolves.toBe(false);
+  });
+
+  describe("a malformed stored hash", () => {
+    // These used to throw out of the promise executor and reach the client as a
+    // 500 rather than as a refused sign-in.
+    it.each([["no-colon"], [""], [":"], ["salt:"], [":key"]])(
+      "%s is refused rather than thrown",
+      async hash => {
+        await expect(passwords.verifyPassword("Test123!", hash)).resolves.toBe(
+          false,
+        );
+      },
+    );
+
+    it("is refused when the key is the wrong length", async () => {
+      await expect(
+        passwords.verifyPassword("Test123!", `${"ab".repeat(16)}:00ff`),
+      ).resolves.toBe(false);
+    });
+  });
+
+  describe("verifyDummyPassword", () => {
+    it("always answers false", async () => {
+      await expect(passwords.verifyDummyPassword("anything")).resolves.toBe(
+        false,
+      );
+    });
+
+    it("costs about as much as a real verification", async () => {
+      // The point of the method: sign-in spends it on the "no such email" path
+      // so that path cannot be told from "wrong password" by how long it took.
+      const hash = await passwords.encryptPassword("Test123!");
+
+      const timeOf = async (run: () => Promise<unknown>): Promise<number> => {
+        const started = performance.now();
+        await run();
+
+        return performance.now() - started;
+      };
+
+      const real = await timeOf(
+        async () => await passwords.verifyPassword("wrong", hash),
+      );
+      const dummy = await timeOf(
+        async () => await passwords.verifyDummyPassword("wrong"),
+      );
+
+      // Deliberately loose - this asserts "the same order of magnitude of work",
+      // which is what defeats the oracle, not a stopwatch reading.
+      expect(dummy).toBeGreaterThan(real / 10);
+    });
+  });
+});
+
+describe("ForgotPasswordTokenModel", () => {
+  const tokens = new ForgotPasswordTokenModel();
+
+  it("generates a distinct token each time", () => {
+    const generated = new Set(
+      Array.from({ length: 50 }, () => tokens.generateResetToken()),
+    );
+
+    expect(generated.size).toBe(50);
+  });
+
+  it("generates a URL-safe token with 256 bits behind it", () => {
+    const token = tokens.generateResetToken();
+
+    expect(token).toMatch(/^[A-Za-z0-9_-]+$/);
+    expect(Buffer.from(token, "base64url")).toHaveLength(32);
+  });
+
+  it("hashes to a stable 64-character digest", () => {
+    const digest = tokens.hashResetToken("a-token");
+
+    expect(digest).toHaveLength(64);
+    expect(tokens.hashResetToken("a-token")).toBe(digest);
+  });
+
+  it("does not hash to the token itself", () => {
+    // What the reset row stores has to be useless to whoever reads the table.
+    expect(tokens.hashResetToken("a-token")).not.toBe("a-token");
+  });
+
+  it("fits the token column, which is varchar(100)", () => {
+    expect(
+      tokens.hashResetToken(tokens.generateResetToken()).length,
+    ).toBeLessThanOrEqual(100);
+  });
+});
diff --git a/packages/vitnode/src/api/models/password.ts b/packages/vitnode/src/api/models/password.ts
index 099fa1761..99baa6b1e 100644
--- a/packages/vitnode/src/api/models/password.ts
+++ b/packages/vitnode/src/api/models/password.ts
@@ -1,35 +1,77 @@
 import crypto from "node:crypto";
 
+/** Bytes of salt per password. Stored hex-encoded, so 32 characters. */
+const SALT_BYTES = 16;
+
+/** Length of the derived key, in bytes. */
+const KEY_BYTES = 64;
+
+/**
+ * A syntactically valid hash that matches nothing.
+ *
+ * {@link PasswordModel.verifyDummyPassword} derives against it so that "no such
+ * account" costs the same as "wrong password" - see that method.
+ */
+const DUMMY_HASH = `${"0".repeat(SALT_BYTES * 2)}:${"0".repeat(KEY_BYTES * 2)}`;
+
+const scrypt = async (password: string, salt: string): Promise<Buffer> =>
+  await new Promise((resolve, reject) => {
+    crypto.scrypt(password, salt, KEY_BYTES, (err, derivedKey) => {
+      if (err) {
+        reject(err);
+
+        return;
+      }
+
+      resolve(derivedKey);
+    });
+  });
+
 export class PasswordModel {
   async encryptPassword(password: string): Promise<string> {
-    return await new Promise((resolve, reject) => {
-      const salt = crypto.randomBytes(8).toString("hex");
+    const salt = crypto.randomBytes(SALT_BYTES).toString("hex");
+    const derivedKey = await scrypt(password, salt);
 
-      crypto.scrypt(password, salt, 64, (err, derivedKey) => {
-        if (err) reject(err);
+    return `${salt}:${derivedKey.toString("hex")}`;
+  }
 
-        resolve(`${salt}:${derivedKey.toString("hex")}`);
-      });
-    });
+  /**
+   * Burns one password derivation and returns `false`.
+   *
+   * Sign-in used to answer "no such email" without hashing anything, so an
+   * unknown address came back in about a millisecond and a known one took as
+   * long as scrypt does. That difference is measurable over the network, which
+   * turns the sign-in endpoint into an oracle for *which addresses hold
+   * accounts* - the list every credential-stuffing run wants first.
+   *
+   * Calling this on the not-found path spends the same work, so both answers
+   * take the same time and say the same thing.
+   */
+  async verifyDummyPassword(password: string): Promise<boolean> {
+    return await this.verifyPassword(password, DUMMY_HASH);
   }
 
   async verifyPassword(password: string, hash: string): Promise<boolean> {
-    return await new Promise((resolve, reject) => {
-      const [salt, key] = hash.split(":");
-      const keyBuffer = Buffer.from(key, "hex");
-
-      crypto.scrypt(password, salt, 64, (err, derivedKey) => {
-        if (err) reject(err);
-
-        if (keyBuffer.length !== derivedKey.length) {
-          crypto.timingSafeEqual(derivedKey, derivedKey);
-          resolve(false);
-        } else {
-          const areEqual = crypto.timingSafeEqual(keyBuffer, derivedKey);
-          resolve(areEqual);
-        }
-      });
-    });
+    const [salt, key] = hash.split(":");
+
+    // A row whose hash is not `salt:key` cannot match anything, and saying so is
+    // the whole answer. Reading `key` as hex regardless used to throw out of the
+    // promise executor, which reached the client as a 500 rather than as a
+    // refused sign-in.
+    if (!salt || !key) return false;
+
+    const keyBuffer = Buffer.from(key, "hex");
+    const derivedKey = await scrypt(password, salt);
+
+    if (keyBuffer.length !== derivedKey.length) {
+      // Still compare, so a truncated stored hash is not distinguishable by how
+      // quickly it is rejected.
+      crypto.timingSafeEqual(derivedKey, derivedKey);
+
+      return false;
+    }
+
+    return crypto.timingSafeEqual(keyBuffer, derivedKey);
   }
 }
 
diff --git a/packages/vitnode/src/api/models/session-admin.ts b/packages/vitnode/src/api/models/session-admin.ts
index 7f5ea9b52..9045d7fc9 100644
--- a/packages/vitnode/src/api/models/session-admin.ts
+++ b/packages/vitnode/src/api/models/session-admin.ts
@@ -70,7 +70,7 @@ export class SessionAdminModel {
     }
 
     const hashedToken = await this.hashToken(token);
-    const device = await new DeviceModel(this.c).getDeviceId();
+    const device = await new DeviceModel(this.c).getOrCreateDeviceId();
 
     await this.c
       .get("db")
@@ -106,7 +106,7 @@ export class SessionAdminModel {
     if (!token) return;
 
     const hashedToken = await this.hashToken(token);
-    const device = await new DeviceModel(this.c).getDeviceId();
+    const device = await new DeviceModel(this.c).getExistingDeviceId();
 
     await this.c
       .get("db")
@@ -114,10 +114,13 @@ export class SessionAdminModel {
       .where(eq(core_admin_sessions.token, hashedToken));
 
     // Drop the cached resolution so getUser stops returning this admin before
-    // the TTL would naturally expire it.
-    await this.c
-      .get("cache")
-      .deleteSystem(adminSessionCacheKey(hashedToken, device.id));
+    // the TTL would naturally expire it. Nothing to drop when the device is
+    // unknown - the key is built from its id, so no entry was ever written.
+    if (device) {
+      await this.c
+        .get("cache")
+        .deleteSystem(adminSessionCacheKey(hashedToken, device.id));
+    }
 
     deleteAuthCookie(this.c, this.c.get("core").authorization.adminCookieName);
   }
@@ -127,7 +130,7 @@ export class SessionAdminModel {
     const token = getCookie(this.c, authorization.adminCookieName);
     if (!token) return null;
 
-    const device = await new DeviceModel(this.c).getDeviceId();
+    const device = await new DeviceModel(this.c).getExistingDeviceId();
     if (!device) return null;
 
     const hashedToken = await this.hashToken(token);
diff --git a/packages/vitnode/src/api/models/session-cookies.test.ts b/packages/vitnode/src/api/models/session-cookies.test.ts
index ecf08453e..da1a24baf 100644
--- a/packages/vitnode/src/api/models/session-cookies.test.ts
+++ b/packages/vitnode/src/api/models/session-cookies.test.ts
@@ -262,7 +262,8 @@ describe("admin session cookie", () => {
 });
 
 describe("device cookie", () => {
-  const create = async (c: Context) => await new DeviceModel(c).getDeviceId();
+  const create = async (c: Context) =>
+    await new DeviceModel(c).getOrCreateDeviceId();
 
   it.each(HOSTS)("is host-only on %s", async (_label, url) => {
     const cookie = named(
diff --git a/packages/vitnode/src/api/models/session-revoke.ts b/packages/vitnode/src/api/models/session-revoke.ts
new file mode 100644
index 000000000..49e4fa04f
--- /dev/null
+++ b/packages/vitnode/src/api/models/session-revoke.ts
@@ -0,0 +1,106 @@
+import type { Context } from "hono";
+
+import { eq } from "drizzle-orm";
+
+import { core_admin_sessions } from "@/database/admins";
+import { core_sessions } from "@/database/sessions";
+
+import { adminSessionCacheKey, sessionCacheKey } from "./session-cache";
+
+/**
+ * The cache keys holding one user's resolved sessions, read off their rows.
+ *
+ * The cache is keyed by token, so there is no way back from a user id to those
+ * keys other than looking the sessions up first. Both callers below need exactly
+ * that, for opposite reasons - one is about to delete the rows, the other wants
+ * them re-read - so the lookup lives here once.
+ */
+const sessionCacheKeysForUser = async (
+  c: Context,
+  userId: number,
+): Promise<string[]> => {
+  const db = c.get("db");
+
+  const [sessions, adminSessions] = await Promise.all([
+    db
+      .select({ token: core_sessions.token, deviceId: core_sessions.deviceId })
+      .from(core_sessions)
+      .where(eq(core_sessions.userId, userId)),
+    db
+      .select({
+        token: core_admin_sessions.token,
+        deviceId: core_admin_sessions.deviceId,
+      })
+      .from(core_admin_sessions)
+      .where(eq(core_admin_sessions.userId, userId)),
+  ]);
+
+  return [
+    ...sessions.map(({ token, deviceId }) => sessionCacheKey(token, deviceId)),
+    ...adminSessions.map(({ token, deviceId }) =>
+      adminSessionCacheKey(token, deviceId),
+    ),
+  ];
+};
+
+/**
+ * Drops one user's cached session rows, leaving the sessions themselves alone.
+ *
+ * Call this whenever something the *cached user object* carries has changed -
+ * `roleId`, above all. `resolveStaffPermissions` is handed `c.get("user")`,
+ * which is that cached object, and reads the primary role straight off it:
+ *
+ * ```ts
+ * const roleIds = await getUserRoleIds(c, user);   // [user.roleId, ...secondary]
+ * ```
+ *
+ * Expiring the permission cache alone is therefore not enough. Recomputing from
+ * a stale `roleId` produces the same answer it just threw away, so somebody
+ * demoted out of an administrator role kept its powers until the session cache
+ * happened to expire - a minute in which the demotion had visibly been applied
+ * and had not taken effect.
+ */
+export const invalidateSessionCacheForUser = async (
+  c: Context,
+  userId: number,
+): Promise<void> => {
+  const keys = await sessionCacheKeysForUser(c, userId);
+
+  if (keys.length > 0) {
+    await c.get("cache").deleteSystem(keys);
+  }
+};
+
+/**
+ * Signs one user out everywhere - every device, every browser, the AdminCP
+ * included.
+ *
+ * Called when a credential changes hands. A password reset that leaves the old
+ * sessions alive only locks the attacker out of *signing in again*: whatever
+ * they already hold keeps working for the ninety days the session cookie lasts,
+ * which is the opposite of what somebody resetting a password after a breach
+ * believes they just did.
+ *
+ * The rows are read before they are deleted because the session cache is keyed
+ * by token, and there is no other way back from a user id to the keys holding
+ * them. Its TTL is only a minute, so this is about closing that minute rather
+ * than about correctness over time.
+ */
+export const revokeAllSessionsForUser = async (
+  c: Context,
+  userId: number,
+): Promise<void> => {
+  const db = c.get("db");
+  const keys = await sessionCacheKeysForUser(c, userId);
+
+  await Promise.all([
+    db.delete(core_sessions).where(eq(core_sessions.userId, userId)),
+    db
+      .delete(core_admin_sessions)
+      .where(eq(core_admin_sessions.userId, userId)),
+  ]);
+
+  if (keys.length > 0) {
+    await c.get("cache").deleteSystem(keys);
+  }
+};
diff --git a/packages/vitnode/src/api/models/session.ts b/packages/vitnode/src/api/models/session.ts
index 811aa26d5..e6af92c0f 100644
--- a/packages/vitnode/src/api/models/session.ts
+++ b/packages/vitnode/src/api/models/session.ts
@@ -45,7 +45,7 @@ export class SessionModel {
       token += byte.toString(16).padStart(2, "0");
     }
 
-    const device = await new DeviceModel(this.c).getDeviceId();
+    const device = await new DeviceModel(this.c).getOrCreateDeviceId();
     const hashedToken = await this.hashToken(token);
 
     await this.c
@@ -77,10 +77,10 @@ export class SessionModel {
       this.c,
       this.c.get("core").authorization.cookieName,
     );
-    const device = await new DeviceModel(this.c).getDeviceId();
+    const device = await new DeviceModel(this.c).getExistingDeviceId();
 
     // Ensure both token and deviceId exist before proceeding
-    if (!(token && device.id)) {
+    if (!(token && device?.id)) {
       deleteAuthCookie(this.c, this.c.get("core").authorization.cookieName);
 
       return;
@@ -113,7 +113,7 @@ export class SessionModel {
     );
     if (!token) return null;
 
-    const device = await new DeviceModel(this.c).getDeviceId();
+    const device = await new DeviceModel(this.c).getExistingDeviceId();
     if (!device) return null;
 
     const hashedToken = await this.hashToken(token);
diff --git a/packages/vitnode/src/api/models/storage.ts b/packages/vitnode/src/api/models/storage.ts
index eede27005..d837f5327 100644
--- a/packages/vitnode/src/api/models/storage.ts
+++ b/packages/vitnode/src/api/models/storage.ts
@@ -513,6 +513,7 @@ export class StorageModel {
       fileName: generateStorageFileName(
         file.name,
         processed.extension ?? undefined,
+        processed.mimeType,
       ),
     });
 
diff --git a/packages/vitnode/src/api/models/user/sign-in-with-passwords.ts b/packages/vitnode/src/api/models/user/sign-in-with-passwords.ts
index 46384a4b9..35e436e0f 100644
--- a/packages/vitnode/src/api/models/user/sign-in-with-passwords.ts
+++ b/packages/vitnode/src/api/models/user/sign-in-with-passwords.ts
@@ -27,14 +27,19 @@ export const signInWithPassword = async ({
     .where(eq(core_users.email, email))
     .limit(1);
 
+  const passwords = new PasswordModel();
+
+  // Both branches derive a key before answering. Returning early here - which is
+  // what this did - made "no account with that email" measurably faster than
+  // "wrong password", so anyone could sift a list of addresses for the ones that
+  // are registered simply by timing the 403s.
   if (!user?.password) {
+    await passwords.verifyDummyPassword(password);
+
     throw new HTTPException(403);
   }
 
-  const validPassword = await new PasswordModel().verifyPassword(
-    password,
-    user.password,
-  );
+  const validPassword = await passwords.verifyPassword(password, user.password);
 
   if (!validPassword) {
     throw new HTTPException(403);
diff --git a/packages/vitnode/src/api/modules/admin/advanced/queue/routes/get.route.ts b/packages/vitnode/src/api/modules/admin/advanced/queue/routes/get.route.ts
index 0a5898163..dab003eb7 100644
--- a/packages/vitnode/src/api/modules/admin/advanced/queue/routes/get.route.ts
+++ b/packages/vitnode/src/api/modules/admin/advanced/queue/routes/get.route.ts
@@ -1,4 +1,4 @@
-import { getColumns, inArray } from "drizzle-orm";
+import { inArray } from "drizzle-orm";
 import z from "zod";
 
 import { buildRoute } from "@/api/lib/route";
@@ -73,10 +73,32 @@ export const getQueueTasksRoute = buildRoute({
       c,
       primaryCursor: core_queue.id,
       where: statuses.length ? inArray(core_queue.status, statuses) : undefined,
+      // Named columns rather than `getColumns(core_queue)`, which also returned
+      // `payload`. A queue job's payload is its arguments, and for `send-email`
+      // those are the fully rendered message - so the list handed every holder
+      // of `queue:can_view` the body of every outgoing email, live password
+      // reset links included. The response schema above never admitted to
+      // returning it, and nothing validates a response against that schema, so
+      // the extra column simply travelled.
       query: async ({ cursorSelection, limit, where, orderBy }) =>
         await c
           .get("db")
-          .select({ ...getColumns(core_queue), ...cursorSelection })
+          .select({
+            ...cursorSelection,
+            id: core_queue.id,
+            pluginId: core_queue.pluginId,
+            name: core_queue.name,
+            queue: core_queue.queue,
+            status: core_queue.status,
+            priority: core_queue.priority,
+            attempts: core_queue.attempts,
+            maxAttempts: core_queue.maxAttempts,
+            availableAt: core_queue.availableAt,
+            reservedAt: core_queue.reservedAt,
+            lastError: core_queue.lastError,
+            createdAt: core_queue.createdAt,
+            completedAt: core_queue.completedAt,
+          })
           .from(core_queue)
           .where(where)
           .orderBy(orderBy)
diff --git a/packages/vitnode/src/api/modules/admin/roles/routes/show.route.ts b/packages/vitnode/src/api/modules/admin/roles/routes/show.route.ts
index ae6ab395e..0f3ab816d 100644
--- a/packages/vitnode/src/api/modules/admin/roles/routes/show.route.ts
+++ b/packages/vitnode/src/api/modules/admin/roles/routes/show.route.ts
@@ -30,6 +30,12 @@ const roleAdminSchema = z.object({
 
 export const showRoleAdminRoute = buildRoute({
   pluginId: CONFIG_PLUGIN.pluginId,
+  // `list` is deliberately ungated - a role *picker* has to work for an
+  // administrator who cannot open the roles screen - but that rationale does not
+  // reach one role's full record, which is the edit screen's read and nothing
+  // else's. `can_edit` depends on `can_view` in the catalog, so every role that
+  // could already open this screen still can.
+  adminStaffPermission: { module: "roles", permission: "can_view" },
   route: {
     method: "get",
     description: "Get a single role by id (Admin only)",
diff --git a/packages/vitnode/src/api/modules/admin/routes/notifications.route.ts b/packages/vitnode/src/api/modules/admin/routes/notifications.route.ts
index f77856237..f1b32ee6b 100644
--- a/packages/vitnode/src/api/modules/admin/routes/notifications.route.ts
+++ b/packages/vitnode/src/api/modules/admin/routes/notifications.route.ts
@@ -14,6 +14,13 @@ export const zodSendNotificationSchema = z.object({
 
 export const sendNotificationRoute = buildRoute({
   pluginId: CONFIG_PLUGIN.pluginId,
+  // The send-notification dashboard widget is the only caller, and its sibling
+  // (`PUT /admin/dashboard/widget-settings`) is gated the same way. Without a
+  // declaration the route asked only for *an* admin session, so an
+  // administrator restricted to one unrelated screen could still push arbitrary
+  // titles and bodies to any user id - a message that arrives inside the
+  // product, wearing the product's own notification UI.
+  adminStaffPermission: { module: "dashboard", permission: "can_edit" },
   route: {
     method: "post",
     description: "Send a notification to a user",
diff --git a/packages/vitnode/src/api/modules/admin/users/lib/assert-edit-user-permission.test.ts b/packages/vitnode/src/api/modules/admin/users/lib/assert-edit-user-permission.test.ts
new file mode 100644
index 000000000..e6eea029c
--- /dev/null
+++ b/packages/vitnode/src/api/modules/admin/users/lib/assert-edit-user-permission.test.ts
@@ -0,0 +1,127 @@
+import type { Context } from "hono";
+
+import { HTTPException } from "hono/http-exception";
+import { describe, expect, it, vi } from "vitest";
+
+import { core_admin_permissions } from "@/database/admins";
+import { core_moderators_permissions } from "@/database/moderators";
+import { core_roles } from "@/database/roles";
+
+import { assertCanAssignRoles } from "./assert-edit-user-permission";
+
+const assertStaffPermission = vi.hoisted(() => vi.fn());
+
+vi.mock("@/api/lib/check-staff-permission", () => ({
+  assertStaffPermission,
+}));
+
+/**
+ * Which roles the fake database considers staff-granting, by the table that
+ * would say so. The guard runs one query per table, so the stub answers by
+ * which table the query named.
+ */
+interface StaffRoles {
+  admin?: number[];
+  moderator?: number[];
+  root?: number[];
+}
+
+/**
+ * A stand-in for the Drizzle query builder: `.select().from(t).where().limit()`
+ * resolves to a row when `t`'s set contains any of the roles under test.
+ *
+ * A stub rather than a database because the thing worth asserting is the
+ * *decision* - "does attaching these roles need `can_edit_admin`" - and that is
+ * three lookups and a boolean, not a schema.
+ */
+const contextWith = (staff: StaffRoles, roleIds: number[]): Context => {
+  const idsFor = (table: unknown): number[] => {
+    if (table === core_roles) return staff.root ?? [];
+    if (table === core_admin_permissions) return staff.admin ?? [];
+    if (table === core_moderators_permissions) return staff.moderator ?? [];
+
+    throw new Error("unexpected table");
+  };
+
+  const db = {
+    select: () => ({
+      from: (table: unknown) => {
+        const matches = idsFor(table).filter(id => roleIds.includes(id));
+
+        return {
+          where: () => ({
+            limit: async () =>
+              await Promise.resolve(matches.map(id => ({ id }))),
+          }),
+        };
+      },
+    }),
+  };
+
+  return { get: (key: string) => (key === "db" ? db : undefined) } as Context;
+};
+
+const assign = async (staff: StaffRoles, roleIds: number[]): Promise<void> => {
+  await assertCanAssignRoles(contextWith(staff, roleIds), roleIds);
+};
+
+describe("assertCanAssignRoles", () => {
+  it("lets an ordinary role through without an elevated check", async () => {
+    assertStaffPermission.mockClear();
+    await assign({ admin: [9], root: [9] }, [2]);
+
+    expect(assertStaffPermission).not.toHaveBeenCalled();
+  });
+
+  it("asks for nothing when no roles are being assigned", async () => {
+    assertStaffPermission.mockClear();
+    await assign({ admin: [9] }, []);
+
+    expect(assertStaffPermission).not.toHaveBeenCalled();
+  });
+
+  it.each([
+    ["a role with an admin-permissions row", { admin: [9] }],
+    ["a root role", { root: [9] }],
+    ["a role with a moderator-permissions row", { moderator: [9] }],
+  ])("requires users:can_edit_admin for %s", async (_label, staff) => {
+    assertStaffPermission.mockClear();
+    await assign(staff, [9]);
+
+    expect(assertStaffPermission).toHaveBeenCalledWith(
+      expect.anything(),
+      expect.objectContaining({
+        module: "users",
+        permission: "can_edit_admin",
+        type: "admin",
+      }),
+    );
+  });
+
+  it("catches a staff role hidden among ordinary ones", async () => {
+    // The escalation this guard exists for: a `users:can_edit` administrator
+    // sending `secondaryRoleIds: [2, 3, <root>]`. Guarding only the primary role
+    // let the whole secondary list past, and a secondary root role grants
+    // everything - `loadStaffPermissions` reads primary and secondary alike.
+    assertStaffPermission.mockClear();
+    await assign({ root: [9] }, [2, 3, 9]);
+
+    expect(assertStaffPermission).toHaveBeenCalledOnce();
+  });
+
+  it("propagates the refusal when the caller lacks the permission", async () => {
+    assertStaffPermission.mockClear();
+    assertStaffPermission.mockRejectedValueOnce(new HTTPException(403));
+
+    await expect(assign({ root: [9] }, [9])).rejects.toBeInstanceOf(
+      HTTPException,
+    );
+  });
+
+  it("checks a role list with duplicates once", async () => {
+    assertStaffPermission.mockClear();
+    await assign({ admin: [9] }, [9, 9, 9]);
+
+    expect(assertStaffPermission).toHaveBeenCalledOnce();
+  });
+});
diff --git a/packages/vitnode/src/api/modules/admin/users/lib/assert-edit-user-permission.ts b/packages/vitnode/src/api/modules/admin/users/lib/assert-edit-user-permission.ts
index 36ecb7889..07ddc0f6e 100644
--- a/packages/vitnode/src/api/modules/admin/users/lib/assert-edit-user-permission.ts
+++ b/packages/vitnode/src/api/modules/admin/users/lib/assert-edit-user-permission.ts
@@ -1,11 +1,13 @@
 import type { Context } from "hono";
 
-import { eq } from "drizzle-orm";
+import { and, eq, inArray } from "drizzle-orm";
 
 import { assertStaffPermission } from "@/api/lib/check-staff-permission";
 import { SessionAdminModel } from "@/api/models/session-admin";
 import { CONFIG_PLUGIN } from "@/config";
 import { core_admin_permissions } from "@/database/admins";
+import { core_moderators_permissions } from "@/database/moderators";
+import { core_roles } from "@/database/roles";
 
 const assertCanEditAdmin = async (c: Context): Promise<void> => {
   await assertStaffPermission(c, {
@@ -29,24 +31,83 @@ export const assertCanEditAdminTarget = async (
 };
 
 /**
- * A role grants admin access when it has a row in `core_admin_permissions`.
- * Assigning such a role as a user's primary role turns that user into an admin
- * (see `SessionAdminModel.checkIfUserIsAdmin`), so it must require the same
- * `can_edit_admin` permission as editing an already-admin user - otherwise a
- * `can_edit`-only admin could escalate a non-admin user into an admin.
+ * Whether granting any of these roles hands the holder staff powers.
+ *
+ * Three ways a role can, and all three have to be asked about together:
+ *
+ * - a row in `core_admin_permissions` - what `checkIfUserIsAdmin` reads, so the
+ *   role opens the AdminCP;
+ * - a row in `core_moderators_permissions` - the moderator half of the same
+ *   thing, `unrestricted` on the seeded Moderator role;
+ * - `core_roles.root` - which `loadStaffPermissions` short-circuits on to return
+ *   *every* permission, whether or not a staff row exists. Checked in its own
+ *   right rather than assumed to imply the first, because a role granting
+ *   everything is exactly the one not to miss on an install whose rows were
+ *   built by hand.
  */
-export const assertCanAssignPrimaryRole = async (
+const rolesGrantStaffAccess = async (
   c: Context,
-  roleId: number,
-): Promise<void> => {
-  const [adminRole] = await c
-    .get("db")
-    .select({ id: core_admin_permissions.id })
-    .from(core_admin_permissions)
-    .where(eq(core_admin_permissions.roleId, roleId))
-    .limit(1);
+  roleIds: number[],
+): Promise<boolean> => {
+  if (roleIds.length === 0) return false;
+
+  const db = c.get("db");
+
+  const [rootRoles, adminRoles, moderatorRoles] = await Promise.all([
+    db
+      .select({ id: core_roles.id })
+      .from(core_roles)
+      .where(and(inArray(core_roles.id, roleIds), eq(core_roles.root, true)))
+      .limit(1),
+    db
+      .select({ id: core_admin_permissions.id })
+      .from(core_admin_permissions)
+      .where(inArray(core_admin_permissions.roleId, roleIds))
+      .limit(1),
+    db
+      .select({ id: core_moderators_permissions.id })
+      .from(core_moderators_permissions)
+      .where(inArray(core_moderators_permissions.roleId, roleIds))
+      .limit(1),
+  ]);
 
-  if (!adminRole) return;
+  return (
+    rootRoles.length > 0 || adminRoles.length > 0 || moderatorRoles.length > 0
+  );
+};
+
+/**
+ * Refuses to attach a staff-granting role unless the caller holds
+ * `users:can_edit_admin`.
+ *
+ * ## Why every role, not just the primary one
+ *
+ * `loadStaffPermissions` resolves a user's powers from `getUserRoleIds`, which
+ * is the primary role **plus every secondary role**. A secondary role therefore
+ * grants exactly what a primary one does - up to and including `root`, which
+ * short-circuits the whole permission check to "yes".
+ *
+ * This guard used to run on `body.roleId` alone, so the secondary list walked
+ * straight past it. An administrator holding only `users:can_edit` could
+ * `PATCH /admin/users/{their own id}` with `secondaryRoleIds: [<root role>]`
+ * and come back as root - the escalation the primary-role check was written to
+ * prevent, reached by the field beside it. Both lists are checked here now, so
+ * there is no "the other one" left to find.
+ */
+export const assertCanAssignRoles = async (
+  c: Context,
+  roleIds: number[],
+): Promise<void> => {
+  const unique = [...new Set(roleIds)];
+  if (!(await rolesGrantStaffAccess(c, unique))) return;
 
   await assertCanEditAdmin(c);
 };
+
+/** {@link assertCanAssignRoles} for a single role. */
+export const assertCanAssignPrimaryRole = async (
+  c: Context,
+  roleId: number,
+): Promise<void> => {
+  await assertCanAssignRoles(c, [roleId]);
+};
diff --git a/packages/vitnode/src/api/modules/admin/users/routes/update.route.ts b/packages/vitnode/src/api/modules/admin/users/routes/update.route.ts
index d7ffc633e..a373aaeba 100644
--- a/packages/vitnode/src/api/modules/admin/users/routes/update.route.ts
+++ b/packages/vitnode/src/api/modules/admin/users/routes/update.route.ts
@@ -3,12 +3,13 @@ import { and, eq, inArray, ne } from "drizzle-orm";
 
 import { buildRoute } from "@/api/lib/route";
 import { invalidateStaffPermissionsForUser } from "@/api/lib/staff-permission-cache";
+import { invalidateSessionCacheForUser } from "@/api/models/session-revoke";
 import { CONFIG_PLUGIN } from "@/config";
 import { core_roles } from "@/database/roles";
 import { core_users, core_users_secondary_roles } from "@/database/users";
 
 import {
-  assertCanAssignPrimaryRole,
+  assertCanAssignRoles,
   assertCanEditAdminTarget,
 } from "../lib/assert-edit-user-permission";
 
@@ -207,8 +208,16 @@ export const updateUserAdminRoute = buildRoute({
       }
     }
 
+    // Every role being attached, in one check, before any of them is written.
+    // Secondary roles carry the same weight as the primary one -
+    // `loadStaffPermissions` reads them all - so guarding only `body.roleId`
+    // left `secondaryRoleIds` as a way to hand out root without holding
+    // `can_edit_admin`.
+    if (roleIdsToValidate.length > 0) {
+      await assertCanAssignRoles(c, roleIdsToValidate);
+    }
+
     if (body.roleId !== undefined) {
-      await assertCanAssignPrimaryRole(c, body.roleId);
       values.roleId = body.roleId;
     }
 
@@ -246,7 +255,14 @@ export const updateUserAdminRoute = buildRoute({
         });
 
       if (rolesChanged) {
-        await invalidateStaffPermissionsForUser(c, user.id);
+        // Both caches, not just the permission one. `resolveStaffPermissions`
+        // reads the primary role off the *cached user object*, so recomputing
+        // from a stale `roleId` reaches the same answer it just discarded - and
+        // a demotion applied here would not take effect for another minute.
+        await Promise.all([
+          invalidateStaffPermissionsForUser(c, user.id),
+          invalidateSessionCacheForUser(c, user.id),
+        ]);
       }
 
       await c.get("events").emit("user.updated", {
@@ -271,7 +287,12 @@ export const updateUserAdminRoute = buildRoute({
       .limit(1);
 
     if (rolesChanged) {
-      await invalidateStaffPermissionsForUser(c, user.id);
+      // The same pair as above - and this is the likelier path of the two, since
+      // a request that changes only roles never reaches the `values` branch.
+      await Promise.all([
+        invalidateStaffPermissionsForUser(c, user.id),
+        invalidateSessionCacheForUser(c, user.id),
+      ]);
     }
 
     await c.get("events").emit("user.updated", {
diff --git a/packages/vitnode/src/api/modules/search/routes/search.route.ts b/packages/vitnode/src/api/modules/search/routes/search.route.ts
index 0256d91ed..be92e998c 100644
--- a/packages/vitnode/src/api/modules/search/routes/search.route.ts
+++ b/packages/vitnode/src/api/modules/search/routes/search.route.ts
@@ -47,6 +47,35 @@ export const zodSearchHitSchema = z.object({
     .nullable(),
 });
 
+/**
+ * A query parameter as a positive integer, or nothing.
+ *
+ * `Number("abc")` is `NaN` and `new Date("abc")` is an Invalid Date, and both
+ * used to travel straight into the query builder - where Postgres rejects them,
+ * which reaches the caller as a `500` and writes a `core_logs` row on the way.
+ * This is a public, unauthenticated endpoint, so that was a log-flooding
+ * primitive as much as it was a bad status code. A filter nobody can parse is
+ * not an error; it is a filter that was not asked for.
+ */
+const positiveIntOrUndefined = (
+  value: string | undefined,
+): number | undefined => {
+  if (value === undefined || value === "") return undefined;
+
+  const parsed = Number(value);
+
+  return Number.isSafeInteger(parsed) && parsed > 0 ? parsed : undefined;
+};
+
+/** A query parameter as a real date, or nothing. See above. */
+const dateOrUndefined = (value: string | undefined): Date | undefined => {
+  if (value === undefined || value === "") return undefined;
+
+  const parsed = new Date(value);
+
+  return Number.isNaN(parsed.getTime()) ? undefined : parsed;
+};
+
 export const searchRoute = buildRoute({
   pluginId: CONFIG_PLUGIN.pluginId,
   route: {
@@ -91,12 +120,12 @@ export const searchRoute = buildRoute({
       itemTypes: query.types
         ? query.types.split(",").filter(Boolean)
         : undefined,
-      authorId: query.authorId ? Number(query.authorId) : undefined,
-      containerId: query.containerId ? Number(query.containerId) : undefined,
+      authorId: positiveIntOrUndefined(query.authorId),
+      containerId: positiveIntOrUndefined(query.containerId),
       sort: query.sort,
-      dateFrom: query.from ? new Date(query.from) : undefined,
-      dateTo: query.to ? new Date(query.to) : undefined,
-      first: query.first ? Number(query.first) : undefined,
+      dateFrom: dateOrUndefined(query.from),
+      dateTo: dateOrUndefined(query.to),
+      first: positiveIntOrUndefined(query.first),
       cursor: query.cursor,
       languageCode: query.lang,
       includePrivate: false,
diff --git a/packages/vitnode/src/api/modules/users/routes/change-password.route.ts b/packages/vitnode/src/api/modules/users/routes/change-password.route.ts
index 06b619502..b1795dcf7 100644
--- a/packages/vitnode/src/api/modules/users/routes/change-password.route.ts
+++ b/packages/vitnode/src/api/modules/users/routes/change-password.route.ts
@@ -3,7 +3,8 @@ import { HTTPException } from "hono/http-exception";
 import { z } from "zod";
 
 import { buildRoute } from "@/api/lib/route";
-import { PasswordModel } from "@/api/models/password";
+import { ForgotPasswordTokenModel, PasswordModel } from "@/api/models/password";
+import { revokeAllSessionsForUser } from "@/api/models/session-revoke";
 import { CONFIG_PLUGIN } from "@/config";
 import { core_users, core_users_forgot_password } from "@/database/users";
 
@@ -49,6 +50,11 @@ export const changePasswordRoute = buildRoute({
   handler: async c => {
     const { password, userId, token } = c.req.valid("json");
 
+    // The column holds a digest, never the token itself - see the reset route.
+    // Matching on the digest is what lets the stored value be useless to anyone
+    // who reads the table.
+    const hashedToken = new ForgotPasswordTokenModel().hashResetToken(token);
+
     const [user] = await c
       .get("db")
       .select()
@@ -56,7 +62,7 @@ export const changePasswordRoute = buildRoute({
       .where(
         and(
           eq(core_users_forgot_password.userId, userId),
-          eq(core_users_forgot_password.token, token),
+          eq(core_users_forgot_password.token, hashedToken),
           gt(core_users_forgot_password.expiresAt, new Date()),
         ),
       )
@@ -79,6 +85,13 @@ export const changePasswordRoute = buildRoute({
         .where(eq(core_users_forgot_password.id, user.id)),
     ]);
 
+    // After the new password is in place, so a failure above cannot sign
+    // somebody out without having changed anything. Whoever reset this password
+    // is doing it because the old credential is not trusted any more, and every
+    // session opened with it is exactly as untrusted - including the attacker's,
+    // which would otherwise outlive the reset by up to ninety days.
+    await revokeAllSessionsForUser(c, userId);
+
     return c.text("Password changed", 201);
   },
 });
diff --git a/packages/vitnode/src/api/modules/users/routes/reset-passowrd.route.ts b/packages/vitnode/src/api/modules/users/routes/reset-passowrd.route.ts
index c23676f5a..35ba97dbd 100644
--- a/packages/vitnode/src/api/modules/users/routes/reset-passowrd.route.ts
+++ b/packages/vitnode/src/api/modules/users/routes/reset-passowrd.route.ts
@@ -54,7 +54,14 @@ export const resetPasswordRoute = buildRoute({
       return RESPONSE_TEXT;
     }
 
-    const hashToken = new ForgotPasswordTokenModel().generateResetToken();
+    // Two values, deliberately: the raw token goes in the email and nowhere
+    // else, and only its digest is written down. A reset row used to hold the
+    // live token in plaintext, so anything that could read the table - a
+    // read-replica, a backup, a leaked dump, a stray log line - could reset
+    // every account on the install without knowing a single password.
+    const tokens = new ForgotPasswordTokenModel();
+    const resetToken = tokens.generateResetToken();
+    const hashToken = tokens.hashResetToken(resetToken);
 
     const [findLastRecord] = await c
       .get("db")
@@ -95,7 +102,7 @@ export const resetPasswordRoute = buildRoute({
 
     // Send email
     const resetUrlNative = new URL(
-      `login/reset-password?token=${hashToken}&userId=${findUser.id}`,
+      `login/reset-password?token=${encodeURIComponent(resetToken)}&userId=${findUser.id}`,
       CONFIG.web.href,
     );
 
diff --git a/packages/vitnode/src/api/modules/users/routes/test.route.ts b/packages/vitnode/src/api/modules/users/routes/test.route.ts
deleted file mode 100644
index 4dc0ca2a5..000000000
--- a/packages/vitnode/src/api/modules/users/routes/test.route.ts
+++ /dev/null
@@ -1,36 +0,0 @@
-import { z } from "zod";
-
-import { buildRoute } from "@/api/lib/route";
-import { CONFIG_PLUGIN } from "@/config";
-
-export const testRoute = buildRoute({
-  pluginId: CONFIG_PLUGIN.pluginId,
-  route: {
-    method: "post",
-    description: "Test route",
-    path: "/test",
-    responses: {
-      200: {
-        content: {
-          "text/plain": {
-            schema: z.string(),
-          },
-        },
-        description: "User",
-      },
-      201: {
-        content: {
-          "text/plain": {
-            schema: z.string(),
-          },
-        },
-        description: "User",
-      },
-    },
-  },
-  handler: async c => {
-    await c.get("log").warn("This is a test warn log");
-
-    return c.text("test");
-  },
-});
diff --git a/packages/vitnode/src/api/modules/users/users.module.ts b/packages/vitnode/src/api/modules/users/users.module.ts
index d82e38f1e..d643f5bcc 100644
--- a/packages/vitnode/src/api/modules/users/users.module.ts
+++ b/packages/vitnode/src/api/modules/users/users.module.ts
@@ -11,7 +11,6 @@ import { sessionRoute } from "./routes/session.route";
 import { signInRoute } from "./routes/sign-in.route";
 import { signOutRoute } from "./routes/sign-out.route";
 import { signUpRoute } from "./routes/sign-up.route";
-import { testRoute } from "./routes/test.route";
 import { ssoUserModule } from "./sso/sso.module";
 
 export const usersModule = buildModule({
@@ -22,7 +21,6 @@ export const usersModule = buildModule({
     signInRoute,
     signOutRoute,
     signUpRoute,
-    testRoute,
     resetPasswordRoute,
     changePasswordRoute,
     permissionsRoute,
diff --git a/packages/vitnode/src/lib/api/upload.test.ts b/packages/vitnode/src/lib/api/upload.test.ts
index c938806c5..1099f6365 100644
--- a/packages/vitnode/src/lib/api/upload.test.ts
+++ b/packages/vitnode/src/lib/api/upload.test.ts
@@ -7,6 +7,7 @@ import {
   getFileExtension,
   parseImageDimensions,
   replaceFileExtension,
+  safeStorageExtension,
   sanitizeFolder,
 } from "./upload";
 
@@ -133,3 +134,101 @@ describe("parseImageDimensions", () => {
     expect(parseImageDimensions({ dimensions: { width: 320 } })).toBeNull();
   });
 });
+
+describe("safeStorageExtension", () => {
+  describe("when the media type is one VitNode knows", () => {
+    it("keeps an extension that belongs to it", () => {
+      expect(safeStorageExtension(".png", "image/png")).toBe(".png");
+      expect(safeStorageExtension(".jpeg", "image/jpeg")).toBe(".jpeg");
+    });
+
+    it("replaces one that does not", () => {
+      // The attack this exists for: the browser announces `image/gif`, the file
+      // passes the media-type check, and the name decides what it is written to
+      // disk as. Served back from the site's own origin, `.html` is a page.
+      expect(safeStorageExtension(".html", "image/gif")).toBe(".gif");
+      expect(safeStorageExtension(".svg", "image/png")).toBe(".png");
+      expect(safeStorageExtension("", "image/webp")).toBe(".webp");
+    });
+
+    it("reads the type without its parameters", () => {
+      expect(safeStorageExtension(".png", "image/png; charset=binary")).toBe(
+        ".png",
+      );
+    });
+
+    it("is case-insensitive on both sides", () => {
+      expect(safeStorageExtension(".PNG", "IMAGE/PNG")).toBe(".png");
+    });
+
+    it("still stores SVG as SVG", () => {
+      // A real image type. Script inside one is the serving layer's problem -
+      // see the sandbox headers on the uploads mount.
+      expect(safeStorageExtension(".svg", "image/svg+xml")).toBe(".svg");
+    });
+  });
+
+  describe("when the media type is unknown", () => {
+    it("keeps an inert extension", () => {
+      expect(safeStorageExtension(".psd", "application/octet-stream")).toBe(
+        ".psd",
+      );
+      expect(safeStorageExtension(".docx")).toBe(".docx");
+    });
+
+    it.each([
+      ".html",
+      ".htm",
+      ".xhtml",
+      ".js",
+      ".mjs",
+      ".php",
+      ".phtml",
+      ".jsp",
+      ".aspx",
+      ".xml",
+      ".xsl",
+      ".svgz",
+      ".swf",
+      ".sh",
+    ])("neutralises %s", extension => {
+      expect(safeStorageExtension(extension)).toBe(".bin");
+    });
+
+    it("neutralises them case-insensitively", () => {
+      expect(safeStorageExtension(".HTML")).toBe(".bin");
+      expect(safeStorageExtension(".PhP")).toBe(".bin");
+    });
+
+    it.each([
+      ["", "no extension"],
+      [".", "a bare dot"],
+      ["..", "a climb"],
+      [".a b", "a space"],
+      [".ht/ml", "a separator"],
+      [".verylongextensionindeed", "an overlong one"],
+    ])("neutralises %s (%s)", extension => {
+      expect(safeStorageExtension(extension)).toBe(".bin");
+    });
+  });
+});
+
+describe("generateStorageFileName with a media type", () => {
+  it("stores a mislabelled name under the media type's extension", () => {
+    expect(
+      generateStorageFileName("payload.html", undefined, "image/gif"),
+    ).toMatch(/^[0-9a-f-]{36}\.gif$/);
+  });
+
+  it("keeps a server-derived override that fits the type", () => {
+    expect(generateStorageFileName("photo.png", ".webp", "image/webp")).toMatch(
+      /^[0-9a-f-]{36}\.webp$/,
+    );
+  });
+
+  it("neutralises an executable extension when the type is unknown", () => {
+    expect(generateStorageFileName("payload.php")).toMatch(
+      /^[0-9a-f-]{36}\.bin$/,
+    );
+  });
+});
diff --git a/packages/vitnode/src/lib/api/upload.ts b/packages/vitnode/src/lib/api/upload.ts
index ebbb0478b..d01d86acb 100644
--- a/packages/vitnode/src/lib/api/upload.ts
+++ b/packages/vitnode/src/lib/api/upload.ts
@@ -47,17 +47,144 @@ export const sanitizeFolder = (folder: string): string => {
   return folder;
 };
 
+/**
+ * The extensions each media type is allowed to be stored under.
+ *
+ * Only the types VitNode itself accepts are listed. Anything absent falls
+ * through to {@link ACTIVE_CONTENT_EXTENSIONS} below, which is the conservative
+ * half of the same rule.
+ */
+const EXTENSIONS_BY_MIME: Record<string, readonly string[]> = {
+  "application/json": [".json"],
+  "application/pdf": [".pdf"],
+  "application/zip": [".zip"],
+  "audio/mpeg": [".mp3"],
+  "audio/ogg": [".ogg"],
+  "audio/wav": [".wav"],
+  "image/avif": [".avif"],
+  "image/gif": [".gif"],
+  "image/jpeg": [".jpg", ".jpeg"],
+  "image/png": [".png"],
+  "image/svg+xml": [".svg"],
+  "image/tiff": [".tif", ".tiff"],
+  "image/webp": [".webp"],
+  "text/csv": [".csv"],
+  "text/plain": [".txt"],
+  "video/mp4": [".mp4"],
+  "video/webm": [".webm"],
+};
+
+/**
+ * Extensions a browser runs, rather than displays, when it fetches them from the
+ * origin that stored them.
+ *
+ * Uploads are served from the site's own origin, so a stored `.html` is not an
+ * attachment - it is a page on the site, with the site's cookies and the site's
+ * API in reach.
+ */
+const ACTIVE_CONTENT_EXTENSIONS = new Set([
+  ".asp",
+  ".aspx",
+  ".cgi",
+  ".cjs",
+  ".htaccess",
+  ".htm",
+  ".html",
+  ".jre",
+  ".js",
+  ".jsp",
+  ".jspx",
+  ".jsx",
+  ".mjs",
+  ".phar",
+  ".php",
+  ".php3",
+  ".php4",
+  ".php5",
+  ".php7",
+  ".phtml",
+  ".pl",
+  ".py",
+  ".rb",
+  ".sh",
+  ".shtml",
+  ".svgz",
+  ".swf",
+  ".xht",
+  ".xhtml",
+  ".xml",
+  ".xsl",
+  ".xslt",
+]);
+
+/** What an extension becomes when it cannot be kept. Nothing executes it. */
+const NEUTRAL_EXTENSION = ".bin";
+
+/** `.png`, but not `.tar.gz`, `..`, `.p h p` or a 300-character one. */
+const WELL_FORMED_EXTENSION = /^\.[a-z0-9]{1,16}$/;
+
+/**
+ * The extension a file may actually be *stored* under.
+ *
+ * Both halves of an upload arrive from the client: the browser sends the media
+ * type in the multipart part, and the file name next to it. Nothing made them
+ * agree. Taking the extension straight off the name - which is what this used to
+ * do - meant a file announced as `image/gif`, and accepted as one, could be
+ * written to disk as `payload.html`; served back from the site's own origin it
+ * is a page, not a picture, and script in it runs with the reader's session.
+ *
+ * So the media type decides. When it is one VitNode knows, the extension has to
+ * be one of that type's own, and is replaced by its canonical one when it is
+ * not. When the type is unknown there is nothing to check against, and the rule
+ * narrows to the thing that actually causes harm: an extension the browser would
+ * execute is replaced by {@link NEUTRAL_EXTENSION}.
+ *
+ * `.svg` is deliberately still storable - it is an image type a CMS has every
+ * reason to accept - and an SVG can carry script. Neutralising it is the serving
+ * layer's job, via the `Content-Security-Policy: sandbox` and `nosniff` headers
+ * on the uploads mount, because those cover HTML that gets stored some other way
+ * too.
+ */
+export const safeStorageExtension = (
+  extension: string,
+  mimeType?: null | string,
+): string => {
+  const normalized = extension.toLowerCase();
+  const wellFormed = WELL_FORMED_EXTENSION.test(normalized) ? normalized : "";
+
+  const type = mimeType?.toLowerCase().split(";")[0]?.trim();
+  const allowed = type ? EXTENSIONS_BY_MIME[type] : undefined;
+
+  if (allowed) {
+    return allowed.includes(wellFormed) ? wellFormed : allowed[0];
+  }
+
+  if (!wellFormed || ACTIVE_CONTENT_EXTENSIONS.has(wellFormed)) {
+    return NEUTRAL_EXTENSION;
+  }
+
+  return wellFormed;
+};
+
 /**
  * Collision-free stored file name: a random UUID keeps the original extension
  * but discards the user-provided name, so no lookups or races are needed. Pass
  * `extension` (including the leading dot) to override the extension, e.g. when
  * an image has been converted to a different format.
+ *
+ * The extension that comes out is always one {@link safeStorageExtension} allows
+ * for `mimeType`, whichever of the two it started from - the caller-supplied
+ * override is server-derived and passes unchanged, and the one read off
+ * `originalName` is the client's and is checked.
  */
 export const generateStorageFileName = (
   originalName: string,
   extension?: string,
+  mimeType?: null | string,
 ): string => {
-  return `${randomUUID()}${extension ?? getFileExtension(originalName)}`;
+  const chosen = extension ?? getFileExtension(originalName);
+
+  return `${randomUUID()}${safeStorageExtension(chosen, mimeType)}`;
 };
 
 export const buildStorageKey = ({
diff --git a/packages/vitnode/src/lib/config.ts b/packages/vitnode/src/lib/config.ts
index 9946d5186..b85dad661 100644
--- a/packages/vitnode/src/lib/config.ts
+++ b/packages/vitnode/src/lib/config.ts
@@ -6,6 +6,25 @@
 export const INSECURE_DEFAULT_CRON_SECRET =
   "default-cron-secret-change-in-production";
 
+/**
+ * Every `CRON_SECRET` value that is published somewhere, and therefore is not a
+ * secret at all.
+ *
+ * More than one, because a value being *written down in this repository* is what
+ * makes it worthless - and the fallback above is not the only one that is. The
+ * scaffolded `.env.example` ships `your-secure-cron-secret-key`, which reads
+ * like a placeholder and works like a password, so an install that copied the
+ * file and never edited that line is exactly as open as one that set nothing.
+ *
+ * `cronAuthMiddleware` refuses production requests while any of these is in use.
+ */
+export const INSECURE_CRON_SECRETS: readonly string[] = [
+  INSECURE_DEFAULT_CRON_SECRET,
+  "your-secure-cron-secret-key",
+  "changeme",
+  "secret",
+];
+
 /**
  * The origin the page itself was served from, when there is one.
  *
diff --git a/packages/vitnode/src/tanstack/i18n/request.test.ts b/packages/vitnode/src/tanstack/i18n/request.test.ts
new file mode 100644
index 000000000..7a2aea5dc
--- /dev/null
+++ b/packages/vitnode/src/tanstack/i18n/request.test.ts
@@ -0,0 +1,71 @@
+import { describe, expect, it } from "vitest";
+
+import { createLocaleRouting } from "@/lib/i18n/locale-routing";
+
+import { handleLocaleRequest } from "./request";
+
+const localeRouting = createLocaleRouting({
+  defaultLocale: "en",
+  locales: ["en", "pl"],
+});
+
+const planFor = (path: string) =>
+  handleLocaleRequest(
+    new Request(`https://site.example${path}`),
+    localeRouting,
+  );
+
+/** Where a browser would actually end up following the plan's redirect. */
+const destinationOf = (path: string): string | undefined => {
+  const location = planFor(path).redirect?.headers.get("location");
+  if (location === null || location === undefined) return undefined;
+
+  return new URL(location, "https://site.example").href;
+};
+
+describe("handleLocaleRequest", () => {
+  it("canonicalises the default locale away", () => {
+    expect(destinationOf("/en/discover")).toBe("https://site.example/discover");
+  });
+
+  it("keeps the query string and hash", () => {
+    expect(destinationOf("/en/discover?a=1#top")).toBe(
+      "https://site.example/discover?a=1#top",
+    );
+  });
+
+  it("strips a locale prefix from an ignored path", () => {
+    expect(destinationOf("/pl/admin")).toBe("https://site.example/admin");
+  });
+
+  it("leaves a correctly-spelled URL alone", () => {
+    expect(planFor("/discover").redirect).toBeUndefined();
+  });
+
+  describe("never redirects off this origin", () => {
+    // `//evil.example` in a `Location` header is not a path - it is a
+    // protocol-relative URL, and everything after the two slashes is read as a
+    // host. Stripping the `/en` off `/en//evil.example` produced exactly that,
+    // so the site answered a request for one of its own URLs with a permanent
+    // redirect to somebody else's: a phishing link hosted on the real domain.
+    it.each([
+      "/en//evil.example",
+      "/en//evil.example/path",
+      "/en///evil.example",
+      "/en/\\/evil.example",
+      "/en/\\\\evil.example",
+    ])("%s stays here", path => {
+      const destination = destinationOf(path);
+
+      if (destination === undefined) return;
+
+      expect(new URL(destination).origin).toBe("https://site.example");
+    });
+
+    it("keeps the path it was redirecting to", () => {
+      expect(destinationOf("/en//evil.example/path")).toBe(
+        "https://site.example/evil.example/path",
+      );
+    });
+  });
+});
diff --git a/packages/vitnode/src/tanstack/i18n/request.ts b/packages/vitnode/src/tanstack/i18n/request.ts
index cf8e2eac5..7931d26a1 100644
--- a/packages/vitnode/src/tanstack/i18n/request.ts
+++ b/packages/vitnode/src/tanstack/i18n/request.ts
@@ -106,7 +106,14 @@ export const handleLocaleRequest = (
   if (redirectTo === undefined) return setCookie ? { setCookie } : {};
 
   const target = new URL(url);
-  target.pathname = redirectTo;
+  // Leading slashes collapsed to exactly one. A `Location` of `//example.com` is
+  // not a path at all - it is a *protocol-relative URL*, and the browser reads
+  // everything after the two slashes as a host. Canonicalising `/en//evil.com`
+  // strips the `/en` and leaves precisely that, so the site answered a request
+  // for one of its own URLs with a 308 to somebody else's - a phishing link that
+  // is genuinely hosted on this domain. A backslash is folded in too, because
+  // browsers treat it as a separator here even though the URL parser does not.
+  target.pathname = redirectTo.replace(/^[/\\]+/, "/");
 
   const headers = new Headers({
     location: target.pathname + target.search + target.hash,
diff --git a/packages/vitnode/src/views/admin/views/core/shared/admin-permission-parity.test.ts b/packages/vitnode/src/views/admin/views/core/shared/admin-permission-parity.test.ts
index 8c0b2d85f..e0fde7c0e 100644
--- a/packages/vitnode/src/views/admin/views/core/shared/admin-permission-parity.test.ts
+++ b/packages/vitnode/src/views/admin/views/core/shared/admin-permission-parity.test.ts
@@ -105,10 +105,11 @@ describe("the scan is reading real declarations", () => {
     ]);
   });
 
-  it("finds the three roles routes that declare one", () => {
+  it("finds the four roles routes that declare one", () => {
     expect([...declarationsIn("roles").keys()]).toEqual([
       "create.route.ts",
       "delete.route.ts",
+      "show.route.ts",
       "update.route.ts",
     ]);
   });
@@ -157,6 +158,7 @@ describe("the roles screen names the API's own permissions", () => {
 
   it.each([
     ["create.route.ts", "create"],
+    ["show.route.ts", "view"],
     ["update.route.ts", "edit"],
     ["delete.route.ts", "delete"],
   ] as const)("%s is %s", (file, tuple) => {
@@ -168,6 +170,10 @@ describe("the roles screen names the API's own permissions", () => {
     // role *picker* has to work for an administrator who cannot open the roles
     // *screen*. So `roles.can_view` decides which page is reachable and nothing
     // else, and this says so on purpose rather than by omission.
+    //
+    // `show.route.ts` is *not* covered by that rationale and does declare one:
+    // the picker reads `/list`, and one role's full record is the edit screen's
+    // read and nobody else's.
     expect(declared.has("list.route.ts")).toBe(false);
     expect(ADMIN_ROLE_PERMISSIONS.view).toEqual({
       module: "roles",
diff --git a/packages/vitnode/src/vitnode.config.ts b/packages/vitnode/src/vitnode.config.ts
index 426c09589..e4818aa9a 100644
--- a/packages/vitnode/src/vitnode.config.ts
+++ b/packages/vitnode/src/vitnode.config.ts
@@ -2,6 +2,7 @@ import type { drizzle } from "drizzle-orm/postgres-js";
 import type { IRateLimiterOptions } from "rate-limiter-flexible";
 
 import type { CacheConfig } from "./api/lib/cache";
+import type { TrustProxyConfig } from "./api/lib/client-ip";
 import type { CronAdapter } from "./api/lib/cron";
 import type { BuildPluginApiReturn } from "./api/lib/plugin";
 import type { AIConfig } from "./api/models/ai";
@@ -99,6 +100,17 @@ export interface VitNodeApiConfig {
   };
   cron?: CronAdapter;
   dbProvider: ReturnType<typeof drizzle>;
+  /**
+   * Publishes the OpenAPI document at `/swagger/doc` and Swagger UI at
+   * `/swagger`.
+   *
+   * Defaults to on in development and **off** in production. The document names
+   * every route, parameter and response shape the install has, the admin tree
+   * included, and it is served without authentication - which is a map of the
+   * attack surface handed to anyone who asks. Turn it on deliberately, and put
+   * something in front of it if the install is public.
+   */
+  docs?: { enabled?: boolean };
   email?: {
     adapter?: EmailApiPlugin;
     logo?: DefaultTemplateEmailProps["templateProps"]["logo"];
@@ -123,6 +135,16 @@ export interface VitNodeApiConfig {
    * web and the API together, point this and `buildConfig` at the same object.
    */
   i18n?: VitNodeApiI18nConfig;
+  /**
+   * Largest request body the API will read, in bytes. Defaults to 25 MB.
+   *
+   * The outer wall, not the upload rule: a Content Engine file field has its own
+   * `maxBytes` and is checked before a byte reaches storage. This exists because
+   * without it nothing bounded a body at all, and `POST /sign_in` buffers its
+   * JSON and then runs scrypt on it - memory and CPU whose size an
+   * unauthenticated caller was choosing.
+   */
+  maxBodySize?: number;
   metadata: VitNodeMetadata;
   plugins: BuildPluginApiReturn[];
   rateLimiter?: Omit<IRateLimiterOptions, "keyPrefix">;
@@ -166,6 +188,27 @@ export interface VitNodeApiConfig {
       webp?: boolean;
     };
   };
+  /**
+   * How many reverse proxies stand between the internet and this API.
+   *
+   * Left unset, no forwarded header is believed at all and the client address is
+   * the socket's - the one thing a caller cannot choose for itself. That is the
+   * right answer when the API is reached directly, and the only safe default:
+   * `X-Forwarded-For` is a *request* header, so trusting it unconditionally lets
+   * every caller pick their own rate-limit bucket and their own line in the
+   * audit trail.
+   *
+   * Set it to the number of proxies actually in front of the app - `true` means
+   * one, the ordinary nginx / Traefik / platform-edge deployment - and the
+   * address that proxy observed is used instead. The count is what makes the
+   * header trustworthy: it is read that many entries from the *right*, so
+   * anything a client wrote itself stays to the left of the answer and is
+   * stepped over rather than believed.
+   *
+   * Getting it too high is the failure worth avoiding: it reaches past the
+   * entries real proxies appended and back into client-supplied text.
+   */
+  trustProxy?: TrustProxyConfig;
 }
 
 let registeredVitNodeConfig: undefined | VitNodeConfig;