Description
The context and chat API has two intended layers of protection: a shared application-wide token required on every request, and a second, per-session secret meant to restrict two specific endpoints exporting a session and viewing full session context to their rightful owner. Neither layer protects user data the way it's supposed to.
Root Cause
The per-session secret is generated by the backend and handed back once, when a session starts. No client code web or desktop ever reads that value out of the response and stores it for later use. Every subsequent request that should include it either omits it or sends it empty, and an empty value can never match the real secret, so the two endpoints meant to check it reject every legitimate caller, always. Separately, the rest of the API reading and writing browsing context, stopping or clearing sessions, and the entire AI chat history subsystem was never given any per-session check to begin with; it relies solely on the shared application token, which is a real secret in the packaged desktop app but is baked directly into the public JavaScript bundle in a browser-based deployment.
Impact
The two endpoints meant to have real per-session protection are unusable by anyone, legitimate or not. Meanwhile, every other endpoint handling the same sensitive browsing history and chat data has no ownership check at all, so anyone holding the shared token can read, overwrite, or delete another person's session just by knowing their session identifier and in a hosted deployment, that token isn't meaningfully secret to begin with.
Proposed Fix
Treat this as one authorization gap, not two unrelated bugs. The fix needs to actually capture the per-session secret when a session starts and carry it through every later request for that session, across both the web and desktop paths, and then extend that same ownership check consistently to every session- and chat-scoped endpoint rather than the two that currently attempt it. A test that starts two independent sessions and confirms neither can touch the other's data would guard against this regressing.
Labels: type:security, GGScoc
Description
The context and chat API has two intended layers of protection: a shared application-wide token required on every request, and a second, per-session secret meant to restrict two specific endpoints exporting a session and viewing full session context to their rightful owner. Neither layer protects user data the way it's supposed to.
Root Cause
The per-session secret is generated by the backend and handed back once, when a session starts. No client code web or desktop ever reads that value out of the response and stores it for later use. Every subsequent request that should include it either omits it or sends it empty, and an empty value can never match the real secret, so the two endpoints meant to check it reject every legitimate caller, always. Separately, the rest of the API reading and writing browsing context, stopping or clearing sessions, and the entire AI chat history subsystem was never given any per-session check to begin with; it relies solely on the shared application token, which is a real secret in the packaged desktop app but is baked directly into the public JavaScript bundle in a browser-based deployment.
Impact
The two endpoints meant to have real per-session protection are unusable by anyone, legitimate or not. Meanwhile, every other endpoint handling the same sensitive browsing history and chat data has no ownership check at all, so anyone holding the shared token can read, overwrite, or delete another person's session just by knowing their session identifier and in a hosted deployment, that token isn't meaningfully secret to begin with.
Proposed Fix
Treat this as one authorization gap, not two unrelated bugs. The fix needs to actually capture the per-session secret when a session starts and carry it through every later request for that session, across both the web and desktop paths, and then extend that same ownership check consistently to every session- and chat-scoped endpoint rather than the two that currently attempt it. A test that starts two independent sessions and confirms neither can touch the other's data would guard against this regressing.
Labels:
type:security, GGScoc