fix(clerk-js): discard a stored session token that was never a mint - #9358
Merged
zourzouvillys merged 1 commit intoAug 7, 2026
Merged
Conversation
`validateToken` documented that a value which could not have come from a mint of ours is discarded, but only checked type, length and expiry — so a corrupt or truncated store entry counted as fresh and suppressed acquisition until it expired, up to the lifetime ceiling. This is hygiene, not a security boundary, and is deliberately not framed as one: only the backend can tell a real token from a well-formed forgery, and anything that can write the store can send the same values to the API directly. What it buys is that a broken entry starts a fresh run immediately. The shape is matched version-agnostically. Pinning it to the current version would mean an SDK rejecting a token the backend had minted ahead of it, and re-running the loader on every page load until the SDK caught up — a test guards against that tightening.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #9299 — this targets
theo/js-session-token-clean, so the diff under review is the two files here.Follow-up to #9299 (comment).
validateTokendocuments that a value which could not have come from a mint of ours is discarded, but only checked type, length and expiry. A corrupt or truncated store entry therefore counted as fresh and suppressed acquisition until it expired.This is hygiene, not a security boundary, and the code comment says so rather than implying otherwise. Only the backend can tell a real token from a well-formed forgery, and anything that can write the store can send the same values to the API directly — so what this closes is a reliability gap (a broken entry costing a real user their token for its remaining lifetime), not an attack. Server-side handling of unverifiable tokens is already covered separately.
The shape is matched version-agnostically (
^v\d+\.…). Pinning it to the current version would mean this SDK rejecting a token the backend had minted ahead of it, and re-running the loader on every page load until the SDK caught up — the second test guards against that tightening.Verification
Both new tests confirmed non-vacuous:
ignores a planted value that could never have been a mint— fails on the unpatched validator, passes with it.reuses a mint whose version this build predates— fails if the regex is pinned to^v1\., passes with^v\d+\..protectSession+protect+fapiClientsuites: 98 passed, 1 skipped, 4 todo. Lint and typecheck are unchanged from the base — the single lint warning and the twoTS6059errors both reproduce ontheo/js-session-token-cleanuntouched.No changeset: this folds into the feature changeset already on #9299.