Broken Object-Level Authorization (BOLA)
BOLA is the most common critical finding in API security assessments. The vulnerability occurs when an API endpoint accepts an object identifier (user ID, order ID, document ID) and returns or modifies that object without verifying that the authenticated user has permission to access it. The pattern is straightforward: User A's token is used to request User B's data by changing an ID in the URL or request body, and the server complies because it trusts the token but never checks ownership.
Why it's missed
Scanners cannot reason about object ownership. Finding BOLA requires testing every sensitive endpoint with two real accounts of different privilege levels side by side, which is exactly how our testers work across every endpoint in scope.
Broken Authentication
API authentication failures go well beyond weak passwords. JWTs accepted with alg: none or signed with a weak shared secret, refresh tokens that remain valid after logout or password change, missing token expiration enforcement, and password-reset tokens that are predictable or reusable are the patterns we find most often. The entire authentication chain, from initial credential exchange to token refresh to logout invalidation, needs to be tested as a single flow.
Why it's missed
Most testing stops at the login endpoint. We test the full token lifecycle: issuance, refresh, revocation, cross-environment replay, and edge cases like concurrent sessions and password-reset race conditions.
Broken Object Property Level Authorization
This class combines two related problems: excessive data exposure (the API returns more fields than the client needs, including PII, internal IDs or financial data) and mass assignment (the API accepts and persists fields that should be read-only, such as role, isAdmin, accountBalance or plan). Both stem from the same root cause: the serializer trusts the schema rather than explicitly defining which fields are readable and writable per role.
Why it's missed
The front end only displays a subset of the API response, so excess fields are invisible in the UI. We inspect raw response bodies field by field and attempt to write back every field we receive to test for mass assignment.
Unrestricted Resource Consumption
APIs without proper rate limiting on authentication endpoints allow credential-stuffing and OTP brute-force attacks. Missing limits on resource-intensive operations (search queries, report generation, file uploads, bulk exports) enable denial-of-service through legitimate-looking requests. GraphQL APIs are particularly vulnerable: deeply nested queries, alias-based batching and unrestricted query complexity can exhaust backend resources with a single request.
Why it's missed
Rate limits often exist on the gateway but can be bypassed with header manipulation, IP rotation or parameter variation. We test the actual enforcement, not just the documented policy.
Broken Function-Level Authorization (BFLA)
BFLA occurs when a regular user can invoke administrative endpoints by guessing or discovering the URL pattern. The API correctly authenticates the user but fails to check whether their role permits the requested action. Common patterns include predictable admin paths (/api/admin/users), HTTP method confusion (a regular user can DELETE a resource they can only GET), and internal endpoints that were never intended to be externally reachable but are.
Why it's missed
Admin endpoints are often excluded from client documentation and therefore from testing. We enumerate every method on every endpoint from the OpenAPI spec and server routes, then test each one with every role in scope.
Server-Side Request Forgery (SSRF)
Any API feature that fetches a URL on the server's behalf is a potential SSRF vector: webhook registration, file import by URL, link preview generation, PDF rendering, and integration callback URLs. In cloud deployments, SSRF can reach the instance metadata endpoint (169.254.169.254) and retrieve temporary IAM credentials, turning a URL-fetching feature into full cloud account compromise. Internal service endpoints, databases, and admin interfaces become reachable from outside.
Why it's missed
Blind SSRF produces no visible response in the API output. We use out-of-band detection infrastructure to confirm every URL-handling feature, including ones that appear harmless like avatar uploads and import endpoints.
Frequently Asked Questions About API Security Testing
What is included in an API security test?
An API security test covers authentication and authorization logic, object-level access control (BOLA), function-level access control (BFLA), mass assignment, rate limiting, input validation, data exposure in responses, and business-logic abuse. Every finding is mapped to the OWASP API Security Top 10 and scored with CVSS 4.0, with proof-of-concept requests and remediation guidance included.
Do you test GraphQL APIs differently from REST APIs?
Yes. GraphQL introduces attack surface that does not exist in REST: introspection exposure, query depth and complexity abuse, batched query attacks, alias-based rate-limit bypass, and field-level authorization gaps in nested resolvers. We test all of these in addition to the standard OWASP API Top 10 categories (BOLA, BFLA, broken auth, etc.) that apply to any API architecture.
How do you test APIs that have no user interface?
We work directly at the HTTP layer using your OpenAPI or GraphQL schema, Postman collections, or raw endpoint documentation. Testing is performed with Burp Suite, custom scripts and API-specific fuzzing frameworks. A user interface is not required. In fact, testing without a UI is how we catch the issues the UI hides: over-fetched response fields, mass-assignment vectors and undocumented endpoints.
Can API security testing be done on production?
Yes, with agreed rules of engagement. We coordinate testing windows, respect rate limits, avoid destructive operations (no DELETE on real data), and use dedicated test accounts. Where possible we recommend a staging environment that mirrors production, but production testing is common and safe when scoped correctly. We agree on all boundaries before testing begins.
Is the retest included in the engagement cost?
Yes. Every API security testing engagement includes one full retest cycle at no additional cost. Once your team has remediated the findings, we re-verify each issue individually and issue a signed closure report confirming what was fixed. This is the document most auditors and enterprise customers ask for directly.