The Anatomy of Web APIs

Most of what users see and click in a web application GUI is powered behind the scenes by APIs. Web APIs serve as the backbone for modern applications, transferring data and invoking functions over the web using HTTP.

This chapter explores the structure, types, behaviors, and security implications of web APIs, forming a crucial foundation for API security testing and exploitation.

🧬 How Web APIs Work

Like web apps, APIs follow a client-server model, communicating via HTTP(S). A client (like a frontend or mobile app) makes requests to API endpoints, which are typically URLs like:

1https://example.com/api/v3/users/ 
2https://example.com/api/v3/customers/

🔖 Resource Naming

• Singleton Resource: /api/user/{user_id}
• Collection: /api/profiles/users
• Subcollection: /api/user/{user_id}/settings

These define what data the client wants, and how it should be accessed or manipulated.

🚪 The API Gateway

API requests pass through an API gateway, which handles:

• Request filtering
• Load balancing
• Routing to microservices
• Authentication & authorization
• Rate limiting
• SSL termination

🧱 Microservices Architecture

Each API endpoint might trigger actions in one or more microservices, which are modular components of an app’s backend.

Example microservices in an e-commerce app:

• 🧾 Billing
• 🧍 User Accounts
• 📧 Emailing Receipts

🧾 API Contracts & Docs

A well-documented API exposes:

• Endpoint paths & variables
• Request methods (GET, POST, etc.)
• Authentication mechanisms
• Permissions
• Input formats & parameter types

Example:

1DELETE /applications/{client_id}/grants/{access_token}

⚙️ CRUD & REST Fundamentals

APIs typically support CRUD operations:

✅ REST Constraints

RESTful APIs typically follow these six architectural constraints:

1. Client-Server Separation
2. Stateless Interactions
3. Cacheable Responses
4. Uniform Interface
5. Layered System
6. (Optional): Code on Demand

REST is a style—not a strict protocol. APIs may deviate or partially implement it.

🧾 Sample REST API Call

Request:

1GET /api/v3/inventory/item/pillow HTTP/1.1
2Host: rest-shop.com
3Accept: application/json

Response

1{
2"item": {
3  "id": "00101",
4  "name": "pillow",
5  "count": 25,
6  "price": {
7    "currency": "USD",
8    "value": "19.99"
9  }
10}
11}

🔄 API Data Formats

APIs use standardized formats to structure requests/responses.

✅ JSON (JavaScript Object Notation)

• Lightweight
• Human-readable
• Widely supported

📄 XML (Extensible Markup Language)

• Verbose
• Tags wrap content
• Used in legacy systems or SOAP APIs

📜 YAML

• More readable than JSON
• Used in OpenAPI specs, config files

🔐 API Authentication Schemes

Different levels of protection for API access:

🧪 APIs in Action – Twitter Example

Request:

1POST /1.1/jot/client_event.json?q=hacking HTTP/1.1
2Host: api.twitter.com
3Authorization: Bearer AAAAAAAAAAAA...

Response:

1{
2"created_at": "...",
3"full_text": "1984: William Gibson published his debut novel...",
4"user_mentions": [],
5"hashtags": ["cyberpunk"]
6}

This demonstrates:

• Use of Bearer tokens
• REST-like structure
• JSON formatting

🚨 Security Implications

• Too Much Info: Overexposed JSON can leak internal fields
• Broken Auth: APIs can misidentify users
• Insecure Defaults: Some APIs skip auth for public endpoints
• Misconfigured Rate Limits: Brute-force & scraping risks

Pro tip: Public API documentation can unintentionally expose admin endpoints or auth logic—always review it thoroughly.