Check whether `sys_session.token` — a live session credential — serializes over the data API (ADR-0100 channel 3 has no read protection)

[os-zhuang]

Status: UNMEASURED. Step one is a measurement, not a fix.

Raised as an out_of_scope_findings item by the #7728 dev (#7728 report), who flagged it as "worth checking first" — i.e. potentially more serious than the card it fell out of. Filed unassigned; assign at the moment you start.

Nothing here has been observed on a running system. The #7728 dev inferred it structurally from the same code paths it measured for sys_api_key.key, and said so plainly. Treat every claim below as a hypothesis with a named place to check it.

The hypothesis

packages/platform-objects/src/identity/sys-session.object.ts:176 declares:

token: ... description: 'Opaque session token — never exposed in UI'

The mechanism that leaked sys_api_key.key — established on code in #7728 — is not field-specific:

• the engine read path never consults hidden (no .hidden reference in engine.ts), so hidden: true does not strip a value from serialization; and
• collectMaskedReadFields (packages/objectql/src/secret-fields.ts:88-96) masks password-typed fields only when the object is not managedBy: 'better-auth'.

sys_session is an auth-subsystem object, so if it carries managedBy: 'better-auth' the masking collector is inert on it too — ADR-0100's channel 3 (auth-subsystem one-way hashes and opaque tokens on plain text columns), which #7728 established has no read protection at all.

⚠️ Do NOT import #7728's framing — this is a different defect if it is one

#7728 is a false-declaration defect: its field claims "never exposed to clients", which is a serialization claim, and it was false.

This field claims "never exposed in UI". That is the narrower claim, and hidden: true does satisfy it. So:

• If token serializes over the data API, the declaration is not thereby false — the defect would be a credential disclosure, argued on its own merits, not on a contradicted description.
• Conversely a "fix the description" option does not exist here, because the description is not the thing that would be wrong.

The reason to rate this potentially above #7728 despite the weaker declaration: sys_api_key.key is a SHA-256 hash — not a usable credential, which is why #7728 was correctly kept public, unembargoed and off target:v17. A session token is the live credential itself. If it serializes to any persona that should not hold it, that is a real disclosure and the severity conversation is a different one.

Step one — measure before anything else

1. Confirm whether sys_session is managedBy: 'better-auth' and whether token is a plain text column.
2. On a real engine: create a session, then GET /api/v1/data/sys_session/{id} and the list endpoint. Does the token value come back, and to which personas? api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728's leak was admin-readable only, because ordinary personas are 403 on the object — establish the equivalent here rather than assuming it matches.
3. Check whether anything legitimately reads token off a data-API response (the verifier using it as a where filter is not a read — that was the distinction that made api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728's strip safe).

"Latent, not live" is a complete and valid outcome. If the value never serializes, say so with the measurement and close the card — do not manufacture a fix for a path nothing exercises.

If it IS live

The fix vehicle is very likely the same one #7728 is parked on — there is currently no field-level mechanism that strips a value from the generic read path (secret encrypts at rest and would break the lookup; password is inert on better-auth objects; FLS is bypassed by system contexts and by admin). #7728's report contains the full elimination and a proposed design awaiting a maintainer ruling.

⛔ Do not build a parallel mechanism. If the measurement says live, report the dependency and stop — the PM will sequence this against #7728's ruling. Two competing masks would be a worse defect than either leak.

⛔ Do not relabel this a security card or embargo it pre-measurement; and do not assume the #7728 severity call transfers, in either direction.

Source

out_of_scope_findings #1 from the #7728 dev report. Sibling finding #2 (sys_account.password, sys-account.object.ts:208, hashed text, same unprotected class, makes no non-exposure claim) is recorded on #7728's escalation rather than filed separately — it has no independent symptom.

[os-zhuang]

Findings-triage route B: promoted — finding → pm:queue (domain:metadata kept as filed).

• Promotion rationale: the card is a bounded measurement with named checkpoints, and the stakes are asymmetric: unlike api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728's SHA-256 hash, sys_session.token would be a live, usable credential if it serializes. The mechanism half is already established on code by api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728 (engine read path never consults hidden; collectMaskedReadFields inert on managedBy: 'better-auth' objects), so the remaining work is exactly the controlled read the card prescribes — cheap, and every day unmeasured is a day a possible credential-disclosure path stays unknown. The card's own discipline (measure first, do not import api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728's false-declaration framing) is the dispatch brief.
• Premise: filed today against 098b629, still the origin/main tip this round.
• Grade escalation path: if the measurement comes back "serializes", the follow-on defect card is target: -class (published-surface credential disclosure) — flag it back to triage same-day rather than waiting a cycle.
• Dedup: api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728 (the api-key sibling) is needs-user-decision and covers a different field/claim; no other card measures sys_session.token.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 5 (domain:metadata seat, huangyiirene term)

• Session: session_01AmES43BMDg4bPrxTdi5q7t
• Branch: claude/issue-7823-session-token-serialization
• Worktree: objectstack-issue-7823 (dedicated)
• Domain: domain:metadata
• File surface: expected read-only. packages/platform-objects/src/identity/sys-session.object.ts (inspection) and the read path it implicates. ⚠️ If the measurement says live, the fix vehicle is blocked (see below) — so a code change is not the expected deliverable.
• Container & model: M ⇒ mode:cloud, model: opus. Bounded in size, but the judgment — whether a live credential serializes, and to which personas — is not.
• Serial constraints cleared: disjoint from this round's siblings. org-override-registry-gate: the field overlay lock is not enforced — an artifact-backed field PUT is accepted 200 (and is inert) #7743 holds packages/metadata-protocol/src/protocol.ts; Setup › Advanced › Signing Keys (JWKS) is a dead nav entry — sys_jwks is API-disabled and a requiredPermissions gate cannot prune it #7544 holds packages/platform-objects/src/apps/setup-nav.contributions.ts + identity/sys-jwks.object.ts. This card's surface (identity/sys-session.object.ts, read-only) intersects neither.

This is a measurement card and it is dispatched as one

⭐ The most likely correct outcome is no code change. Two of its three endings produce no diff:

• latent (the value never serializes) ⇒ report the measurement and the card closes. Complete outcome.
• live ⇒ ⛔ report the dependency and STOP. The card is explicit and this seat endorses it: there is no field-level mechanism today that strips a value from the generic read path (secret encrypts at rest and breaks the lookup; password is inert on managedBy: 'better-auth' objects; FLS is bypassed by system contexts and admin). api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728 carries the elimination and a proposed design awaiting a maintainer ruling — it sits in the decision box right now. ⛔ Do not build a parallel mechanism; two competing masks would be worse than either leak.
• Only a third, unlikely ending — a defect entirely unrelated to api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728's vehicle — produces a diff, and it would need saying explicitly.

The framing trap the card names, carried into the brief

⛔ Do not import #7728's framing. #7728 is a false-declaration defect: its field claims "never exposed to clients" — a serialization claim — and that was false. This field claims "never exposed in UI", which is narrower and which hidden: true does satisfy. So if token serializes, the declaration is not thereby false, and the "fix the description" option does not exist here. The defect would be a credential disclosure, argued on its own merits.

The asymmetry that makes it worth doing now: sys_api_key.key is a SHA-256 hash — not a usable credential, which is why #7728 was correctly left public and off target:v17. A session token is the live credential. ⛔ Do not assume #7728's severity call transfers in either direction, and ⛔ do not relabel or embargo pre-measurement.

Triage's escalation instruction is carried

if the measurement comes back "serializes", the follow-on defect card is target:-class (published-surface credential disclosure) — flag it back to triage same-day rather than waiting a cycle.

That is this seat's action on a live result, not the dev's; the dev's job ends at the measurement and the report.

---

Generated by Claude Code

[huangyiirene]

Measured: LIVE. sys_session.token serializes over the data API as the usable credential — and I replayed it to authenticate as another user.

Measurement only. No code change, no branch pushed, no PR, worktree clean — stopping at the card's gate, because the fix vehicle is the one #7728 is parked on.

Real engine, real driver: bootStack(showcaseStack) (@objectstack/verify, in-process HTTP + sqlite-wasm), against origin/main @ 68a1edb.

1. Per-persona result — the answer is not a yes/no

signIn() returns the bearer token itself, so I had ground truth to compare each serialized value against byte-for-byte.

Persona	Surface	Status	token	Whose token
anonymous	list, ?select=id,token	401	—	fully denied (UNAUTHENTICATED)
admin	GET /data/sys_session	200	PRESENT ×3	own + every other user's
admin	GET /data/sys_session/{own}	200	PRESENT	own
admin	GET /data/sys_session/{another user's}	200	PRESENT	the member's live token, verbatim
admin	?select=id,token	200	PRESENT ×3	all
member	GET /data/sys_session	200	PRESENT ×1	own only
member	GET /data/sys_session/{own}	200	PRESENT	own
member	GET /data/sys_session/{admin's}	404	absent	RECORD_NOT_FOUND — RLS holds
member	?select=id,token	200	PRESENT ×1	own only

These are two different defects and they should not be reported as one.

• Ordinary member — not a disclosure. sys_session_self (using: 'user_id == current_user.id', default-permission-sets.ts) holds on both list and get-by-id; the cross-user fetch is a clean 404. A member sees a credential they already hold as their own bearer. No escalation.
• Platform admin — cross-user live-credential disclosure. Admin reads every other user's session token verbatim, on the default projection and by explicit ?select=token.

2. The disclosed value is a working credential — replay-proven

Ground-truth string equality only proves it's the same string. So I took the member's token exactly as it came back to admin off the data API and used it as a bearer:

STOLEN value === member ground truth ? true

[REPLAY] admin-read member token used as a bearer
 GET /data/sys_session status = 200 (rows = 1, member-scoped)
 GET /auth/get-session status = 200
 authenticated as email = probe-7823-member@verify.test
 => REPLAY AUTHENTICATES = true

This is the line that separates this card from #7728: sys_api_key.key is a SHA-256 hash and is not usable. This value is the credential — replayable directly as Authorization: Bearer <token> to act as that user, with none of the audit trail the platform's sanctioned impersonation path carries (impersonated_by column + better-auth admin plugin). Admin already holds enormous power; the distinction that matters is audited impersonation vs. silent, indefinite session theft that survives after the admin's own rights are revoked.

One nuance inside the "self-only" case, and it is not zero. A member with two devices reads both their own session tokens (sees OWN = true, sees OTHER DEVICE = true, rows = 2). So a single compromised session (XSS, a leaked bearer) can enumerate and capture that user's other live sessions — which is exactly what the object's own revoke_my_other_sessions / "Sign out other devices" affordance exists to protect.

3. Both PM mechanism hypotheses hold on origin/main — with one refinement that matters

• ✅ sys_session is managedBy: 'better-auth' (sys-session.object.ts:23), and token is a plain Field.text (:176, hidden: true, readonly: true, required: true).
• ✅ The engine read path never consults hidden — zero .hidden references in engine.ts; all 6 hidden mentions are the __search companion (The __search companion column, declared client-invisible, is echoed in every record body #7642) or unrelated comments. hidden: true does not strip a value from serialization.
• ⚠️ Refinement on collectMaskedReadFields (secret-fields.ts): the card frames the better-auth exemption as the reason the collector is inert here. True, but it is the second barrier, not the first. The collector only ever collects secret and password types — token is text, so it is not collected regardless of managedBy. This matters for the fix conversation: retyping token to password would not work either, because the better-auth exemption then catches it. Two independent barriers, and ADR-0100 channel 3 has no read protection at all — exactly as api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728 established.
• ✅ Reads are genuinely served: enable.apiMethods: ['get', 'list'], apiEnabled: true (:231-239).

4. Nothing reads token off a data-API response (the #7728 distinction)

Consumer	Reads token from a response?	Evidence
resolve-authz-context.ts:135	No	sessionData?.session?.token comes from better-auth's getSession(headers), not the data API — the same "not a read" distinction that made #7728's strip safe
All three listViews (mine, all_sessions, revoked)	No	token is a column in none of them (:82-115)
sys_presence, sys_oauth_*_token	No	reference sys_session by id lookup, never token
Client SDK / dashboards	No	sys_session_metrics aggregates counts only

Same caveat #7728 recorded honestly: I could not grep the console SPA (packages/console vendors no dist; built from objectui). Structurally token is in no listView, so a UI read would have to be hand-written.

So the description is accurate. hidden: true does satisfy "never exposed in UI". As the card predicted, the "fix the description" option does not exist here — the declaration is not what's wrong. This is a credential-disclosure finding on its own merits.

5. ⛔ Stopping here — the vehicle is #7728's, and it is in the decision box

I did not build a mechanism. Every elimination in #7728's report re-verified and still holds: secret encrypts at rest and would break the session lookup; password is inert on better-auth objects (and now doubly so, per §3); FLS is bypassed by system contexts and by admin — and admin is precisely the persona the leak is against here.

One piece of new evidence that strengthens #7728's proposed design, which that report did not have: a hard-coded precedent for stripping a value from the generic read path already exists at the exact choke point the proposed flag would use. stripSearchCompanionFromRead (#7642, engine.ts:4759) strips the hidden __search companion from find results — same call site as maskSecretFields, same post-hook position, with a measured carve-out for system callers that name it by projection. So the claim "there is no field-level mechanism" is precise, but "the engine cannot strip a column from the read path" is not true — it does, today, for one column. #7728's design is generalizing an established pattern rather than inventing one, and stripSearchCompanionFromRead also demonstrates the ?select= bypass must be closed explicitly (a non-system caller does not keep the column even by name) — which my ?select=id,token measurement shows would be required here too.

For the PM, not for me to decide

Per the triage escalation instruction, the measurement came back serializes, so this is flagged back same-day. Two things I'd ask be carried into that call, both from the measurement rather than from #7728's framing:

1. The severity is admin-cross-user, not "any authenticated caller". Anonymous is 401, member is self-only. That is narrower than a worst case — but the value is a live, replayable credential, which is worse in kind than api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728's hash.
2. The self-scoped case still lets one compromised session capture that user's other sessions.

I have not relabelled, embargoed, or applied any target: label — that is the PM's call.

Reproduction: the probe is two throwaway *.dogfood.test.ts files against bootStack(showcaseStack), deleted after measuring (worktree left clean, git status = 0). The whole finding reproduces in four lines: sign in as admin, sign up a member, GET /api/v1/data/sys_session as admin, and replay any token from the response body as a bearer against /api/v1/auth/get-session.

---

Generated by Claude Code