🔌 API Security Testing

Methodology

1. 01

   Reconnaissance & Endpoint Enumeration

   Enumerate API endpoints, parameters, authentication flows, and data models from OpenAPI/Swagger documentation, traffic capture, JavaScript analysis, and active crawling.

2. 02

   Authentication & Authorisation Testing

   Test for broken object-level authorisation (BOLA/IDOR), broken function-level authorisation, JWT algorithm confusion, OAuth2 flow attacks, API key exposure, and privilege escalation.

3. 03

   Input Validation & Injection

   Test all parameters for SQL injection, command injection, XXE, SSRF, mass assignment, and excessive data exposure in response bodies.

4. 04

   Business Logic & Rate Limiting

   Identify rate limiting bypasses, resource exhaustion attacks, business workflow flaws, and replay attack opportunities unique to the application's logic.

5. 05

   Reporting & Remediation Support

   Produce a prioritised finding report with severity ratings, full exploit evidence, and developer-focused remediation guidance. Retesting included within 30 days.

What You Get

• ✓ API endpoint inventory with attack surface mapping
• ✓ Detailed finding report with CVSS scores and proof-of-concept
• ✓ OWASP API Top 10 coverage matrix
• ✓ Developer-focused remediation guidance
• ✓ Free retesting credit (30-day window)

Frequently Asked

What API types do you test?

We test REST, GraphQL, and gRPC APIs. We also cover WebSocket connections, webhook endpoints, and server-sent event streams where they process or expose sensitive data. Mobile backend APIs and microservice-to-microservice communication are also in scope.

Do we need to share source code for an API security test?

No — a black-box test only requires the API base URL and documentation (OpenAPI spec, Postman collection, or equivalent). For a more thorough grey-box assessment, we also review authentication and authorisation code. White-box review includes full source access and produces the most comprehensive findings.

What is BOLA/IDOR and why is it ranked #1 in the OWASP API Top 10?

Broken Object Level Authorisation (BOLA), also known as Insecure Direct Object Reference (IDOR), occurs when an API exposes direct references to internal objects (e.g. user IDs) without validating that the requesting user has permission to access them. It is ranked #1 because it is both extremely common and often highly impactful — a single BOLA vulnerability can expose the entire user database.