Credential access and network transmission in one file
Expected behavior · high confidence
This app logs you in and keeps a session token, and whenever it loads or posts game chat it includes that token so the server knows the request is yours. The alarm was raised only because reading the token and making a web request happen in the same file. The requests go solely to the app's own server, which is exactly where a login token is supposed to go. Nothing is sent to anyone else, and no malicious behavior is present.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The scanner flagged co-location of a credential read and a network call, but the actual data flow is the standard authenticated-client pattern. A helper reads the session token from the app's auth store and attaches it as a bearer authorization header on requests to adventure chat endpoints under a relative same-origin API base. All observed requests target the application's own backend, matching the project's stated purpose of a browser RPG client talking to its own server. There is no third-party destination, alternate host, encoded or obfuscated payload, dynamic URL construction from external input, or transmission of the token anywhere other than the issuer backend. Sending a bearer token to the API that issued it is the token's intended use, not exfiltration.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- tavernkeeper 5
- Rule
- credential-exfiltration
- File role
- production
- Source
- frontend/src/composables/useGameSocket.ts:200