fix: close three account-takeover paths found in review

[aquie00t]

Fixes from the /code-review and security passes over eb3c92e..origin/main (the eight feature PRs merged this week). Three of these are account takeover; please merge before the mobile app starts calling this API.

The three that matter

1. A request body could name its own identity

Fastify's default AJV setting strips unknown properties only from schemas that declare additionalProperties: false — and a plain TypeBox object declares nothing, so an unknown key survives validation and arrives in request.body intact. Three handlers spread ...request.body over an identity taken from the session, and the spread came last, so the body won:

• POST /devices with {"currentUserId": "<victim's uuid>"} registers the attacker's phone against the victim. From then on every one of the victim's notifications — who followed them, who replied, with the content ids in the deep-link payload and their unread count as the badge — is delivered to the attacker's device. The victim sees nothing: there is no read side on /devices, and their own registration is a separate row.
• PATCH /articles/:id with {"userId": "<victim's uuid>"} rewrites any article on the platform under its real author's byline. UpdateArticleUseCase proves ownership by asking whether the supplied userId owns the article, so the injected value does not fail that check — it satisfies it.
• POST /articles with {"authorId": …} files a draft owned by somebody else, which the above then publishes.

User ids are not secret; GET /profile/:username returns one.

Fixed two ways, because either alone is one refactor from being untrue: AJV now runs with removeAdditional: "all", and the three handlers name their fields instead of spreading over an identity. The article handlers were pre-existing rather than introduced this week — they are fixed here anyway, since the root cause is shared and the outcome is worse.

2. The reuse alarm revoked nothing

RefreshUseCase.execute runs its whole body inside prisma.$transaction. resolveRetry called revokeAllByUserId and then threw — so Prisma rolled the revocation back with the very error that reported it. The response said "All sessions revoked"; the database was untouched.

The outcome was exactly inverted: an attacker who holds a stolen refresh token rotates it once, the victim's own client later presents the token it still holds, and the victim is ejected with a 401 while the attacker's token keeps rotating for its full thirty days. The alarm could be tripped any number of times and never converge.

The transaction now reports a compromise and the revocation runs outside it, on its own connection. The e2e test asserted only the 401 body; it now opens a second session first and asserts that session is dead afterwards, which is the property that was actually missing.

3. OAuth state was not bound to a browser

The state proved that somebody had started a flow on this deployment, not that the browser presenting the callback was that somebody — which is the entire point of state. So the login-CSRF that #278's own comment claims to close still worked: start a flow signed in as yourself, capture the callback URL without following it, get a victim to load it, and the victim's browser finishes the flow and is silently signed in as you. Everything they then write — posts, drafts, direct messages — lands in an account you can read.

The state is now also set as a signed, httpOnly, SameSite=Lax cookie scoped to /api/v1/oauth, and the callback requires it to match before the cache is even consulted.

The rest

• Rotation no longer alarms on a second consecutive retry. The retry path retired the successor without repointing the token the client still holds, so a client that lost two responses in a row was treated as a thief and signed out of every device. It is repointed now; revokedAt is deliberately left alone so repeated retries cannot slide the window forward.
• An in-flight idempotency claim expires in two minutes, not a day. A process that died between the claim and the response left the key answering "still in progress" for twenty-four hours, for a write that never happened.
• A failed Play notification releases its record. It was recorded before the work, so a failure afterwards made Pub/Sub's redelivery look like a duplicate and dropped it silently.
• STRICT keys on the edge address. The app runs trustProxy: true, so request.ip is the left-hand end of a client-written X-Forwarded-For — a caller could hand themselves a fresh login bucket per request. It now prefers CF-Connecting-IP, which Cloudflare overwrites and which cannot be reached around, since the Render subdomain is disabled.
• Three schedulers destroy their task on close instead of dropping the reference and firing against a disconnected Prisma client; deletion survives a failed subscription cancellation; a redirect target that already carries a query string is appended to with &; the Play push secret is compared in constant time; the purchase endpoint answers the badge question through the shared helper rather than a second !== null; and OAUTH_NATIVE_REDIRECT_ALLOWLIST gets back the sync: false a conflict resolution had dropped.

Tests

• Unit, 1536 passing (5 new): the second consecutive retry being served, the grace window not sliding, the edge address winning over the proxied one, and deletion completing when the cancellation throws.
• E2E: tests/e2e/security/mass-assignment.test.ts — an article is filed under the caller and not the id in the body, and an edit dressed in the victim's userId is refused. The OAuth suite now carries the state cookie the way a browser does, plus a case where the state is valid but the cookie is absent. The refresh reuse case asserts a sibling session dies.
• CI sets REFRESH_ROTATION_GRACE_SECONDS=0, so the e2e exercises the alarm; the window itself is unit-tested, where a clock can be moved.
• tsc -p tsconfig.build.json --noEmit, eslint, prettier --check clean.

Not fixed here

A device token can still be moved between accounts on the strength of the token alone. That is the design — it is how a phone handed to a second account stops delivering the first one's notifications — but a token is not a secret, and somebody who obtains one can both silence a victim's phone and choose what appears on its lock screen. Closing it properly needs a device-scoped installation id the app generates and stores in its keystore, so it is app-side work as much as API work. Added to the roadmap rather than rushed in here.

AI Asistan: Opus 5

[github-actions]

🎉 This PR is included in version 1.27.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀