API Security Best Practices

API1: Broken Object Level Authorization

The single most common API finding: an endpoint trusts an object ID in the request path or body without verifying the caller actually owns that object.

What we test: for every endpoint that takes an ID, we substitute IDs belonging to a different test account and check whether the response leaks or modifies that account's data.

How teams fix it: resolve the "current user" from the authenticated session, and scope every database query to that user or tenant; never trust an ID from the request alone.

API2: Broken Authentication

Weak or misconfigured authentication: missing token expiry, predictable API keys, or endpoints that accept expired or unsigned tokens.

What we test: we test token expiry enforcement, signature validation (including algorithm-confusion attacks on JWTs), and whether password-reset or API-key issuance flows can be abused.

How teams fix it: use short-lived, signed tokens validated with a fixed algorithm and key, rotate API keys on a schedule, and apply the same brute-force protections to API auth as you would a login form.

API3: Broken Object Property Level Authorization

Endpoints that return or accept more fields than the client should see or modify, exposing internal flags, other users' data, or allowing privilege escalation via mass assignment.

What we test: we compare full API responses against what the UI actually displays, and attempt to set sensitive fields (e.g. role, isAdmin, accountBalance) on update requests.

How teams fix it: use explicit response and request schemas (allow-lists of fields) rather than serializing entire database models, especially for write operations.

API4: Unrestricted Resource Consumption

No limits on request size, pagination, or computation cost per request, which lets a single client exhaust resources or run up backend costs.

What we test: we send oversized payloads, request unbounded pagination (e.g. ?limit=999999), and test for missing limits on expensive operations like search, export or report generation.

How teams fix it: enforce per-account and per-IP rate limits, cap pagination size, and apply request size limits at the gateway layer.

API5: Broken Function Level Authorization

Admin or privileged endpoints reachable by lower-privilege users, often because the check exists in the UI but not the API itself.

What we test: using a low-privilege account's token, we call every admin and internal endpoint we can enumerate, including ones not linked from the standard UI.

How teams fix it: apply role checks centrally (e.g. route-level middleware or policy engine), and write tests that assert a non-admin token is rejected by every admin route.

API6–API10: Business Flow, SSRF, Misconfiguration & Inventory

The remaining categories cover unrestricted access to sensitive business flows (API6), server-side request forgery via webhook or URL-fetching endpoints (API7), security misconfiguration of the API gateway and CORS (API8), improper inventory management (undocumented or deprecated API versions left reachable, API9), and unsafe consumption of third-party APIs (API10).

What we test: we enumerate API versions and hostnames from DNS, JS bundles and documentation to find "shadow" or deprecated APIs still in production, and test any outbound-fetch features for SSRF.

How teams fix it: maintain a single source of truth for all live API versions, retire deprecated versions rather than leaving them reachable, and apply the same authz and validation rules to data received from third-party APIs as you would user input.

How is API penetration testing different from a regular web app test?

API testing focuses heavily on authorization logic between accounts and roles, since there's no UI to hide unauthorized actions behind. We typically test with multiple authenticated accounts at different privilege levels in parallel, swapping tokens and IDs between them.

Do you need our API documentation (OpenAPI/Swagger) to test effectively?

It helps speed things up and improves coverage, but it's not required: our team also performs endpoint discovery from client applications, JS bundles and traffic capture to find undocumented routes.

We use GraphQL, not REST. Does this still apply?

Yes, with adjustments. Object and field-level authorization (API1, API3) map directly onto GraphQL resolvers and field permissions, and we additionally test for query depth/complexity abuse (a GraphQL-specific form of API4) and introspection exposure in production.

How long does an API penetration test typically take?

For a single API with 20-40 endpoints and 2-3 user roles, most CipherTrivia engagements run 1-2 weeks, including a retest pass after fixes are deployed.