Target, domains, API keys, bearer tokens, SSO IDs, and organisation names are redacted. This writeup is for educational purposes and describes testing performed in an authorised UAT bug bounty scope.

Summary

After finding a client-side encrypted API flow, I looked for other places where the application trusted encrypted data from the browser.

One interesting flow was an MSPACE-style auto-login/deeplink feature. The frontend accepted a data URL parameter, decrypted it with a client-side key/IV, parsed it as JSON, and sent the values to a backend endpoint:

POST /<REDACTED_PATH>/api/leads/control-transfer

The critical finding was that the backend returned a successful MSPACE token-validation message even when the inner MSPACE token was a random fake string.

The Two Token Layers

This bug involved two different token concepts:

1. Outer API bearer token
   Sent in the Authorisation header.
   Required to call the backend API.
2. Inner MSPACE deeplink token
   Sent inside the encrypted JSON request body.
   Supposed to prove the MSPACE deeplink/control-transfer is legitimate.

The outer API bearer token was valid. The vulnerability was that the inner MSPACE token was fake, but the backend still…