Every year, sensitive APIs get discovered, exploited, and breached — not because attackers were technically sophisticated, but because the APIs were publicly accessible and never intended to be exposed. Here's how it works and how to find your own exposure before someone else does.
APIs are the connective tissue of modern applications. They handle payments, user data, authentication, admin functions — everything. And when they're exposed to the internet without proper auth or access controls, they're one of the fastest paths from "interesting finding" to "critical breach."
The problem: most organizations don't know how many APIs they have, what those APIs do, or whether they're actually supposed to be public. Security researchers find this out within minutes. Here's the playbook.
APIs get exposed in ways that look completely innocent:
Certificate Transparency (CT) logs are public records of every SSL certificate issued for a domain. Tools that query CT logs can reveal subdomains and internal hostnames you'd never guess existed — without sending a single DNS request.
Look for patterns: api.yoursite.com, admin.yoursite.com, internal.yoursite.com, v1.yoursite.com, dev.yoursite.com — these are the most likely to expose sensitive functionality.
Every web app's JavaScript is a goldmine of API intelligence. Endpoints get referenced in JS files as fetch() calls, axios calls, and hardcoded paths. Even when the main app requires authentication, the JS is publicly accessible.
Tools can automatically scrape JS files from a domain, extract all URL paths, and identify API endpoints — including internal APIs that shouldn't be public. Look for patterns like:
fetch('/api/admin/users')
POST /api/v2/payments
GET /api/internal/health
wss://api.yoursite.com/realtimeIf an API has OpenAPI/Swagger documentation published without authentication, it tells an attacker everything: which endpoints exist, what parameters they accept, what response formats look like, and whether auth is enforced. Common locations to check:
/api/docs
/api/swagger.json
/api/openapi.json
/swagger-ui.html
/api/v1.yamlNot everything gets a certificate. Path brute-forcing uses wordlists of common API endpoint patterns to find endpoints that exist but weren't discovered passively. Common API path wordlists target:
/api, /api/v1, /api/v2, /api/beta/admin, /administrator, /manage/internal, /private, /intranet/debug, /debug/pprof, /actuator/phpinfo.php, /.env, /server-statusSometimes the endpoint is known but the parameters aren't. Adding parameters like ?debug=true, ?verbose=1, or ?format=json to endpoints can reveal hidden data or change response behavior. This is how researchers find debug modes left enabled in production.
| Endpoint Pattern | Risk Level | Why It Matters |
|---|---|---|
/api/admin/* |
HIGH | Unauthenticated admin functions — user management, config changes, data deletion |
/api/v1/users |
HIGH | User enumeration — email, ID, role extraction |
/actuator/env |
HIGH | Spring Boot actuator — exposes environment variables, secrets, config |
/swagger.json |
MED | Full API map — all endpoints, parameters, auth requirements visible |
/debug/pprof |
HIGH | Go pprof — CPU profiles, heap dumps, goroutine traces exposed |
/api/internal/* |
MED | Internal-only endpoints that bypass public-facing auth |
/api/debug |
HIGH | Debug endpoints — often leak stack traces, configs, internal state |
/.env |
HIGH | Environment file — database credentials, API keys, JWT secrets |
EdgeIQ's API Endpoint Discovery tool combines passive CT log analysis, JavaScript endpoint extraction, and active path brute-forcing to map your full API surface — free, no signup.
Scan your domain free →Most API exposure is accidental — an endpoint left public that was supposed to be internal, a documentation page that got indexed, a JS file that reveals more than it should. The good news: it's findable, it's fixable, and the fix is usually simple. Audit your APIs, find what shouldn't be public, and close the gaps before someone else finds them first.