API Security Testing Tools Compared: What Each One Checks

Imagine a scanner reports 200 OK on every endpoint it hits, while the invoices API still leaks every customer's invoices to any logged-in user. Nothing would necessarily be wrong with the scanner. It may have tested what it was configured to test, using the one identity it was given.

That is the problem with comparing API security testing tools as a ranked list. These tools do different jobs, and the jobs overlap less than the marketing suggests. A spec-driven scanner can test documented endpoints for injection, input-validation and other vulnerabilities. A fuzzer explores how the application behaves under mutated or unexpected input. Neither approach necessarily checks whether customer A can read customer B's invoice: that requires suitable authorisation tests, and some serious API vulnerabilities arise when those checks are missing.

So this post is not a ranking. It compares five categories by what each one actually checks, where each is the right fit, and where each one goes quiet. The pivot is object-level and function-level authorisation (BOLA/IDOR, BFLA, tenant boundaries). These bugs often require multiple identities and application context to test convincingly, and that requirement quickly narrows the field. Borg is one approach among the five, and we will say plainly where it is the wrong choice.

Who each approach is best for

Short answer first, no fake balance.

Spec-driven scanners and DAST are best for teams with a clean OpenAPI spec who want cheap, repeatable coverage of injection, misconfiguration, transport and header problems on every build.

Fuzzers are best for teams whose risk sits in parsing and input handling: file uploads, binary or custom protocols, GraphQL depth and complexity abuse, anything where a malformed request can crash or confuse the service.

Manual proxy testing (a human with Burp Suite or similar) is best when you have a novel, high-stakes flow and a skilled tester who can reason about it. Money movement, a new auth scheme, a one-off pre-launch review.

Posture and runtime monitoring is best for knowing what you are running: shadow APIs, undocumented endpoints, anomalous traffic, drift between spec and production. It is an inventory and detection tool. It does not prove exploitability.

Code-aware testing is best when the bugs you fear are authorisation and business logic: BOLA, BFLA, tenant isolation, billing logic that trusts the client. This is the category Borg sits in, with pentests for whole applications and security reviews for pull requests.

Most API-heavy teams end up with two or three of these. The skill is picking the combination that does not pay twice for the same coverage, which we get to below.

What 'API security testing' has to cover: BOLA, BFLA and business logic

The OWASP API Security Top 10 (2023 edition) ranks Broken Object Level Authorization at number one, Broken Object Property Level Authorization at number three, and Broken Function Level Authorization at number five. Three of the top five are authorisation failures. That ordering highlights how important access control is to API security.

Here are the terms, with no abstraction.

BOLA (object-level): the endpoint accepts an object ID and returns the object without checking that the caller is authorised to access it. GET /api/v1/invoices/4821 works for the user who is permitted to access invoice 4821 and also for users who should not be able to access it. See our walkthrough on IDOR testing for APIs for how this gets found.

BFLA (function-level): a regular user calls a function they are not authorised to use. For example, POST /api/v1/refunds may be hidden in the UI, but if the server fails to enforce the required permissions, a regular user may still be able to call it.

Tenant boundary failures: in a multi-tenant system the caller is legitimate, the object exists, the role is right, and the data still belongs to another organisation. We cover that separately in tenant isolation testing.

Business logic: the server trusts a price, a quantity, a step order or a state transition the client controls. A coupon applied twice. A refund larger than the charge.

These bugs often share one trait: the requests in the exploit can be individually valid. You may see status 200, well-formed JSON and a correct auth header, with no malicious payload to pattern-match. The bug is the relationship between who is asking and what they are asking for. A tool that tests only one identity, or lacks the context needed to establish which objects belong to whom, can miss these flaws. That is the filter we will apply to each category.

The five approaches: spec-driven scanners and DAST, fuzzers, manual proxy testing, posture and runtime monitoring, code-aware testing

Spec-driven scanners and DAST. You feed in an OpenAPI or Postman collection (or let the tool crawl), and it tests discovered endpoints with attack payloads and other checks: SQL injection strings, XSS, path traversal, missing security headers, weak TLS and verbose errors. It can provide broad, repeatable coverage in CI. Its effectiveness depends on the checks implemented, the authentication configured and the endpoints discovered. Where a vulnerability depends on a valid request from one user accessing another user's object, a scan may miss it unless it performs suitable authorisation tests. A specification also describes only the API functionality it documents.

Fuzzers. A fuzzer generates large volumes of mutated input, using random or schema-aware mutation, and watches for crashes, 500s, hangs and anomalous responses. It can find parser bugs, unhandled exceptions, resource exhaustion and some injection paths nobody wrote a signature for. What it detects depends on its test oracle: a fuzzer configured only to detect crashes may miss a BOLA response because the application can return a normal response while exposing data to the wrong user.

Manual proxy testing. A tester routes traffic through Burp Suite or a similar proxy, logs in as multiple accounts, swaps IDs, tampers with state and reasons about the flow. This approach can be particularly effective for authorisation bugs because a skilled human can use business context to investigate unexpected behaviour. The costs can include time, scheduling and decay: the report describes the system as it was during the testing engagement.

Posture and runtime monitoring. These tools can discover endpoints from traffic or cloud configuration, flag undocumented and shadow APIs, track sensitive data flows and alert on anomalies. They help answer "what do we expose," and runtime detection can identify suspicious activity or an attack in progress. Traffic analysis may flag a scraping pattern against sequential IDs, but passive monitoring alone does not establish that an endpoint is vulnerable before an attack occurs.

Code-aware testing. The tester reads source to understand routes, handlers, ownership checks and role models, then tests the running application with that map and suitable user contexts. Borg's pentesting works this way: it tests live applications and APIs with source-code context and generates its own user contexts, so test accounts generally do not need to be supplied. The trade-offs are covered in what code-aware application security testing is.

Comparison table: input, multi-role testing, business logic, proof of findings, CI fit, retesting

Treat the cells as category tendencies, not vendor guarantees. Individual products vary, and you should ask each one directly.

Multi-role testing is one of the rows that separates the field. A tool that cannot act as two different callers cannot directly demonstrate that one caller reached the other's data through a cross-user test. The second row to read is proof. A finding that arrives with a working reproduction gives engineers stronger evidence to investigate and fix it. A finding that arrives as "possible access control issue, confidence medium" may require more investigation before it can be prioritised. See verified security findings for how to tell the difference.

One honest note on Borg's cells: Borg currently allows one active run at a time, and a run cannot be paused, only aborted and restarted. If you need highly parallel scans in a build matrix, a scanner designed for that workflow may fit better.

Where authorisation bugs slip through: caller A, object B, and a worked GET /api/v1/invoices/{id} example

Take a B2B billing API. Two tenants: Acme (user Alice) and Globex (user Gary). Alice owns invoice 4821. Gary owns invoice 5107.

The handler, simplified:

GET /api/v1/invoices/{id}
  require_login()
  invoice = db.invoices.find(id)
  return invoice

It checks that you are logged in. It never checks that the invoice is yours. Now run the five categories against it.

Scanner. It authenticates as Alice, requests /invoices/4821, gets 200 with a valid body. Injection payloads in the path return 404 or 400. No findings. Correct by its own logic.

Fuzzer. It mutates the ID: negative numbers, huge integers, strings, unicode. The server returns 404 or 400 cleanly. No crashes. No findings.

Posture monitoring. It may discover the endpoint, classify the response as containing financial data, and record it in the inventory. Passive inventory alone does not establish that the endpoint has an authorisation flaw. Runtime monitoring may detect suspicious ID enumeration, but detection depends on the signals and rules the product supports.

Manual tester. Logs in as Alice, logs in as Gary in a second session, requests invoice 5107 with Alice's token, and gets Globex's invoice. Finding, with reproduction. This works, and it is slow and point-in-time.

Code-aware testing. Reading the handler shows there is no ownership predicate on the query. The test identities then make the cross-tenant request against the running app and confirm it. The finding carries evidence and reproduction steps. On the PR side, PR review examines code changes in context and can flag similar authorisation issues before they merge, although detection depends on the change and the review's coverage.

The bug here is not subtle. It is invisible because of how the tools are configured: one identity, no knowledge of which object belongs to whom. The same shape repeats for BFLA (Alice calls POST /api/v1/refunds) and for property-level bugs (Alice sends {"role": "admin"} in a profile update). Every one of those requests is valid on its face.

How to combine them without buying overlap

Don't buy five tools. Buy coverage for five questions and notice where two tools answer the same one.

Start with the cheap floor. A spec-driven scanner in CI can provide repeatable coverage of injection, headers, TLS and misconfiguration on every build, depending on the product and configuration. If your spec is accurate, this can be a cost-effective starting point for the stack. It is not your authorisation story, and you should stop describing it as one unless it performs suitable authorisation testing.

Add fuzzing where input handling is a meaningful risk. If you parse uploads, run a GraphQL endpoint with deep queries or accept custom formats, fuzz those surfaces. Plain JSON CRUD APIs can also benefit from fuzzing, particularly for boundary values, unexpected types and resource-consumption issues, but the value depends on the API's complexity and the checks you already run.

Pick one owner for authorisation. This is where teams can double-pay: an annual manual pentest, a scanner with an "access control" module and a monitoring tool that claims BOLA detection may all cover parts of the same bug class. Compare what each actually tests and verifies, then choose an approach that tests with multiple identities and application context, and run it often enough to track your release cadence. That can be a skilled manual tester on a schedule, or code-aware testing running continuously. The comparison in manual pentest vs AI pentest walks through when each wins.

Add monitoring when inventory is the problem. If you cannot list your own endpoints, fix that first, because you cannot test what you do not know exists.

Close the loop on fixes. A finding is done when a retest provides sufficient evidence that it is resolved, not when a ticket moves to Done. Ask every vendor how retesting works. With Borg, an eligible finding linked to a pull request can be retested when that pull request merges, provided automatic retests are enabled and the required integration and configuration are in place. By default, this reviews the merged code change rather than replaying the attack against the running application. Know that distinction before you rely on it.

Verdict: choose each approach if...

Choose a spec-driven scanner or DAST if you have a maintained OpenAPI spec, want automated coverage of known vulnerability patterns on every build, and have a separate answer for authorisation. It is the right floor, not the whole building.

Choose a fuzzer if your API parses complex or binary input, or you have had crashes and resource exhaustion in production. Skip it if your risk is who can see what.

Choose manual proxy testing if you have a single critical flow to review before launch, a tester you trust and no immediate need for repeat coverage. It is particularly useful for complex flows that require human judgement, but repeated engagements can be costly and harder to schedule around weekly releases.

Choose posture and runtime monitoring if your first problem is knowing what you expose, or you need detection in production. Don't expect it to prove an endpoint is exploitable before an attacker does.

Choose code-aware testing, Borg included, if your exposure is BOLA, BFLA, tenant isolation, billing and business logic, and you ship often enough that an annual report may become outdated well before the next assessment. Pentests assess the running application using code context, while PR reviews examine code changes. Confirm what evidence and reproduction steps each type of finding includes.

Where Borg is not the right fit: if you need a self-serve scanner that you can sign up for and run immediately, Borg is not that: there is no self-serve signup. If your whole need is injection and header checks against a documented spec, a conventional scanner may be a simpler and more cost-effective fit. If your main risk is input parsing, a fuzzer may be the better starting point. And Borg does not replace network-level or runtime detection, which require complementary tools and controls.

Conclusion

Pick your authorisation owner first, then fill the cheaper categories around it. If your APIs carry tenant data, money or permissions, the question to ask any vendor is simple: how does it test access across different identities, and what evidence accompanies a finding? If it tests only one identity and provides no evidence of cross-user access, you may still be exposed to the invoices example above.

If you want to see how code-aware testing handles your own routes, book a walkthrough. Bring the endpoint you are least sure about. We'll walk through how a pentest would test caller A against object B, and what a verified finding with reproduction steps looks like in your tracker.