My First Valid Bug Bounty Report: One JS Scan, One Hidden API Key - $200 💵

Hey all 👋

About This Blog

This blog is going to be a little different from the usual technical writeups you see floating around. I'm going to introduce myself, talk about how I got into bug bounty hunting, and walk you through how I found my very first valid bug that paid me $200. Yeah — the first one always hits different.

Who Am I?

I go by rudr03 — on pretty much every platform. I like keeping my real name out of it. Don't know why exactly, just always felt more comfortable that way 😅.

I'm a self-taught cybersecurity guy. No formal background, no fancy degree in security — just curiosity and a lot of late nights. I started learning the basics of cybersecurity and computer networks in mid 2025, and honestly it felt overwhelming at first. There's just so much out there.

Then in October 2025, a friend of mine introduced me to bug bounty hunting. That changed everything. I spent the next few weeks binge-watching YouTube, going through TryHackMe labs, and reading Medium writeups (like this one!) to understand how real-world hunting worked.

At the beginning, I didn't even want to touch platforms like HackerOne or Bugcrowd. I thought — I'm a beginner, I'll just embarrass myself. So I started with self-hosted programs to build confidence first.

A Small Message for New Bug Hunters 🐛

If you're still looking for your first valid bug — don't quit.

Seriously. The first few weeks/months are brutal and it's almost a rite of passage to get hammered with duplicates, informational reports, and N/A's. That's not failure, that's just the learning curve doing its thing. The hunters who make it are the ones who treat every closed report as a lesson and keep going.

You will find your first bug. Keep at it.

My First Month: The Reality Check

I started hunting in October 2025, excited and eager. I fired off reports to multiple programs, felt good about them — and then the responses started coming in:

• 3 × Informational
• 5 × Duplicate
• 3 × Not Applicable

In 30 days. Nothing valid.

That stings. I won't pretend it doesn't. So I stopped, took a Two-week break, and instead of hammering more reports, I went back to reading. Real bug bounty writeups on Medium. How do people actually find bugs? What methodology are they using?

That 2 week changed my approach completely.

The Comeback: A New Methodology

After that break I had a few new things in my toolkit:

• Google Dorking — how to find exposed assets using search engines
• JS file analysis — hunting for secrets (API keys, tokens, credentials) hardcoded inside JavaScript files
• Tools — specifically Katana for collection and Mantra for analysis

In November 2025, I came back to a self-hosted program — let's call it redacted.com — with a calm mind and this new methodology. My entire goal was simple: collect as many JS files as possible from the target, then scan them for anything sensitive.

Step 1: Collecting JS Files

I used two methods in parallel.

🤖 Automated — Using Katana

Katana is a fast crawling tool by ProjectDiscovery. It crawls a target and pulls out all the JS files that get loaded when the application runs.

katana -list all_subdomains.txt -jc | grep "\.js$" > katana_js.txt

katana -list all_subdomains.txt -jc | grep "\.js$" > katana_js.txt

Note:_ Katana can miss things if the application blocks crawlers or only loads JS files dynamically after login. Don't rely on it alone._

🖐️ Manual — Using Burp Suite

I created an account on redacted.com, turned on Burp's proxy, and manually walked through every page and feature I could find. As I browsed, Burp captured all the requests — including every JS file the application loaded.

I then went through Burp's proxy history, pulled out all the JS URLs, and saved them to a file called Burp-JS.txt.

This manual step is important. Authenticated areas of the app load JS files that a crawler would never reach.

Step 2: Merging and Deduplicating

Two files, lots of overlap. I merged them into one clean list:

cat katana_js.txt Burp-JS.txt | sort -u > all_js.txt

cat katana_js.txt Burp-JS.txt | sort -u > all_js.txt

sort -u handles both the alphabetical sort and the deduplication in one shot. Simple and effective.

Step 3: Scanning for Secrets with Mantra

Now for the good part. I used Mantra — a secret analyser that scans JS files for exposed API keys, tokens, AWS credentials, JWT secrets, and more.

cat all_js.txt | mantra

cat all_js.txt | mantra

It downloads each JS file and runs pattern matching against a library of known secret formats.

⚠️ Resource Note: Mantra is process-heavy. If you're running under 8GB RAM, stop everything else before running it. You can also reduce threads with -t 10 or -t 20 to keep it from grinding your system to a halt.

The Finding

Mantra threw back a bunch of results. As expected, most of them were false positives — generic-looking strings, Google API keys with no real scope, that kind of thing.

But two keys caught my eye immediately. They followed a very specific format:

sk-ant-api03-<long string>

sk-ant-api03-<long string>

I didn't recognise the format at first, so I asked ChatGPT. The response was clear: this is the format for an Anthropic Claude Enterprise API key — the kind organisations use to integrate Claude into their products.

The potential impact if a key like this is valid and exposed:

1. Unauthorized API Usage — an attacker could make unlimited API calls billed to the organisation's account
2. Financial Impact — Anthropic charges per request; this could rack up serious costs
3. Data Exfiltration — a valid key lets you push sensitive data through Claude under the org's account
4. Service Abuse — the API could be used for malicious purposes, all traced back to the victim organisation

I verified the key using Anthropic's API key validation check. It came back valid.

That was the moment I knew this was real.

The Report

I wrote up a clean, detailed report the same day — explained the discovered key , included the verification proof, and laid out the impact clearly.

Timeline

Date Event 20–11–2025 → Discovered the exposed Anthropic API keys 20–11–2025 → Submitted the report with a full explanation 21–11–2025 → Program confirmed the keys were valid and accepted the report 21–11–2025 Rewarded $200 🎉

24 hours from discovery to bounty. That's the one.

Takeaways

• JS file analysis is massively underrated. A lot of developers push API keys into frontend JS without realising it, and it's still surprisingly common in real production apps.
• The break mattered. Coming back with a clear head and a defined methodology was more productive than grinding blindly for another 30 days.
• Verify before you report. I confirmed the key was actually valid before submitting. A false positive on a high-severity finding damages your credibility — take the time to be sure.
• False positives are the majority. Out of everything Mantra flagged, only 2 results were real. That's normal. The noise is part of the game.

Thanks for reading. This is the first in what I'm planning to be a series of writeups documenting my bug bounty journey — the wins, the duplicates, the weird edge cases, and the lessons in between.

If this helped you at all, drop a clap and follow along. More coming soon.

— rudr03