Yesterday, we talked about what Swagger UI is — that clean little interface that shows all the API endpoints and lets you hit "Try it out" like it's Postman in your browser.

Today, let's be honest:

The real question is: how do you actually find Swagger UI on real targets in your bug bounty recon?

This isn't theory. This is the exact step‑by‑step flow you can follow the next time you open a new program.

Why Swagger UI Is Worth Your Time

Before we jump into commands and paths, it helps to remember why you're doing this.

When Swagger UI is exposed, you basically get:

  • A ready‑made API map
  • Every endpoint and HTTP method
  • All the parameters and their names
  • Request and response schemas
  • And a "Try it out" button that makes testing stupidly easy

Instead of spending hours guessing URLs and reverse‑engineering the frontend, Swagger UI just… tells you everything.

For a bug bounty hunter, that can turn into:

  • IDOR/BOLA (thanks to paths like /users/{userId})
  • Broken auth (admin or internal endpoints that don't check permissions properly)
  • Business logic and payment bugs (because you see all the money‑related fields right there)

So yeah, hunting Swagger UI is absolutely worth the time.

Step 1: The "Lazy" Browser Check

When you open a new target, don't overcomplicate it. Start with the main domain and any obvious API domains.

Let's say you have:

The first thing you do? Add a few classic paths to the URL bar and see what happens.

Try these:

  • /swagger
  • /swagger-ui
  • /swagger/
  • /swagger-ui/
  • /swagger/index.html
  • /swagger-ui/index.html
  • /api-docs
  • /v2/api-docs
  • /v3/api-docs
  • /swagger.json
  • /openapi.json

So you end up checking URLs like:

Two good outcomes:

  • You see the Swagger UI interface with endpoints and "Try it out" → win.
  • You see JSON/YAML that starts with openapi or swagger and has paths → still a win.

If you get either, note the URL. This is now one of your most important recon assets.

Step 2: Let Google Do Some Recon For You

When the company has tons of subdomains, hunting manually becomes painful. This is where Google dorks shine.

Open Google and drop this in:

intext:"Swagger UI" intitle:"Swagger UI" site:target.com

Replace target.com with your actual target.

What this does:

  • Look for pages under that domain
  • That has "Swagger UI" in the title
  • And mention "Swagger UI" in the page content

In practice, this often reveals:

  • Dev API portals
  • Staging Swagger UIs
  • Old docs that the devs forgot to lock down

Every time you see that familiar Swagger UI blue interface, or even just a raw OpenAPI spec, save the URL. These are places you want to come back to.

And if you just want to practice on random public UIs, you can drop the site: part:

intext:"Swagger UI" intitle:"Swagger UI"

Scroll, click, explore. Good way to get used to different layouts and styles.

Step 3: When You Have 100+ Subdomains, Use a Script

Real recon quickly turns into lists like this:

api.target.com
dev.target.com
staging.target.com
portal.target.com
mobile.target.com

You are not going to click each one and try /swagger by hand. That's how you burn out.

Here's a simple approach:

  1. Put all your subs in a file called subs.txt.
  2. Use a tiny bash script with curl to probe common Swagger paths.

subs.txt:

api.target.com
dev.target.com
staging.target.com
portal.target.com

Script:

while read sub; do
  DOMAIN="https://$sub"
  for p in /swagger /swagger-ui /swagger/index.html /swagger-ui/index.html /api-docs /v3/api-docs /swagger.json /openapi.json; do
    url="$DOMAIN$p"
    echo "[*] Checking $url"
    resp=$(curl -sk --max-time 5 "$url" | head -n 5)
    if echo "$resp" | grep -Eiq "swagger|openapi"; then
      echo "[+] Possible Swagger/OpenAPI found at: $url"
    fi
  done
done < subs.txt

Now you can go grab a coffee while your terminal does the boring part.

Anything that prints with it [+] is worth opening in the browser.

Step 4: Did You Get the UI or Just the Spec?

Once you've got some hits, you need to know what kind of thing you're looking at.

When it's full Swagger UI

You'll know it immediately:

  • The page says "Swagger UI"
  • There's a big heading with the API name
  • You see grouped sections like user-controller, auth-api, admin, billing
  • Endpoints expand to show methods, parameters, and a "Try it out" button

This is the dream. You can click around, see everything, and send requests.

When it's only JSON/YAML

Sometimes you land on this wall of JSON or YAML:

json
{
  "openapi": "3.0.1",
  "info": {
    "title": "Example API",
    "version": "v1"
  },
  "paths": {
    "/users": {
      "get": { ... }
    }
  }
}

or:

json
{
  "swagger": "2.0",
  "info": { ... },
  "paths": { ... }
}

This is the raw OpenAPI/Swagger spec.

It's not as pretty, but it's just as useful. You can feed it into your own tools and build your own Swagger UI around it.

Save it as something like openapi.json or swagger.json. You'll use it in the next step.

Step 5: Turning a Raw Spec Into Your Own Swagger UI

Let's say the target is kind enough to expose, /openapi.json but not the UI.

No problem. You can build the UI yourself on your own machine.

First, save the spec:

bash
mkdir -p ~/swagger_specs
curl -s https://api.target.com/openapi.json -o ~/swagger_specs/openapi.json

Now you've got the spec locally.

If you use Docker, you can spin up Swagger UI like this:

bash
docker run -p 8080:8080 \
  -e SWAGGER_JSON=/foo/openapi.json \
  -v ~/swagger_specs/openapi.json:/foo/openapi.json \
  swaggerapi/swagger-ui

Then open:

http://localhost:8080

Boom. Full Swagger UI, same endpoints, same structure, just hosted locally.

If Docker isn't your thing, you can also:

  • Paste the JSON into Swagger's online editor
  • Import the spec into Postman or Insomnia and auto‑generate a collection

The point is: a raw spec is never "nothing". It's a key.

Step 6: Use Tech Stack Clues to Guess Smarter

Sometimes nothing obvious works, but you can still guess Swagger paths based on the backend tech.

Some common defaults:

  • Spring Boot (Java)
  • /swagger-ui.html
  • /swagger-ui/index.html
  • /v3/api-docs
  • ASP.NET Core (Swashbuckle)
  • /swagger
  • /swagger/index.html
  • /swagger/v1/swagger.json
  • Node / Express / NestJS
  • /api-docs
  • /swagger
  • Custom setups
  • /docs
  • /openapi

You can usually guess the stack by:

  • Looking at Server or X-Powered-By headers
  • Checking error pages (ASP.NET, Spring, etc. are easy to spot)
  • Looking at JS bundles and comments

Once you have an idea of the framework, try the relevant default Swagger URLs.

Step 7: What to Do Once You've Found Swagger UI

Finding Swagger UI is not the end of the story — it's the start of a much better one.

Here's what you do when you have it open (either on the target or your local Docker instance):

Map the big picture

  • Look at all the tags (groups):
  • admin, internal, billing, orders, export, debug
  • Note the main resources:
  • /users, /accounts, /orders, /invoices, /projects, /tokens, /sessions

Now you know, in a few seconds, what the backend actually does.

Mark the ID‑based endpoints

Look for paths like:

  • /users/{userId}
  • /orders/{orderId}
  • /organizations/{orgId}
  • /files/{fileId}

These are your classic IDOR / BOLA candidates.

Later, you can:

  • Call them User A
  • Swap the ID to see if you can see or modify User B's data

Swagger UI saves you from guessing these endpoints. They're right in front of you.

Spot the "dangerous" fields

Open a few interesting endpoints and scan the request schemas for:

  • IDs: userId, accountId, orderId, tenantId
  • Role/flags: isAdmin, role, plan, subscriptionLevel, status, active
  • Money: amount, price, quantity, discount, credit, points

That's where:

  • Privilege changes can happen
  • Payment logic can be abused
  • Business rules might be weak

From here, you're no longer randomly poking the app. You're making informed attacks.

A Tiny Checklist to Reuse on Every Program

To turn this into a habit, you can keep a short checklist like this in your notes:

  • Try common Swagger paths on the main and API subdomains
  • Run a Google dork: intext:"Swagger UI" intitle:"Swagger UI" site:target.com
  • Scan all subdomains with a curl/bash loop
  • Classify hits: full UI vs raw spec
  • Save specs and load them into local Swagger UI or Postman
  • Inside Swagger:
  • List high‑value tags (admin, internal, billing, debug)
  • Mark ID‑based endpoints for IDOR/BOLA
  • Highlight role/flag/money fields for business logic tests

Do this across enough programs, and finding Swagger UI stops feeling like "luck" and starts feeling like part of your standard recon muscle memory.

Yesterday was about understanding Swagger UI. Today, you've seen how to actually hunt it down and weaponize it in your bug bounty workflow.

The natural next step? Using what Swagger shows you to dig into authentication, authorization, and payment logic bugs — but that's a story for another day.