That's how I found a hardcoded JWT in production. Not glamorous, but efficient.

It began like every ordinary bug hunt: click, scan, repeat. Lots of noise, no signal. I tried the usual checks and nothing gave. Then I got bored and opened the production JavaScript bundle, because static files are where secrets go to hide.

I did not expect to find a token spelled out in plain sight.

var socketJWT = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...";

Yes. A JWT. In production. In a client-side file. Used for WebSocket auth. Someone had literally dropped the authentication token in a place anyone can read.

What I actually found

  • A production bundle from [REDACTED] contained a variable named socketJWT.
  • That token is used to authenticate WebSocket connections to the voice/AI socket endpoint.
  • The token was expired, exp: 2021–11–12, which saved them from an immediate live breach.
  • Still, an expired token proves a design problem: if one expired token slipped in, a valid one could too.

This is not exciting in a cinematic way. It is boring and preventable, which makes it worse.

Reproduce in three clicks:

  1. Open the production bundle for [REDACTED] and search for socketJWT.
  2. Copy the token you find.
  3. Try connecting to the socket URL the code uses, passing the token as a query parameter:
wss://[REDACTED]/socket.io/?EIO=3&transport=websocket&token=<JWT>

No exploits required. Just reading and pasting.

Why it matters

  • If the token were valid, anyone could connect to the WebSocket endpoint and impersonate the client.
  • Even expired tokens leak how authentication is implemented and what endpoints exist. That helps attackers craft follow up attacks.
  • It reveals a larger problem: someone thought client-side code is private. It is not.

This is the kind of failure that creates attack paths later. Teams accidentally shipping a valid token in the same way would hand attackers authenticated access with no login required.

What I reported

My report was short and practical:

  • Where to find the issue: file path and the socketJWT variable.
  • Why it's wrong: client bundles are public, tokens must not be embedded.
  • Repro steps and minimal proof of concept.
  • Suggested fixes.
None

They accepted the bug and rewarded that bug

I recommended immediate and long-term fixes.

Fixes they should do now

  1. Remove hardcoded JWTs from all client bundles immediately.
  2. Issue tokens server-side, per user, short lived only.
  3. Enforce expiry and rotate secrets often.
  4. Audit the build and CI pipeline to prevent credentials leaking into artifacts.

Short version: stop treating client files like private storage.

Final, blunt takeaway

You do not need clever hacking to find meaningful bugs. Sometimes all it takes is opening files other people ignore. If your build ever prints a secret into a bundle, assume it will be found. Treat client code as public and design accordingly. Leaving tokens in JS is sloppy and dangerous. If you do it, fix it. If you find it, report it cleanly and move on.

That's how I found a hardcoded JWT in production. Not glamorous, but efficient.