Dripster: Keeping API Keys Out of WebSocket URLs

The answer in 30 seconds

Dripster directly engaged Zealynx for a ten-day penetration test of its NestJS and Prisma backend, which coordinated off-chain prediction-market operations and signed value-changing payloads for an on-chain vault.[1][3]

The pivotal issue was not broken cryptography. Two WebSocket gateways accepted long-lived partner API keys in the handshake URL, and the public integration guidance recommended that path. A valid key could therefore be copied into access logs, reverse-proxy logs, and browser history before the gateway authenticated the connection. Zealynx traced the credential across the complete handshake and documentation path. The public resolution records that query-string support was removed and authentication now requires the auth payload or Authorization header.[2]

This is a technical engagement narrative, not a customer transformation story. Public evidence supports the reviewed mechanism and recorded fix, but not exploitation, credential misuse, production deployment, monetary exposure, or private customer outcomes.

The buyer decision: can partners authenticate without leaking the credential?

Dripster's backend exposed partner-facing WebSocket streams as part of a wider prediction-market system. The reviewed API coordinated position lifecycle operations and held signing authority over value-changing on-chain actions. Dimes currently describes its product as embedded leverage infrastructure for prediction-market front ends, including terminals, applications, bots, and command-line tools.[1][4]

For an integration platform, authentication must work across different client stacks. WebSocket clients do not all expose handshake headers equally conveniently, which makes a URL query parameter attractive. The security decision is whether that convenience justifies sending a reusable secret through a channel routinely recorded by infrastructure.

The invariant under review was:

Long-lived partner API keys must cross the WebSocket handshake only through an authentication channel that ordinary URL telemetry does not retain.

The dangerous assumption: encrypted transport makes every URL field private

TLS encrypts a WebSocket handshake in transit, but it does not stop the application server, reverse proxy, observability layer, or local browser history from retaining the requested URL. A secret can therefore arrive over an encrypted connection and still spread into systems that were never intended to hold credentials.

The reviewed extractApiKey() logic checked client.handshake.query.apiKey first. Only when the query parameter was absent did it inspect the Authorization header. The report also records that the partner integration documentation recommended the query-string form, making the weaker carrier an expected route rather than an obscure fallback.[2]

This created a connected failure path:

1. A partner placed its reusable API key in wss://…?apiKey=….
2. The WebSocket upgrade request carried the full URL through edge and application infrastructure.
3. Any standard component that retained request URLs could retain the credential too; the public evidence establishes this exposure path, not that a specific production log actually stored a key.
4. Operators or systems with legitimate log access could then encounter a live secret outside the authentication boundary.
5. The same key could be replayed wherever its permissions remained valid.

The finding did not claim that logs were accessed or a key was abused. It established that the supported authentication design copied secrets into channels with broader retention and access patterns than an authentication header.

How Zealynx tested the invariant

1. Trace every accepted credential carrier

The assessment followed the WebSocket handshake into extractApiKey() rather than stopping at the presence of authentication. That showed both accepted carriers and their precedence: query parameter first, then Authorization header.[2]

2. Follow the secret beyond application code

The review considered where the handshake URL could persist before and after authentication: access logs, reverse-proxy logs, and browser history. This widened the trust boundary from one gateway method to the operational systems that observe requests.[2]

3. Compare implementation with the integration guidance

A secure alternative already existed in code, but the public partner documentation recommended the query-string route. Reviewing documentation alongside implementation showed that partner behavior was likely to exercise the weaker path.[2]

4. Verify removal rather than a new preference order

Reordering the checks would not close the leak because clients could still send a key in the URL. The recorded fix removed query-string support entirely and requires the auth payload or Authorization header.[2]

Before, intervention, and verified after-state

The finding is marked fixed. That status applies to the reviewed resolution; it does not establish when or where the changed code was deployed.[2]

Why removing the carrier is stronger than warning partners

Documentation alone would leave the server capable of accepting an unsafe request. A forgotten client, copied code sample, or library default could continue to put credentials in URLs.

Removing the query-string carrier changes the backend contract: integrations must use an authentication-specific channel. This turns secure handling from optional guidance into an enforced property. Where a client cannot set suitable headers, a short-lived, single-use ticket exchange can avoid placing the long-lived key itself in the URL; the public finding lists that as an alternative design, not as the implemented remediation.[2]

A reusable review model for WebSocket authentication

Teams operating authenticated WebSocket APIs should test the entire credential lifecycle:

1. Issuance: Is the credential long-lived, scoped, revocable, and shown only when needed?
2. Carrier: Can clients place it in a URL, path, query parameter, cookie, auth payload, or header?
3. Precedence: If several carriers are accepted, which one wins when they disagree?
4. Retention: Which proxies, load balancers, application logs, analytics tools, and browser surfaces record each carrier?
5. Documentation: Do examples direct integrators toward the safest supported method?
6. Rejection: Does the server reject insecure carriers rather than merely preferring a safer one?
7. Rotation: Can a potentially exposed partner key be revoked without disrupting unrelated tenants?
8. Testing: Do integration tests assert that URL-based credentials are rejected?

The transferable lesson is that authentication success is not enough. A secure handshake must also prevent reusable credentials from crossing observability surfaces that routinely retain request URLs.

Impact and evidence limits

The strongest supportable outcome is finding-specific: the recorded remediation removed the demonstrated route that placed reusable partner API keys in WebSocket URLs.[2]

The public evidence does not establish that any key appeared in a particular production log, that anyone accessed or replayed a leaked key, that the fix was deployed, or that funds or positions were exposed. The wider assessment reported 21 findings, with 13 fixed and eight acknowledged, but those totals do not prove the entire backend or later versions are secure.[1][3]

Evidence and attribution

• Zealynx-authored canonical record: the public report and assessment page identify Dripster as the client, Zealynx as the provider, the ten-day backend assessment, scope, and remediation totals.[1][3]
• Finding-specific evidence: F-2026-0003 documents the accepted credential carriers, leakage surfaces, recommendation, resolution, and fixed status.[2]
• Attribution class: direct Zealynx engagement. No public evidence identifies a delivery partner.
• Evidence cutoff: the April 29, 2026 report and its recorded remediation state.[3]
• Publication authority: under Zealynx's case-study policy, its public report for Zealynx-delivered work is sufficient authority for this bounded technical narrative.
• Limitations: provider-authored evidence supports technical scope and recorded remediation, but not customer sentiment, production deployment, business impact, or continuing assurance.

Building an authenticated real-time API?

Zealynx can test credential issuance, WebSocket handshakes, tenant authorization, logging boundaries, and the backend actions that connect off-chain APIs to on-chain value. Review the application security assessment approach, explore the security methodology, or request a scoped backend review.

Frequently asked questions

Why are API keys in WebSocket URLs risky if the connection uses TLS?

TLS protects the handshake in transit. It does not prevent servers, proxies, observability systems, or browser history from recording the requested URL, which can copy the key into additional storage and access boundaries.

Was the API key visible to every internet user?

No. The finding shows that a partner who used the supported query-string method could expose its own key to URL-retaining systems. The public evidence does not show public disclosure or confirmed misuse.[2]

Why not keep query authentication as a fallback?

A fallback remains an accepted security boundary. As long as the backend accepts a reusable key in the URL, old clients and copied examples can continue to leak it. Removing the carrier makes unsafe use fail closed.

What if a WebSocket client cannot set an Authorization header?

The finding recommends a short-lived, single-use ticket exchange as an alternative when query transport is unavoidable. The long-lived partner API key should not become the URL token.[2]

How was the finding fixed?

The public resolution states that query-string support was removed and the auth payload or Authorization header is now required.[2]

Does the fix prove the Dripster backend is secure?

No. The assessment was point-in-time and scope-limited. The public record reports 21 findings with mixed remediation states; this narrative addresses one credential-carrier path.[1][3]

Sources

[1] https://zealynx.io/audits/dripster/offchain-pentest-q2-2026 — Dripster Backend Pentesting audit record [2] https://zealynx.io/audits/dripster/offchain-pentest-q2-2026/findings/F-2026-0003 — API key exposed in WebSocket query parameters [3] https://raw.githubusercontent.com/ZealynxSecurity/audits/main/web2/2026-04-zealynx-dripster-offchain.pdf — Dripster Backend Pentesting report [4] https://dimes.fi — Dimes embedded leverage product