But real bug bounty hunters and penetration testers don't work that way.

They work with trust, identity, and logic.

This is how high‑impact bugs are actually found.

Step 1 — Start from the public site

Every test begins at www.target.com.

Hunters log in, use features, open tickets, view profiles, and observe how the frontend communicates with the backend.

Using browser DevTools or a proxy, they observe:

  • Which API endpoints are called
  • What cookies or tokens are used
  • What object IDs (tickets, users, orders) look like

This builds a map of the system.

Step 2 — Move to the API

Once endpoints are known, the same requests are tested directly on:

api.target.com

Here, the goal is simple:

Does the server enforce who can see what?

This is where IDOR, broken authentication, and data leaks appear.

Step 3 — Pivot to internal subdomains

Now the real hunting begins.

The same requests are sent to:

admin.target.com
stage.target.com
dev.target.com

No payloads.

No bypass tricks.

Just the same authenticated user session.

The question is:

Does this internal system trust my normal user identity?

If yes, that's a broken trust boundary.

Step 4 — Identity testing

Hunters always check:

  • Who does this server think I am?
  • What role do I have?
  • What data can I see?

Endpoints like /me, /profile, or /session quickly reveal whether the backend is enforcing roles correctly.

Step 5 — Object access & role enforcement

They test:

  • Can I view other users?
  • Can I see support tickets?
  • Can I access logs or internal tools?

If a low‑privileged user can read or access admin data, it's a privilege escalation — not a hack, but a logic failure.

Why does this lead to huge bounties

The biggest bug bounty payouts don't come from XSS or SQL injection.

They come from:

  • Broken Access Control
  • IDOR
  • Privilege Escalation
  • Trust Boundary Violations

And these almost always exist in internal subdomains that developers assume are safe.