One unauthenticated endpoint. One unrestricted API key. $331,000/month in potential financial damage.

Introduction

Bug bounty hunting teaches you one thing very quickly the most dangerous vulnerabilities are often the simplest ones. This is the story of how a single misconfigured production endpoint, accessible to anyone on the internet, exposed a fully unrestricted Google Maps API key with access to 10 live APIs.

No authentication bypass. No exploit chain. Just one curl command.

Responsible Disclosure Note: The name of the affected organization has been omitted intentionally. The vulnerability was reported through a responsible disclosure program before this article was published.

How It Started Android APK Recon

My testing began with static analysis of an Android APK. After extracting the application package, I started enumerating all hardcoded URLs and endpoints referenced inside the app’s assets and compiled resources.

# Extract APK contents
unzip -d app_extracted target_app.apk
# Find all URLs and endpoints
grep -rE "https?://[a-zA-Z0-9._/-]+" app_extracted/ \
  | grep -v ".png|.jpg|schema|google.com" \
  | sort -u

Among the output, one endpoint stood out immediately:

https://[REDACTED]/envs/env.json

The path /envs/env.json is a well-known pattern — applications often fetch runtime configuration from a JSON file to avoid hardcoding environment-specific values in the APK. The word "envs" in the path strongly suggested this was serving live environment configuration, possibly for multiple environments (dev, staging, production).

The Vulnerability Zero Authentication Required

I sent a basic request to the endpoint:

curl -s https://[REDACTED]/envs/env.json

No token. No cookie. No authentication whatsoever.

The server returned a full JSON configuration object in plaintext:

{
  "ENV": "production",
  "GOOGLE_MAPS_API_KEY": "AIzaSy[REDACTED]",
  "API_BASE_URL": "https://[REDACTED]",
  ...
}

Two things immediately stood out:

1. "ENV": "production"This was not a test environment. This was live production.
2. "GOOGLE_MAPS_API_KEY"A Google Maps API key, sitting in a publicly accessible file.

Validation Testing the API Key

The next step was to verify how much access this key actually had. I tested it against all major Google Maps Platform APIs using the keyhacks methodology:

# Geocoding API
curl "https://maps.googleapis.com/maps/api/geocode/json?address=London&key=AIzaSy[REDACTED]"
→ 200 OK ✅
# Directions API
curl "https://maps.googleapis.com/maps/api/directions/json?origin=London&destination=Paris&key=AIzaSy[REDACTED]"
→ 200 OK ✅
# Places API (Nearby Search)
curl "https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=51.5,-0.1&radius=1000&key=AIzaSy[REDACTED]"
→ 200 OK ✅
# Distance Matrix API
curl "https://maps.googleapis.com/maps/api/distancematrix/json?origins=London&destinations=Paris&key=AIzaSy[REDACTED]"
→ 200 OK ✅
# Static Maps API
curl "https://maps.googleapis.com/maps/api/staticmap?center=London&zoom=10&size=400x400&key=AIzaSy[REDACTED]"
→ 200 OK ✅

All 10 tested APIs responded successfully.

The key had zero restrictions configured:

❌ No HTTP referrer restrictions
❌ No IP address restrictions
❌ No API-level restrictions
❌ No daily quota limits set
✅ Full unrestricted access to entire Google Maps Platform

Financial Impact $331,000/Month

This is where the finding went from “interesting” to Critical severity. Google Maps Platform charges per API request after a $200 monthly free credit. Here is the damage calculation:

With distributed abuse across multiple IPs and automated scripts — a realistic attacker scenario — a 3x multiplier brings the total to approximately $331,000/month in financial damage, all billed directly to the victim’s Google Cloud account.

This is not hypothetical. Real-world victims have reported $10,000+ bills within just 4 days of a key being compromised. Google’s own policy states clearly:

“Google Maps Platform customers are responsible for charges incurred with unrestricted API keys, including usage by unauthorized third parties.”

What an Attacker Could Do

Financial Abuse
Run automated scripts hitting all 10 APIs simultaneously, generating maximum billing charges billed entirely to the victim.

Competitive Intelligence
Use the Places and Geocoding APIs to extract bulk location data at the victim’s expense.

Service Disruption
Exhaust the daily API quota so the legitimate app stops rendering maps for its real users causing direct user-facing downtime.

Underground Monetization
Sell the key on dark web forums. Buyers pay a fraction of the value to use someone else’s quota a well-documented pattern in API key abuse markets.

Root Cause Two Misconfigurations, One Critical Finding

This finding was the result of two independent misconfigurations that combined into something far more severe:

Misconfiguration #1 Publicly Accessible Config File
The /envs/env.json endpoint had no authentication layer. Any person on the internet with the URL could fetch the complete production configuration. Sensitive config files should never be publicly served values should be injected at build time or fetched only by authenticated clients.

Misconfiguration #2 Unrestricted API Key
Google Maps API keys support three types of restrictions:

• Application restrictions limit usage to specific HTTP referrers or IP addresses
• API restrictions limit the key to only the APIs the app actually uses
• Quota limits cap maximum daily/monthly spend

None of these were configured. The key was completely open.

Either misconfiguration alone would be a Low/Medium finding. Together, they created a Critical severity financial vulnerability.

Remediation

Immediate Actions (Day 0):

• Revoke and rotate the exposed API key immediately
• Restrict access to /envs/env.json add authentication or remove the endpoint entirely
• Audit Google Cloud billing console for unauthorized usage activity

Long-Term Fixes:

• Restrict all API keys to specific HTTP referrers (web) or IP addresses (server-side)
• Enable only the specific APIs each key needs disable everything else
• Set monthly budget alerts in Google Cloud Console ($50 / $100 / $500 thresholds)
• Move secrets to a proper secret manager (Google Secret Manager, AWS Secrets Manager, HashiCorp Vault) never serve them in public JSON files
• Add a Content Security Policy and authentication middleware to all configuration endpoints

Timeline

Takeaways for Security Researchers

1. Config files are your best friends during recon.
Always check for /env.json, /envs/env.json, /config.json, /.env, /app.config.js, /settings.json, /api/config. These paths are goldmines.

2. “Common” findings can still be Critical.
Google Maps key exposure is often rated Low when found in JavaScript source code. Add an unauthenticated production endpoint to the mix and the severity jumps to Critical immediately.

3. Quantify financial damage always.
A finding with a specific dollar figure attached gets taken more seriously than one that says “attacker could abuse this.” Run the numbers. Show your math.

4. Test all APIs, not just one.
Do not stop at confirming the key works for Maps JavaScript API. Enumerate every Google Maps Platform API systematically. Every additional API that responds is additional impact.

5. Chain your findings.
The two misconfigurations here unauthenticated endpoint + unrestricted key individually rate as Medium. Together they rate as Critical. Always look for how findings combine.

Conclusion

Not every Critical vulnerability requires a complex exploit. Sometimes it is a publicly accessible JSON file and four curl commands. The simplest misconfigurations are often the ones that get overlooked precisely because they seem too obvious.

In this case, a production config file with zero access controls and a fully unrestricted API key two configuration mistakes created a vulnerability with over $331,000/month in measurable financial damage potential.

The lesson is simple: treat every secret like it is already exposed, because one day, it might be.

Happy hacking always responsibly.

#BugBounty #AndroidSecurity #GoogleMaps #APIKeyExposure #InfoSec #MobileSecurity #ResponsibleDisclosure #CyberSecurity