API testing

API testing is the process of sending requests directly to an API’s endpoints and checking that the responses meet expectations for functionality, reliability, performance, and security.

What API testing focuses on

API tests validate that each endpoint does the right thing with given inputs, returns correct data and status codes, enforces authentication/authorization, and handles errors safely. Because APIs usually lack a graphical interface, this testing happens at the message layer (HTTP methods, headers, payloads like JSON or XML) instead of through the UI.

API Reconnaissance Techniques

API reconnaissance focuses on discovering all the APIs, endpoints, and parameters you can interact with before you start heavy testing, so you see the real attack surface instead of just what the UI shows.

Mapping hosts and endpoints

Start by enumerating subdomains and hosts likely to expose APIs (for example, api.example.com, dev-api.example.com) using tools like Amass or similar subdomain finders, then probe them for open HTTP services. Next, discover endpoints by crawling traffic through an intercepting proxy, using endpoint/route fuzzers like Intruder or API‑focused tools such as KiteRunner with targeted wordlists to brute‑force common paths like /api/v1/users, /auth/login, or /admin/*.​

Mining documentation, JavaScript, and OSINT

Public docs, SDKs, OpenAPI/Swagger specs, and help centers often leak real endpoint paths, parameters, and request examples; scraping these to build custom wordlists greatly improves discovery. On the front end, enumerating JavaScript files and parsing them with tools like LinkFinder or similar scripts can reveal hidden API endpoints and even hard-coded keys or tokens that never appear in the visible UI.​

Parameter and behavior discovery

Once core endpoints are known, parameter fuzzing helps you uncover hidden or undocumented fields such as is_admin, role, limit, or experimental flags that change behavior. Techniques include sending requests with guessed parameter names, leveraging tools like Param Miner, and varying HTTP headers (for example, X-HTTP-Method-Override, X-Forwarded-For) to see how the API reacts, which often exposes extra logic, debug features, or alternate code paths worth deeper testing.

API Schema / API Blueprint

API schema and API Blueprint are both ways to describe how an API works in a precise, machine- and human-readable format.​

API schema (OpenAPI-style)

An API schema is a structured definition of an API’s endpoints, methods, parameters, request bodies, and response shapes, usually written in OpenAPI (formerly Swagger) using JSON or YAML. By formalizing data types and operations in a schema, teams can auto-generate documentation, client SDKs, server stubs, and validation, ensuring everyone shares the same contract for how the API should behave.​

API Blueprint

API Blueprint is a high-level, Markdown-based language for describing web APIs in a more narrative, documentation-first style. A Blueprint file (.apib) mixes headings, examples, and structured blocks to define resources, actions, request/response payloads, and headers, making it easy for both technical and non-technical stakeholders to read while still being parsable by tools like Apiary.​

When to use which

OpenAPI schemas tend to be preferred when strong tooling, code generation, and strict validation are priorities across large systems. API Blueprint can be attractive for design-first workflows where teams want to sketch and iterate on API behavior directly in Markdown while keeping the document close to product-style prose.​

Mapping API Endpoints

Mapping API endpoints is about building a complete list of every URL path, method, and parameter your API exposes so you know exactly what to test and protect.​

Gathering endpoints from existing sources

Start with what you already have: proxy or browser DevTools logs, server logs, and any OpenAPI/Swagger specs or internal docs. Capture each request’s path (for example /api/v1/users), HTTP method, auth type, and main parameters, and record them in a central inventory or spreadsheet so you can see coverage and duplicates.​

Discovering hidden and undocumented routes

To go beyond what the UI shows, probe common API base paths (/api, /api/v1, /mobile, /admin) and use route/wordlist fuzzing tools to brute-force potential endpoints. Combine this with JavaScript/code review and passive recon to uncover extra endpoints, then extend your inventory with notes about which roles can access each one, forming a full map that drives deeper security and functional testing.

Detecting Concealed Parameters

Detecting concealed parameters means finding extra query/body fields, headers, or cookies that the backend uses even though the UI never exposes them, which often reveals hidden features or insecure logic paths.​

Practical techniques

A common approach is parameter fuzzing: take a valid request and systematically add many candidate parameter names while monitoring for changes in status codes, response size, or content. Tools such as Burp Param Miner, x8, or ZAP Param Digger automate this by injecting parameter wordlists (for example admin, role, debug, redirect, test, preview, limit) and highlighting which ones cause meaningful response deltas.​

Example workflow

1. Normal request seen in proxy:
GET /api/v1/profile HTTP/1.1
Host: example.com
Authorization: Bearer <token>

2. Fuzzed request with guessed parameters:
GET /api/v1/profile?debug=true&is_admin=1 HTTP/1.1
Host: example.com
Authorization: Bearer <token>

3. If debug=true suddenly adds stack traces or verbose error messages, or is_admin=1 makes the response include extra fields (for example, other users’ data or admin-only options), that indicates those concealed parameters are understood and acted on by the server despite not appearing in the UI or documentation.

Securing APIs Against Vulnerabilities

Securing APIs against vulnerabilities means combining strong design, strict access control, and continuous testing so exposed endpoints do not become the easiest way into your systems.​

Strong authentication, authorization, and least privilege

Every sensitive endpoint should require robust authentication (for example OAuth 2.0/OIDC for user-facing APIs, signed keys or mTLS for service-to-service) rather than relying on simple static tokens. Enforce fine-grained authorization on the server using roles or scopes, apply least privilege to tokens and API keys, and rotate/expire credentials so a stolen token has limited value.​

Input validation, rate limiting, and data minimization

Validate and sanitize all inputs (paths, query params, bodies, headers) using allowlists, length and type checks, and parameterized queries to prevent injection, mass assignment, and deserialization attacks. Limit how often and how much clients can call each endpoint with rate limiting and quotas, and minimize data exposure by returning only necessary fields, avoiding debug information, and filtering sensitive values from responses and logs.​

Defense-in-depth with gateways and transport security

Place APIs behind an API gateway or reverse proxy that centralizes TLS termination, authentication, logging, and coarse-grained access controls like IP filtering and geo/risk-based rules. Enforce HTTPS/TLS for all external and internal API traffic, use modern cipher suites, and consider a WAF or API-specific security solution to detect and block common attack patterns such as injection, broken object-level authorization, or excessive data scraping.​

Continuous discovery, testing, and monitoring

Maintain an up-to-date inventory of all APIs, versions, and exposed hosts so shadow or deprecated APIs do not become unmonitored backdoors. Integrate static analysis, dynamic scanning, and dedicated API security tests (including checks aligned to the OWASP API Security Top 10) into CI/CD, and monitor production traffic for anomalies such as unusual error spikes, brute-force patterns, or data exfiltration attempts, responding quickly to alerts.​