T09 · Insecure Skill Coding Practices
- Location
SKILL.md:422- Finding
JWT Disclosure Through SSE Query Parameters
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:422
Vulnerability Type: Bearer token exposure through URL query parameters
Risk Level: MediumVulnerable Code
typescript // Auth: JWT via query param (EventSource doesn't support headers)Technical Analysis
The Skill explicitly recommends transmitting a JWT in the query string of an SSE endpoint. Query parameters are unsuitable for bearer credentials because complete URLs may be retained by browser history and captured by reverse-proxy access logs, application logs, observability platforms, analytics systems, and error reports.
Anyone who obtains a valid JWT from one of these locations may replay it against the SSE endpoint until the token expires or is revoked. TLS protects the URL while it is in transit, but it does not prevent endpoint infrastructure or client software from recording it.
Attack Path
- An authenticated client opens an SSE connection using a URL such as
/events?token=<JWT>. - A browser, reverse proxy, application server, monitoring agent, or log aggregation service records the requested URL.
- An attacker or insufficiently privileged operator gains access to the resulting history, telemetry, or log entry.
- The attacker extracts the bearer token from the query string.
- The attacker submits the token to the SSE endpoint before it expires.
- If the server does not impose additional audience, scope, replay, or revocation controls, the attacker receives the victim's authenticated event stream.
Impact Assessment
Successful exploitation can provide unauthorized access to user-specific real-time events. Based on the documented event types, exposed information may include trade status, transaction hashes, strategy lifecycle events, detected signals, scanner activity, price updates, and AI decisions.
The immediate scope is the authorization granted to the JWT for the SSE service. If the same JWT is accepted by other API endpoints, token replay ...[truncated 163 chars]
- An authenticated client opens an SSE connection using a URL such as
- Remediation
View remediation
Remediation Suggestions
- Authenticate native
EventSourceconnections with a same-site session cookie configured withHttpOnly,Secure, and an appropriateSameSitepolicy. - If cookie authentication is unsuitable, exchange the primary session token for a single-use, narrowly scoped SSE ticket:
- Limit its audience to the SSE endpoint.
- Bind it to the intended user and permitted event types.
- Give it a very short expiration period.
- Invalidate it immediately after connection establishment.
- Do not place reusable access or refresh tokens in URLs.
- Configure reverse proxies, application servers, analytics tools, and observability systems to redact query strings and authorization data.
- Validate token audience, issuer, expiration, scope, and revocation state on every connection.
- Reauthorize subscriptions server-side so clients cannot request another user's channels or event types.
- Ensure error responses, reconnect logic, and diagnostic telemetry never reproduce authentication material.
- Authenticate native