8. Master the Basics, Break the Web: API Basics
1. REST
REST (Representational State Transfer) is an architectural style used to design simple, scalable APIs. It relies on standard HTTP methods (GET, POST, PUT, DELETE) and uses clean, meaningful URLs to represent resources like users, products, or orders. REST APIs return structured data — usually JSON — making them easy to use across different applications and platforms.
Pentest Relevance:
- Understanding REST structure helps identify predictable endpoints and hidden actions.
- Testing focuses on input validation, authentication, authorization, and improper handling of HTTP methods.
- REST often exposes CRUD operations that can be abused when access controls are weak.
💡Example: A REST API for users:
GET /users/10→ Fetch user detailsPUT /users/10→ Update userDELETE /users/10→ Delete user
Pentesters test whether the user 10 can also access or modify other users data.
2. JSON
JSON (JavaScript Object Notation) is a lightweight data format used by most modern APIs to exchange information between clients and servers. It represents data using key–value pairs, arrays, and nested objects, making it easy for both humans and machines to read and write. Because it’s flexible and widely supported, JSON is the default format for REST APIs, mobile apps, and frontend–backend communication.
Pentest Relevance:
- JSON fields can carry user-controlled data that may lead to injection or logic manipulation.
- Changing values in JSON requests helps test authorization, hidden parameters, and business logic flaws.
- Some APIs rely on client-side enforcement — pentesters override JSON fields to expose vulnerabilities.
💡Example: A typical JSON request:
{
"username": "john",
"role": "user"
}A pentester may modify "role": "admin" to see if the server validates it properly.
3. HTTP Verbs in APIs
APIs use standard HTTP verbs to define what action the client wants to perform on a resource. Each verb has a specific purpose and helps create predictable, easy-to-understand API behavior.
GET — Retrieve Data: Used to fetch information from the server without making changes. It is safe and idempotent, meaning multiple GET requests should always return the same result.
POST — Create or Submit Data: Used to create new resources or submit complex information like forms, JSON, or uploads. Commonly used for login, registration, and data submission workflows.
PUT — Replace Existing Data: Replaces an entire existing resource with the provided data. Often used for updating full user profiles or configuration objects.
PATCH — Partial Update: Updates only specific fields of a resource instead of replacing the whole thing. More efficient than PUT when only a small change is needed.
DELETE — Remove Resource: Deletes an existing resource from the server. Common in CRUD APIs for removing users, items, or records.
OPTIONS — Discover Supported Methods: Returns the HTTP methods allowed for a specific endpoint. Used by browsers during CORS preflight checks.
4. Headers in APIs (Auth, Content-Type, Accept)
API headers provide important information that tells the server how to interpret a request and who is making it. They help enforce authentication, define data formats, and manage how clients communicate with the API.
Authorization Header
Used to send credentials or tokens required to access protected API endpoints. Common formats include Bearer tokens (JWTs), API keys, or Basic Auth. The server validates this header to identify the user or application making the request.
Authorization: Bearer <token>
Content-Type Header
Indicates the format of the data inside the request body. Common types include application/json, multipart/form-data, and application/x-www-form-urlencoded. The server uses this header to parse the incoming data correctly.
Content-Type: application/json
Accept Header
Tells the server what type of response the client expects. APIs use this to decide whether to return JSON, XML, or another format. It helps ensure clients and servers communicate in compatible formats.
Accept: application/json
5. Understanding Endpoint Structure
API endpoints follow a structured format that represents resources and the actions that can be performed on them. A well-designed endpoint is predictable, readable, and reflects the object it interacts with — such as users, orders, products, or sessions. Endpoints typically combine a base URL, resource path, parameters, and sometimes versioning.
Base URL: The main API location where all endpoints start. https://api.example.com
Resource Path: Represents the object or collection you’re interacting with. /users, /orders, /products
Resource Identifier: Used to target a specific item inside a collection. /users/10 → refers to the user with ID 10
/orders/423 → refers to order 423
Query Parameters: Optional values added after ? for filtering, sorting, or pagination. /products?category=books&limit=10
Versioning: Helps evolve APIs without breaking existing clients.
Common formats:
/v1/users, /api/v2/orders
💡Example:
GET https://api.example.com/v1/users/25?active=trueBreakdown:
- https://api.example.com → Base URL
- /v1 → API version
- /users/25 → Resource + specific user
- ?active=true → Query parameter
Wrapping up here — next up: Server & Deployment Basics
Catch you soon 🙌,
Abinesh
