Exposed API Endpoints: How Hackers Find Your Data in Under 60 Seconds

The 60-Second Attack

A hacker opens a terminal. Three commands. 702,651 user records land in a CSV on their desktop.

No brute force. No zero-days. No password cracking. Just a public API endpoint your developers forgot to protect.

We've found this exact scenario — not in a lab, but in real production sites serving real customers. The endpoint looks like this:

$ curl https://example.com/api/users

HTTP/1.1 200 OK

Content-Length: 48,203,541

{"users":[{"id":1,"email":"[email protected]","phone":"555-0123","address":"..."},...]}

No token. No session cookie. No API key. Just data.

How Attackers Find These Endpoints

1. JavaScript Bundle Mining

Modern web apps ship their entire route map inside their JavaScript bundles. An attacker downloads your main bundle and runs:

$ grep -oE '"/api/[^"]+' main.chunk.js | sort -u

/api/admin/users

/api/analytics/export

/api/customers/list

/api/orders/all

These aren't hidden. They're in the code your browser downloads.

2. Google Dorking

Search engines index API responses that leak into public pages. Common dorks:

site:example.com inurl:"/api/" filetype:json

site:example.com inurl:"users" "email"

3. Common Path Enumeration

REST APIs follow predictable patterns. Attackers try:

/api/v1/users

/api/v2/users

/api/admin/users

/api/export/users

/admin/api/users

Most companies have at least one of these working unauthenticated.

4. Parameter Fuzzing on Known Endpoints

Once a base path is found, attackers fuzz parameters:

$ for id in $(seq 1 10000); do

curl -s "https://example.com/api/user/$id" | jq .email

done

This is an IDOR (Insecure Direct Object Reference) — your IDs are sequential and your auth check is missing.

What We Found in Real Assessments

During our assessment of a press release distribution platform, we found:

• GET /api/users → 702,651 records, no auth
• {c}GET /sources/u{id}{/c} → individual user profiles, sequential IDs
• GET /admin/export.csv → full database export, no session required

The company had no idea. Their security scanning tool showed "green" because it only checked for known CVEs.

How to Check Your Own APIs

Quick Self-Check

Open browser DevTools, go to Network tab, and navigate your app logged out. Look for any API calls that return data without session cookies.

Automated Check

# Export your JS bundle endpoints

curl https://yoursite.com/main.js | grep -oE '"/api/[^"]+' | sort -u > endpoints.txt

# Test each one without authentication

while read endpoint; do

status=$(curl -s -o /dev/null -w "%{http_code}" "https://yoursite.com$endpoint")

echo "$status $endpoint"

done < endpoints.txt

Any 200 response on a data endpoint without authentication is a critical finding.

The Fix

• Require authentication on every data endpoint — no exceptions
• Use middleware-level auth checks, not route-level (easier to miss)
• Implement rate limiting even on authenticated endpoints
• Audit your JS bundles for exposed internal paths
• Run a security assessment before attackers do

Pedro scans for all of these automatically. One assessment, 99+ probes, results in 60 seconds.