Think like a Developer: API Hacking

🔍 What Does an API Look Like? (Structure Breakdown)

A typical API request looks like this:

GET /v1/user/profile?id=0034 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

Here’s what each part is for and how to spot uniqueness:

Part	What It Does	How to Identify	Why It’s Important
Method (GET/POST)	What action the API is taking	First word in the request line	GET = retrieve, POST = create, PUT = update, DELETE = remove
Endpoint (/v1/...)	The resource being accessed	Always follows method—URL path	Shows version, resource, hierarchy
Query Params (?id=)	Filter or identify specific data	After ?, in key=value format	Can be manipulated or tested for IDOR, SQLi, etc.
Host	The server the API lives on	Usually api.domain.com	Subdomain often used to separate API traffic
Headers	Metadata: auth, format, content-type	Seen as key: value pairs	Auth headers = access control, content headers = data format
Token (JWT/Bearer)	Authenticates the request	Authorization: Bearer [token]	Can be intercepted, decoded, replayed, or forged
Payload (Body)	(For POST/PUT) Contains the data being sent	JSON, XML, or form data in the body	Look for fields, input validation, or hidden logic
Status Code (200, 403)	API’s reply—success, fail, error	Returned in the response	Helps detect broken auth, rate limiting, or abuse

🧪 Example: API Request & Response (Visual)

Request:

POST /v1/register HTTP/1.1
Host: api.coolapp.io
Authorization: Bearer eyJK...sTR1Ng
Content-Type: application/json

{
  "username": "Friza",
  "email": "friza@example.com",
  "password": "StrongPassword123"
}

Response:

{
  "success": true,
  "user_id": "U-998321",
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

✅ What’s unique?

• /v1/register — Maybe telling you versioning and function.

• Bearer token — Signals use of JWTs or OAuth2.

• Body fields — Might tell you what input is required, or vulnerable.

⚔️ How to Identify a Vulnerable or Valuable API

Clue	What It May Reveal
Publicly exposed Swagger docs	Endpoint list, methods, schemas, even testing tools
No rate limiting	Open to brute force, scraping, DoS
Predictable IDs (user_id=12)	Test for IDOR (Insecure Direct Object Reference)
Missing Auth header	Means open endpoint (by design or mistake)
Verbose error messages	Leak logic or stack trace info
JWT with "none" algorithm	Means forgery is possible (exploit!)
CORS misconfigurations	Allows cross-site requests, potential hijack

APIs look like professional conversations between systems. The URL structure, method, headers, and response all give tells about security posture, logic flow, and access points. Like how headers can tell, kind of, what containers the operation are contained in. Which to check with critical thinking, let's check what these trained professional ARE trained FOR upon request unfortunately. API reconnaissance or API enumeration is key in both offensive testing and defensive hardening when being revealed what they're trained to do.

1. Endpoints

APIs are trained to perform specific tasks, and those tasks are exposed through endpoints. For example:

GET /api/v1/users
POST /api/v1/login
DELETE /api/v1/user/1345

Each endpoint tells you:

• What action it's trained to handle

• Which data it's designed to expose, modify, delete

• How sensitive the logic or content might be (ex: /delete, /admin, /payments)

🧠 2. Swagger / OpenAPI / Postman Collections

If you can find a file like:

• /swagger.json

• /openapi.yaml

• /docs

• /api-docs

You're basically seeing the API’s instruction manual. These docs lay out:

• What functions it was trained to provide

• What data it takes in and gives out

• What verbs (GET, POST, DELETE) it accepts

• Any authentication mechanisms it expects

🔍 3. Passive Clues from Headers & Responses

Even if the API isn’t fully documented, you can watch how it reacts.

For example:

• Try sending a GET to an unknown endpoint.

• See if it responds with:
  "Method not allowed" → It knows the path, just not this verb.
  "Unauthorized" → It’s expecting a token.
  "Not found" → It wasn’t trained on this path.

These are tells. Like how a dog trained for guarding reacts to a stranger but not to its owner — the API gives away what it's used to handling.

🧪 4. Test for Behavior via Fuzzing or Mapping

You can fuzz or map to discover hidden behavior:

• Use tools like:

  • ffuf to brute force endpoint paths

  • Burp Suite or Postman to send crafted requests

  • jwt.io to decode tokens and see user roles

If it accepts a certain pattern, it's trained to understand it. If it fails or leaks info, it's trained but poorly.

🔒 5. Training = Logic = Attack Surface

If an API was trained to:

• Accept password resets (/forgot-password)

• Perform file uploads (/upload)

• Handle role-based logic (/admin, isAdmin: true)

That tells you the risk zones and attack points.

Conclusion

Have a nice day!