Why API Recon Is a Big Deal

So guys, today we're going deep into how to recon APIs properly, the how, why, and where…. Modern applications are API‑driven: web and mobile frontends are just clients talking to a backend API. If you only test what the UI shows you, you're leaving a huge amount of attack surface untouched.

Good API recon means:

• Finding real endpoints, not guessing.
• Understanding how they work, not just hitting them.
• Using that knowledge to uncover hidden features, parameters, and vulnerabilities.

Understanding API Endpoints with a Simple Example

Start with a basic request:

GET /api/devices HTTP/1.1
Host: target.com

Here:

• /api/devices is the endpoint.
• The server might return a list of devices in JSON, similar to a library API returning all devices.

Another example:

/api/devices/mobilephone

This could be a more specific endpoint that returns only mobile phones, like a filtered list of "devices " instead of the whole library.

From just these two, you can already see:

• There is a /api base path.
• /api/devices is a collection.
• /api/devices/<something> probably filters or targets a specific subset.

Your first recon goal is to map these patterns: collections, single items, filters, and versions.

What You Need to Learn About an API

Once you've spotted an endpoint, your job is to understand how it behaves. Focus on four things:

1. Input data

• Path parameters: /api/devices/123
• Query parameters: /api/devices?type=mobile&sort=asc
• Body parameters for POST/PUT/PATCH requests (usually JSON or XML).
• Which parameters are required, which are optional, and what types they are (string, number, boolean, object).

2. Supported HTTP methods APIs often support multiple methods on the same path:

• GET – Retrieve data.
• POST – Create data.
• PATCH – Apply partial updates.
• PUT – Replace a resource.
• DELETE – Remove a resource.
• OPTIONS – Ask which methods are allowed.

Example for /api/tasks:

• GET /api/tasks – Retrieves a list of tasks.
• POST /api/tasks – Creates a new task.
• DELETE /api/tasks/1 – Deletes task with ID 1.

When you test different methods, always use low‑priority or test data to avoid breaking anything important.

3. Media formats and content types

APIs often expect data in a specific format and may behave differently depending on Content-Type:

• application/json
• application/xml
• application/x-www-form-urlencoded
• multipart/form-data

Changing the content type can:

• Trigger different parsing logic.
• Produce richer error messages you can learn from.
• Bypass weak filters that only protect one format.

You can change the Content-Type header and reformat the body accordingly. Tools like Burp's Content Type Converter can help convert between JSON and XML quickly.

4. Rate limits and authentication

• Does the API require a token, API key, cookie, or nothing at all?
• Do some endpoints work without auth, while others don't?
• Do you see 429 Too Many Requests quota messages when sending many requests?

This tells you where to look later for broken access control and rate‑limit bypasses.

Human‑Readable vs Machine‑Readable API Documentation

APIs are usually documented so developers know how to use and integrate with them. That documentation is beneficial for recon and often easier to understand than raw traffic.

Human‑readable documentation

• Developer portals, HTML docs, or wiki pages.
• Written for people: explains endpoints, parameters, examples, and usage scenarios.
• Helps you quickly understand what the API is supposed to do.

Machine‑readable documentation

• Structured formats designed to be processed by tools.
• Often written in JSON or YAML, sometimes XML.
• Common formats include OpenAPI/Swagger specs such as openapi.json, openapi.yaml, or swagger.json.

Machine‑readable docs can be used to:

• Automatically generate test requests.
• Build client SDKs.
• Validate requests and responses.

For bug hunters, machine‑readable docs are basically a ready‑made map of all endpoints, methods, parameters, and response schemas.

APIs that are intended for external developers often expose this documentation publicly or semi‑publicly, which makes it ideal recon material.

Discovering API Documentation on a Target

Even if there's no obvious "API Docs" link in the UI, you can still often find documentation by exploring how the app talks to the backend.

Use a proxy and a crawler

• Run the application through a proxy like Burp Suite.
• Use its crawler to map out endpoints.
• Manually browse the application and watch for API‑related paths and JSON responses.

Look specifically for possible documentation paths, such as:

• /api
• /swagger/index.html
• /swagger/ or /swagger-ui/
• /openapi.json or /openapi.yaml
• /api-docs or /v1/api-docs

These are common locations for Swagger UI and OpenAPI specs.

Walk the base paths

If you find a resource endpoint like:

/api/swagger/v1/users/123

Don't stop there. Also test:

• /api/swagger/v1
• /api/swagger
• /api

The interactive docs or raw spec often live at one of those base paths.

Brute‑force likely doc paths

Use a list of common paths and a tool like Burp Intruder or any directory brute‑forcer to try:

• /swagger/
• /swagger/index.html
• /swagger-ui/
• /openapi.json
• /openapi.yaml
• /api-docs
• /docs
• /redoc

Once you find machine‑readable documentation, you can import it into tools like Burp, Postman, or SoapUI to instantly generate requests for all documented endpoints.

Using Machine‑Readable Documentation with Tools

When you have an OpenAPI or Swagger file:

• Import it into Burp Suite with an OpenAPI parser extension.
• Burp will create requests for each defined operation.
• Use Burp Scanner to crawl and audit the documented endpoints.
• Import the same spec into Postman or SoapUI to build a full collection you can easily replay and modify.

This moves you from "guessing paths manually" to "systematically testing everything the backend exposes".

Interacting with API Endpoints

Once you've identified endpoints and, ideally, loaded them into your tools, it's time to interact and observe how they behave.

Using Burp Repeater

Send interesting requests to Repeater to:

• Change HTTP methods (GET, POST, PATCH, DELETE, OPTIONS).
• Adjust headers, including Content-Type and auth headers.
• Add, remove, or modify parameters in the URL, body, and headers.

Watch for:

• Status code changes.
• Differences in response length and content.
• Error messages that reveal validation rules, expected formats, or internal field names.

Sometimes an error message gives you exactly the information you need to craft a valid or more dangerous request.

Using Burp Intruder

Once you know a valid request format, you can use Intruder to:

• Fuzz parameter names and values.
• Try different IDs to discover object enumeration issues.
• Test header variations and custom headers.

You can also use Intruder's HTTP verbs list to automatically cycle through methods on a given endpoint and see what's accepted.

Changing Content Types to Expose More Behavior

APIs may behave very differently based on the content type of the request:

• The JSON parsing path might be well‑secured.
• The XML parsing path might have injection or XXE vulnerabilities.
• Different content types might trigger different validation logic or error messages.

To explore this:

1. Take a known working request, for example:

POST /api/devices HTTP/1.1 Host: target.com Content-Type: application/json {"name": "test-device"}

2. Change Content-Type to application/xml.

3. Reformat the body as XML and resend it.

Observe whether the server:

• Rejects it outright.
• Processes it but behaves differently.
• Returns useful error messages.

Using an automatic converter speeds up this experimentation when switching between JSON and XML.

Finding Hidden Parameters

During recon, you might discover that an API supports undocumented parameters — fields that aren't in the docs or UI, but the server knows how to process them.

Techniques to find hidden parameters:

• Use Intruder to inject candidate parameter names into query strings, request bodies, headers, and cookies.
• Use an extension like Param Miner to automatically guess large numbers of parameter names and detect when the response changes in a meaningful way.
• Pay attention to JSON responses that contain fields you never send; these field names are great candidates to try as request parameters.

Finding hidden parameters can lead to powerful behavior changes, such as toggling flags, changing roles, or triggering admin‑level actions.

Mass Assignment: When Hidden Parameters Turn into Vulnerabilities

Mass assignment (also called auto‑binding) occurs when the backend framework automatically maps request parameters onto internal objects without proper filtering.

Why is it risky in APIs:

• APIs often return full objects with many fields.
• If the server trusts any field you send and binds it directly, you can sometimes set properties that were never meant to be controlled by clients, like role, isAdmin, status, or price.

Typical attack pattern:

1. Inspect a JSON response that includes fields like:

{ "id": 1, "email": "user@example.com", "role": "user", "isAdmin": false }

2. Send a request that includes extra fields:

{ "email": "user@example.com", "role": "admin", "isAdmin": true }

3. If the server does not validate or filter fields properly, these changes might be applied.

Mass assignment bugs usually appear only after you've done solid recon: reading responses, finding hidden parameters, and understanding how objects are structured.

Conclusion: Turn API Recon into a Habit, Not a Guess

A strong API recon process looks like this:

• Start from real traffic and map endpoints.
• Understand each endpoint's inputs, methods, and content types.
• Hunt for both human‑readable and machine‑readable documentation.
• Use tools like Burp (Scanner, Repeater, Intruder), Postman, and extensions to turn docs into real requests.
• Systematically test methods, content types, parameters, and hidden fields.
• Keep an eye out for mass assignment and other logic flaws.

Once you make this style of recon your default, APIs stop being opaque black boxes and become structured, predictable targets where serious bugs are much easier to find.