Methodology, not chance hits

An API pentest follows a defined methodology, not a gut feeling. Established references such as the OWASP Web Security Testing Guide (WSTG) and NIST SP 800-115 structure the approach into phases. NIST SP 800-115 describes the purpose as planning and conducting technical security tests, analyzing the findings, and deriving countermeasures, with emphasis on concrete techniques and their benefits and limitations.

Applied to an API, this yields a reproducible sequence:

  1. Recon and discovery: capture endpoints, parameters, versions and documentation (e.g. OpenAPI specifications), including undocumented or outdated endpoints.
  2. Auth analysis: how are sessions, tokens (e.g. JWT) and roles issued and checked?
  3. Authorization testing: systematically working through authorization flaws at the object, function and property level.
  4. Fuzzing and input validation: send unexpected values, types and formats to every parameter.
  5. Business logic testing: check whether the business logic can be defeated by deviating orders or manipulated steps.
  6. Finding and documentation: every hit is backed by a traceable request/response.

The WSTG assigns these building blocks firmly, for example 4.1 Information Gathering, 4.4 Authentication Testing, 4.5 Authorization Testing and 4.10 Business Logic Testing.

Vulnerability classSignature-/pattern-based scannerManual API pentest
Known CVE / outdated componentreliable (version/pattern recognition)supplementary
Injection with a known payloadoften detectable (payload pattern)verified, reduces false positives
BOLA (object level)practically not (no pattern, context-dependent)core method (multi-user testing, ID manipulation)
BFLA (function level)no (legitimate calls, no payload)role/hierarchy analysis, method/URL probing
BOPLA (property level)rarely (mass assignment is context-dependent)targeted property tests
Business logic flawsno (no understanding of context)core domain (creative probing)

What finds what: scanner vs. API pentest

Why scanners miss logic and authorization flaws

Signature- and pattern-based scanners look for known patterns: dangerous payloads, telltale error messages, known vulnerable versions. But authorization and logic flaws have no such pattern. The WSTG puts it directly: One reason automated tools are bad at testing for vulnerabilities is that they can't think creatively. Creative thinking has to happen case by case, because almost every application is uniquely built, even when using common frameworks.

This is especially clear with the authorization flaw Broken Function Level Authorization (BFLA): per the OWASP API Security Top 10 2023, exploiting it requires the attacker to send legitimate API calls to an endpoint they shouldn't have access to. There is no malicious payload, no pattern a scanner could recognize: the call looks like any other valid request. Whether it should be allowed only follows from the caller's role and the business context.

On business logic, the WSTG writes that automated tools struggle to understand context, which is why such tests fall to a human. This class of flaws cannot be detected with a tool or scanner and depends on the tester's skill and creativity. That's the dividing line: scanners find patterns, a pentest finds logic.

Systematically probing BOLA, BFLA and BOPLA

The three authorization classes of the OWASP API Security Top 10 2023 are tested in a pentest deliberately and separately, because they break at different levels.

BOLA (API1:2023) - object level

What's tested is whether an authenticated user can access other people's objects by manipulating an object ID. The canonical method from the WSTG (Insecure Direct Object References): create at least two users, each with their own objects, map every place where input directly references objects, and then try to access user B's objects using user A. Multiple users save time, because real foreign IDs are available instead of guessed values.

BFLA (API5:2023) - function level

Here it's tested whether a regular user can access functions they're not entitled to. OWASP names as guiding questions: can a normal user reach administrative endpoints? Can they trigger sensitive actions just by changing the HTTP method (e.g. from GET to DELETE)? Can a user from group X call a function meant only for group Y by guessing the URL, e.g. /api/v1/users/export_all?

BOPLA (API3:2023) - property level

Per OWASP, APIs often return all of an object's properties. What's tested is whether the API exposes too many properties (excessive data exposure) or accepts properties the user shouldn't be allowed to set (mass assignment), such as a role or is_admin field in the request body. Per OWASP, all three classes are easy to find (Detectability Easy), but only through targeted probing, not signature detection.

Fuzzing and business logic testing

Fuzzing supplements the authorization tests: unexpected values, wrong types, boundary values and special characters are sent to every parameter to test input validation, error handling and injection paths (WSTG 4.7 Input Validation Testing). Fuzzing can be partly automated, but evaluating the responses remains the tester's job, because an unusual response isn't automatically a vulnerability.

Business logic tests check factual consistency. The WSTG asks, in essence: if an authentication flow expects steps 1, 2, 3 in that order, what happens if a user jumps straight from step 1 to step 3? Does the application then wrongly grant access (fail open), deny it, or abort with a 500 error? Typical checkpoints are:

  • Skipping or reordering steps in multi-step flows (e.g. purchase, approval, payment).
  • Repeatedly calling a function beyond its intended limits.
  • Manipulating values between steps, such as a price lowered after the fact before the tender.
  • Race conditions and timing, to bypass locking or reservation logic.

These tests require understanding the developer's intent and, per OWASP, are at once among the hardest to detect and often the most damaging when exploited.

Manual, automated, continuous

The WSTG warns against the one-method fallacy: many organizations have historically relied solely on penetration testing, which is too little too late in the development cycle. A balanced approach is recommended, combining manual review, source code review and automated testing. NIST SP 800-115 correspondingly emphasizes the respective strengths and limits of each technique.

The three modes play different roles:

  • Automated (DAST/SAST/SCA): fast, broad, and suited for CI/CD, to catch the obvious vulnerabilities (low hanging fruit) after every release. Finds no authorization or logic flaws.
  • Manual: context-aware and creative, finds BOLA/BFLA/BOPLA and business logic flaws, but is point-in-time and resource-intensive.
  • Continuous: ongoing repetition of the tests, because APIs keep changing and every new endpoint creates new authorization paths.

Venedy addresses exactly this gap: context-aware, ongoing authorization and logic testing on your own API, with a traceable finding instead of an opaque rating.

The reproducible finding

A pentest result is only usable if it's backed reproducibly. The WSTG warns that a superficial review creates a false sense of security, which can be as dangerous as no review at all. Findings must be carefully verified and false positives weeded out, since a false report can undermine the validity of the rest of the report.

A solid API finding therefore contains:

  • the exact request (method, path, headers, body, token or role used),
  • the corresponding response (status code such as 200 OK, headers, relevant body excerpt),
  • proof of the authorization violation, i.e. that the response shows other people's data or an impermissible action,
  • the steps to reproduce it, and the affected user/role combination.

Only this request/response evidence turns a suspicion into a verifiable finding that developers can reproduce, fix, and lock down with a regression test. That's the difference between a scanner report full of pattern matches and a pentest that proves logic.

Sources

Keep reading
OverviewOWASP API Security Top 10 API1Broken Object Level Authorization API6Unrestricted Access to Sensitive Business Flows