Before diving in, I'd like to ask everyone to take a moment and pray for our brothers and sisters in Gaza. May they find strength and peace amidst their struggles
JavaScript files can hide some big secrets — like tokens and secret keys — that hackers can use if they're not careful. I've found bugs by looking at these files, and it's easier than you might think. Tools don't always catch these secrets and tokens, so you have to dig in yourself. In this guide, I'll show you how I did it, step by step. Whether you're hunting bugs or just curious, you'll see how a quick check of JS files can uncover stuff that shouldn't be there.
Let's Go
Let's say our target is example.com, We started by browsing the site normally, just like any user would
While poking around, we figured out all the technologies they were using — nothing fancy, just observing the site's behavior and network requests
We noticed there was a payment process, which got us curious about how it worked behind the scenes
That's when we decided to dive into the JavaScript files manually. We searched for keywords like secret, private, token, and so on — common terms that might lead to something juicy. And then, while typing private, we hit gold : we found a private key for Affirm, exposed right there in one of the JS files
So, after we found that Affirm key 🗝️, we didn't stop , We ran to the Affirm API We sent a quick request, and guess what? The API opened up and gave us everything , More than 2,000 users' info came back — names, details, emails , address , merchant-id , …. etc
But we stopped right there and reported it like good hunters should. Wait, where you going? Hold up, there's another bug coming! 😂R Mre fun's on the way!
Now, wait a sec — before we even hit that Affirm key jackpot 🗝 we found another cool bug!
While digging through some JavaScript files on example.com, we spotted another file hiding a client_id and client_secret for CommerceTools
We got super curious — like, what can these things do? 🤔 So, we took them, tested them out, and — surprise!
We got an access token that opened the door wide
After that, we didn't just sit there — we sent a request to CommerceTools to grab a token!!!
And guess what? We got it! Then, the real magic happened — we pulled PII for all the users! Names, Shipping address , emails , everything when sending this request :
curl — get https://api.us-central1.gcp.commercetools.com/example-production/orders -i — header "Authorization: Bearer {{TOKEN}}
where you going? Hold up, there's another bug coming! 😂R Mre fun's on the way!
The third bug related to Mapbox Token , first we checked if access token valid or not using the following request :
curl "https://api.mapbox.com/tokens/v2?access_token={{Token}}"
The response :
After we got the Authorization , we sent a CURL to Geocoding API :
curl "https://api.mapbox.com/geocoding/v5/mapbox.places/Los%20Angeles.json?access_token={{Token}}We thought the vulnerability wouldn't be accepted by the customer, and indeed, the report was closed as "not applicable." However, about three months later, the vulnerability was accepted as: Sensitive Data Exposure > Disclosure of Secrets > Pay-Per-Use Abuse.
there's more write-ups coming soon, inshallah! Stay with us for more adventures and bugs! 😎
متنساش تصلي على حبيبك النبي محمد بن عبدالله