API Testing

Why it matters

What this protects you from

• The interface is not the boundary

  If a rule is enforced only by the app that calls the API, it is not enforced. Attackers call the API directly.

• Broken object authorization is everywhere

  Changing one identifier in one request is the single most common way records leak. It requires no tooling.

• Scanners barely touch APIs

  Without a schema and valid tokens, automated tools see almost nothing. This work is manual or it is not happening.

• Integrations widen the surface

  Every partner integration, webhook and service token extends who can reach your data and under what conditions.

Coverage

What we test

• Object and function level authorization

  Whether identifiers can be swapped across users, tenants and roles, tested on every state-changing endpoint in scope.

• Authentication and token scope

  Token type confusion, scope enforcement, expiry and revocation, and whether privileged claims can be influenced by the client.

• Mass assignment and input handling

  Whether unexpected fields are accepted and persisted, plus injection across parameters, headers and request bodies.

• Rate limiting and resource controls

  Whether limits are enforced server-side and whether client-controlled headers can be used to bypass them.

• Schema and introspection exposure

  GraphQL introspection, verbose errors, and documentation endpoints that reveal more surface than intended.

• Business logic across endpoints

  Sequencing, value tampering and race conditions that only appear when endpoints are combined rather than tested alone.

Approach

Three ways to run it

• Black box

  Endpoints discovered from traffic and public documentation, with no schema supplied. Mirrors an external attacker.

• Grey box

  Schema or collection plus test accounts across each role. The most efficient choice, and what we usually recommend.

• White box

  Schema, accounts and source code, so authorization logic can be traced to where it is actually enforced.

Process

How the engagement runs

1. 01

   Scoping and threat alignment

   We agree endpoints, environments, roles, rate limits and exclusions in writing, then map the surface and its trust boundaries.

2. 02

   Enumeration and schema mapping

   Full endpoint, parameter and role mapping, including undocumented routes found in traffic or client bundles.

3. 03

   Authorization matrix testing

   Every role tested against every in-scope endpoint systematically, because this is where the serious findings live.

4. 04

   Targeted exploitation

   Confirmed exploitation of authorization, injection, logic and rate limiting weaknesses, with evidence captured.

5. 05

   Reporting and remediation

   Findings written with the exact request and response, so a developer can reproduce them without guessing.

6. 06

   Retest

   After remediation we retest the affected endpoints and issue a retest summary confirming closure.

Standards

What we test against

OWASP API Security Top 10

The primary reference for this work, covering the authorization and object-level failures that dominate real API findings.

OWASP ASVS

Verification requirements for authentication, session management and access control, applied at the API layer.

OWASP Web Security Testing Guide

Individual test cases for input handling and session management, so coverage is reproducible between engagements.

NIST SP 800-115

Overall assessment structure, which is what procurement teams expect to see referenced.