Bug Bounty API Security Testing

ToxSec | A Guide to API Testing

Jun 17, 2025

0x00 Testing API Security

APIs sit at the core of modern applications. Mobile clients, single-page frontends, IoT devices, and enterprise dashboards all rely on them to function. For bug bounty hunters, that makes them one of the most valuable areas to explore.

APIs are often shipped quickly, treated as “internal,” or layered onto systems that were never designed to be exposed. As a result, they can leak data, skip validation, and widen the attack surface compared to polished web frontends.

Effective API testing goes beyond injecting payloads. The real findings come from uncovering logic flaws, broken access control, and misplaced trust. The goal is to identify where the backend makes unsafe assumptions about the client and demonstrate how those gaps can be abused.

0x01 Recon: Finding the API Surface

You can’t hack what you can’t see. API hunting starts with discovery. Before payloads, before fuzzing—you need the map. APIs often live off the main web paths, hidden in subdomains, mobile traffic, or forgotten documentation.

Where APIs hide:

Subdomains
Classic entry point. Look for naming patterns:

api.target.com, v1.target.com, mobile-api.target.com.

Don’t stop at obvious. Try versioned subs

api-v2, staging-api, internal-api

and regional ones

eu-api, us-west-api

Use tools like amass, subfinder, assetfinder, or paid recon platforms. Pair brute-force wordlists (api, graphql, rest, svc, gw) with certificate transparency logs (crt.sh) to catch live but unlinked hosts.

Mobile apps
Many companies hide APIs in their mobile flows. Grab the APK/IPA, install on a test device/emulator, and proxy traffic through Burp or MITMProxy. Mobile often exposes endpoints not linked on web—like account recovery, telemetry, or internal feature flags. Decompile APKs with JADX to spot hardcoded base URLs and secrets.
Frontend JavaScript
JS is a goldmine for buried API calls. Audit minified bundles or individual .js files for keywords:

fetch(, axios.post, XMLHttpRequest, graphql, apiKey.

Regex hunt for URL patterns

/api/, https://, version strings

Chrome DevTools > Network tab also exposes background XHR/fetch requests when you click through the site.

Documentation leaks
Devs leave doors open:

/swagger.json, /openapi.json, /swagger-ui/, /docs/.

Public Postman collections on company GitHub or misconfigured SharePoint/Confluence spaces.
Even robots.txt can hint at hidden API routes.
Parsing Swagger/OpenAPI gives you structured endpoint maps with verbs, parameters, and models—basically a blueprint for attacks.

Other angles
- GitHub/GitLab leaks: Search for baseUrl or api_url in commits.
- DNS + CDN: Sometimes APIs run on api.targetcdn.com.
- Error messages: 404s, stack traces, or “Invalid API key” responses can point to hidden endpoints.

Recon is less about brute force, more about piecing together fragments—naming conventions, mobile flows, leaked docs. Every endpoint is another potential attack surface.

Tools that make it faster:

Manual recon works, but automation buys you speed. The trick is chaining tools together so one feed drives the next.

Historical endpoints
Use gau (GetAllURLs) or waybackurls to pull archived routes from the Wayback Machine, Common Crawl, and other sources. These often surface deprecated API paths, versioned routes (/v1/, /beta/), or admin panels that aren’t linked anymore but still respond.
Subdomain recon
- amass, subfinder, assetfinder — the go-to trio for building subdomain inventories.
- Pipe results into httpx to filter live hosts.
- Don’t ignore wildcard DNS entries—sometimes they expose internal staging APIs if you brute common words.
Misconfiguration scanners
- nuclei with API-specific templates (open Swagger, exposed GraphQL consoles, CORS issues).
- Look for overly permissive headers (Access-Control-Allow-Origin: *), verbose error messages, and test endpoints left enabled.

Go beyond endpoints—map methods:

The surface isn’t just the path.
Same route, different behavior:

GET /user/123 → Returns user data.

PUT /user/123 → Updates the record.

DELETE /user/123 → Removes it entirely.

Don’t assume functionality is locked down. Developers sometimes restrict the UI but leave backend verbs exposed. Test every standard method (GET, POST, PUT, PATCH, DELETE) plus oddballs (OPTIONS, HEAD). Unexpected responses (405 errors, redirect chains, even CORS preflight results) can signal misconfigured routes.

Mapping verbs is often how read-only access turns into full account takeover.

API recon isn’t just about making a list of URLs. It’s about building a map of what the system thinks you’re allowed to do.

0x02 Common API Flaws

Once you’ve mapped endpoints, the next step is figuring out where they break. APIs rarely fail with flashy injections — they fail in logic and trust.

APIs introduce several recurring vulnerabilities that hunters should keep in focus. Broken Object Level Authorization (BOLA), also known as IDOR, remains the most common and the most damaging: change user_id=123 to user_id=124 and you may suddenly see another user’s data.

Mass assignment is another frequent issue, where APIs that accept full JSON bodies fail to whitelist fields—allowing an attacker to slip in parameters like "isAdmin": true and escalate privileges. Gaps in rate limiting are equally valuable, especially on login, password reset, or enumeration endpoints where brute-force attempts go unchecked.

Verbose error messages can leak details about backend structure, SQL queries, or hidden endpoints through stack traces and exception strings.

Finally, weak or missing authentication continues to surface, with endpoints exposed under the assumption they were “internal” or secured by poorly signed tokens and API keys.

0x03 API Testing Workflow

API testing isn’t one payload. It’s a loop of manipulate → replay → observe. Burp Suite becomes your best friend here.

Step 1. Intercept & Replay

Send interesting requests to Burp Repeater.
Change parameters like user_id, account_id, or order_id.
See if you get someone else’s data.

Step 2. Method Manipulation

Try verbs the devs didn’t expect:

PUT /users/123 {"role":"admin"}  
DELETE /users/123

Same path, different verb often bypasses frontend restrictions.

Step 3. Payload Tampering

Send oversized arrays or unexpected types.
Try boolean flips ("isAdmin":true).
Look for hidden parameters by diffing docs, guessing common fields, or fuzzing JSON keys.

Step 4. Auth Validation

Remove Authorization headers — does the endpoint still respond?
Swap JWTs between users — does the server validate ownership, or just trust the token?
Replay expired tokens — are they rejected, or still honored?

Good API hunting is less about “fuzz everything” and more about asking: what assumption is the backend making about me, and how do I break it?

0x04 Exploitation Beyond the Basics

Once you’ve confirmed an API quirk, the next step is chaining it into impact. This is where bounty reports go from “informational” to “critical.”

Chaining flaws for real-world damage:

IDOR → Account Takeover: Change user_id and pull another user’s profile, then edit it via a PUT request. Suddenly you’re controlling someone else’s account.
Mass Assignment → Privilege Escalation: Inject "role":"admin" into a JSON body. If accepted, you’ve jumped from user to admin.
Rate Limit Gaps + Credential Stuffing: Without throttling, spraying passwords or tokens can lead to mass compromise.
Misconfigured CORS: If Access-Control-Allow-Origin: * is present, XSS on another site can steal API tokens cross-origin.
GraphQL Introspection Abuse: If schema introspection is enabled, you can enumerate all queries/mutations, including hidden admin functionality.

Never overlook “boring” server-side issues: file uploads, command execution, or SSRF behind an API endpoint. Those often fly under the radar because hunters treat APIs as pure JSON — but they can expose the same critical vulns as a web form.

0x05 Bug Bounty Scope: Valid vs Noise

Not every API finding earns a bounty. Programs have learned to filter out the noise. Hunters who understand scope get paid; hunters who dump raw scanner output get ignored.

Valid API findings:

Accessing another user’s data (BOLA/IDOR).
Escalating privileges with mass assignment.
Exploiting weak auth or forging tokens.
Proving business impact through chained flaws (e.g., read → edit → takeover).

Noise in reports: [ turn to paragraph ]

Generic 500 errors with no data exposure.
“No rate limiting” on non-sensitive endpoints (e.g., public search).
Automated scanner alerts with no manual verification.
Endpoints clearly marked as out-of-scope in the program rules (common mistake).

How to frame a valid report:

Bad: “I found an IDOR on /api/user/123.”
Good: “By modifying user_id, I accessed invoices for other accounts. This allows me to exfiltrate financial records for any customer.”

Impact is the difference between a triage reject and a bounty payout.

0x06 Debrief

APIs are the nervous system of modern apps. Often they are also weakest part. Frontends may have polish and guardrails, but APIs usually expose the raw logic underneath.

For hunters, that’s both the opportunity and the challenge. You’re not looking for flashy payloads. You’re looking for trust failures: endpoints that give you data you shouldn’t see, let you send fields you shouldn’t control, or skip the checks that keep one user from impersonating another.

CTFs train the mechanics — fuzzing parameters, flipping booleans, hammering requests. Bug bounty raises the bar: you need to show how that quirk turns into business risk. A leaked invoice, an escalated role, a token that never expires. That’s the difference between noise and signal, rejection and payout.

APIs aren’t going away. If anything, they’re the real front door now. Hunters who learn to test them methodically will always have targets.