On a typical late-night recon session—just me, my terminal, and a cup of coffee—I was passively scanning a few assets on domain.com, a target participating in a public bug bounty program.

I wasn’t expecting much at first, just running through my usual checklist: subdomain enumeration, JS file discovery, parameter harvesting, and content scraping.

Here’s how it started:

# Subdomain enumeration

assetfinder --subs-only domain.com >> subs.txt

# Probing for live hosts

cat subs.txt | httpx -silent >> live.txt

# Crawling for JS files

cat live.txt | waybackurls | grep ".js" >> jsurls.txt

After gathering a list of live JavaScript files, I filtered out the third-party ones and focused on those hosted directly on domain.com.

Sometimes, tools aren’t enough—you have to read the code. So I fetched a few large JS files and manually inspected them:

curl -s https://www.domain.com/static/main.js | less

While scrolling, a particular block caught my attention:

const config = {
  apiKey: "AKIAXXXXXXXEXAMPLEKEY123",
  data=91173hsbakexampledata
}

Yep. An API key, sitting exposed in client-side code. Immediately, a few red flags popped up in my head.

Even without knowing exactly what service the key belonged to, I knew this was risky:

If the key had write permissions, it could lead to data tampering or account abuse.