Repository navigation
fix: trust only own entries in the session token store - #448
Merged
santoshyadavdev merged 1 commit intoNov 4, 2026
Merged
Conversation
devframe's verifyAuthToken trusts a token when `trusted[token]` is truthy. The store is an ordinary object, so inherited keys such as `constructor` or `toString` pass as tokens, and any client could become trusted through the auth handshake or the `devframe_auth_token` connection parameter without the one-time code. devframe 1.3.2 has the same check. At startup the devframe's setup now rebuilds `trusted` as a null-prototype object holding only own entries that are token records. devframe's storage keeps the prototype on later copies, so exchanges, revokes and pruning leave it prototype-free. This lives in the published package, so apps that install it are covered without a dependency patch.
Contributor
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 56 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
|
View your CI Pipeline Execution ↗ for commit aa24b14
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
🚀 Deploying Preview to Cloudflare 🚀Preview Deployments by commit
|
santoshyadavdev
deleted the
santoshyadavdev-fix-devframe-token-prototype-auth
branch
November 4, 2026 05:55
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
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.
What and why
devframe's
verifyAuthTokentrusts a client whentrusted[token]is truthy. The token store is an ordinary object, so a token such asconstructor,__proto__ortoStringmatches an inherited property. Any client could become trusted, through theanonymous:devframe:authhandshake or thedevframe_auth_tokenconnection parameter, without the one-time code (CWE-287). devframe 1.3.2, the latest release, has the same check, so upgrading doesn't fix it, and a pnpm patch wouldn't reach apps that install our package.The fix is in the published package. A new
hardenTokenStore()inauth-store.tsruns when the server starts, fromexpireAuthTokens(), which the devframe's setup already calls for the hub, the Vite plugin and the CLI. It rebuildstrustedas an object with no prototype. It keeps only the entries stored on the object itself that are token records: an object with a numerictimestamp, and anauthTokenthat matches the key when the record has one. devframe's storage (immer) keeps the null prototype on later copies, so code exchanges, revokes and pruning leave the store prototype-free.How it was verified
pnpm commit:check(commit messages follow the guidelines): passedpnpm format:check: not run in full.prettier --checkon the changed files passedpnpm typecheck(includes thengctemplate checks): passedpnpm test,pnpm test:devtoolsandpnpm test:panel: onlypnpm test:devtoolswas run, and it passed (3648 passed, 4 skipped).pnpm testandpnpm test:panelwere not run; this change doesn't touchapp/pnpm skills:check(when.claude/changed): N/Aapps/docsupdated andpnpm docs:buildpasses (when behavior, options, UI labels or agent tools changed), or theno-docslabel added with the reason below:security.mdupdated;pnpm docs:buildnot runpnpm extension:buildandextension/uicommitted (whenapp/changed): N/ANew tests in
auth-guard.test.ts:hardenTokenStore.constructor,__proto__,toStringandhasOwnPropertyare not trusted, and a token issued through the one-time code still reconnects. Without the fix this test fails.Screenshots
N/A
Notes for reviewers
auth.jsonthat have no numerictimestamp, or whoseauthTokendoesn't match their key. Records without anauthTokenfield are kept.globalThis. The hub tests now clear it after each test so they don't affect each other.