My flatmate was screaming about a missed headshot while I was staring at a password form on a multi‑hundred‑crore company's website. Two hours later, I was inside their reports database, every job application, every contact‑form inquiry, every résumé link, dating back to day one. And I never had to break a thing.

This isn't a CTF writeup. This is a real mid‑cap industrial stock listed on the NSE. And they left the keys in the Js.

Step 1: The Gate

None

The /reports page was a simple white box: "Enter Password." No username. No submit to a server. Just a client‑side form. When a site does that, it's screaming one thing: the password is in the code.

But how do you find it in a modern Next.js app with a hundred minified chunks?

Step 2: The Chunk Hunt

Next.js gives every page its own JavaScript file. I opened the page source, looked for the script tag:

html

<script src="/_next/static/chunks/pages/reports-69xae817429f1ce4.js" defer=""></script>

That's the file with the logic. I downloaded it with curl, then ran one command:

bash

grep -i 'password' reports.js

And there it was, inside a single giant line:

javascript

"__admhost __*8899*@*21#285#699#64"===r ? p(!0) : showToast("Incorrect password…")

The password was a hardcoded string. No hashing. No server check. Just a string comparison in the browser.

Step 3: The Bypass

I typed that password into the form, hit Submit, and the page immediately transformed into an Export Data panel with a form selector, date range picker, and a bright "Export to Excel" button.

No API token. No session. The client-side gate just let me through because I knew the secret that never should have been client-side in the first place.

None

Step 4: What Was Behind the Gate

Two forms could be exported:

  • Contact Us Form — every personal info: names, emails, phone numbers, messages.
  • Career Form — every job application: resumes, cover letters, contact details, positions applied for.

The career form even returned direct URLs to uploaded résumés, stored on the company's CDN. The data went back to the very first submissions. I could filter by any date range and download an .xlsx with everything.

I didn't download anything, that's the line every ethical hacker should respect of😉 I won't cross without authorization but the attack surface was massive: full of PII exposure, internal hiring pipeline leaks, and a h@cker*'s phishing goldmines.

The Technical Lessons (Why This Happened)

  1. Client‑side authentication is theater If the password check happens in JavaScript, the password lives in the JavaScript. There is no way to hide it. Move auth to the server.
  2. Static exports don't mean safe The page was nextExport:true, but developers often assume static == no secrets. They forgot that the JS bundle still runs on the client.
  3. Secrets in source code are trivially discoverable A single grep command on the right chunk revealed the password. Any visitor can do this.
  4. Staging environments clone production flaws The same vulnerability existed on the staging subdomain, with an identical password. Always lock down staging like production.

🎯 The Takeaway

This wasn't a CTF. This was a real company with real money, real employees, and a real vulnerability that could've been exploited by anyone with cURL and a keyboard.

If you're a developer building admin panels, please remember — Never ever trust clients!

Now back to my flatmate, who's still stuck in Silver XD

Found this useful? Smash that clap button and follow for more real‑world security breakdowns. No labs. No fake targets. Just the messy, beautiful internet.