The Bug I Used

he vulnerability was an auth-boundary mistake that developed through ordinary product drift.

A backend API key started as a narrow, low-impact mechanism. Over time it picked up more more micro-services for low profile APIs atuh. Then that key was shipped into the browser build. A frontend request path used the key directly, while the app already had JWT-based web auth available elsewhere. On the backend, service-auth decorators accepted possession of that static key as proof that the caller was a trusted service.

Once the browser build exposes a credential that the backend treats as service identity, the security conclusion is already established.

That was enough to establish the fix too: remove the service credential from the client path, use the user-auth boundary for browser-originated requests, and stop treating a browser-reachable static key as service identity.

A weaker report can still say true things around this bug:

• there is a key in client-reachable code

• there are .env defaults worth cleaning up

• internal gRPC is not hardened with mTLS

• startup validation can be stricter

Those are not nonsense. They just do not carry the main risk. The main risk is the browser-to-backend trust break: client code can access a credential that backend service-auth accepts as trusted service identity.