In this blog, I’ll walk you through a real-world scenario where a seemingly harmless feature—OTP-based login—unintentionally opened the door to a serious security flaw. It was like hiding the house key under the doormat: convenient, but dangerously predictable.
- You enter your mobile number to log in.
- The app sends a request to the server.
- The server sends the OTP to your mobile number — so far so good.
- But wait — the same OTP also comes back in the HTTP response to the browser!
The OTP, meant to be secret, was traveling back in plain sight, just sitting there in the network response like it’s no big deal.
So, if an attacker intercepts the response (using a proxy tool like Burp Suite or browser dev tools), they can read the OTP and log in as you — without ever needing access to your phone.
Now, the app I was testing did something a little better. It didn’t expose the OTP directly. Instead, it returned an encrypted OTP in the response.
I started digging,
- I did a bit of Google dorking (searching for exposed files and endpoints).
- So I manually read through the Javascript files of the application.
And there it was…
The key and the decryption code were right there in the frontend JavaScript.
Like hiding your house key under the welcome mat… and also leaving a sign that says “Key’s under here!”
I copied the decryption function, plugged in the encrypted OTP, and boom — I got the original OTP.
Logged in. Account taken over. No brute force, no phishing, no hacking tools — just browser dev tools and a little patience.
Here’s what you should remember — whether you’re a developer or a security tester:
- Never send OTPs (or any sensitive info) in HTTP responses, even if they’re encrypted.
- Never hardcode encryption keys or secrets in client-side code — it defeats the whole purpose of encryption.
- Always do recon. It’s not about fancy tools — sometimes, reading the JS manually is all you need.
- Manual inspection > automation (in many cases). Automated scanners might miss things hidden in plain sight.
This whole situation could’ve been avoided with just a bit more care during development. Security isn’t about paranoia — it’s about not handing over the keys to your users accounts in a gift box.
If you’re a developer, always assume that anything on the frontend can be seen and manipulated by users. If you’re a bug bounty hunter, don’t underestimate the power of curiosity, recon, and reading a bit of JavaScript.