The API breaches that make the news are rarely clever. Somebody noticed that changing a number in a URL returned somebody else’s data. The endpoint required authentication, the token was valid, the request was well formed, and the server cheerfully returned a record belonging to a different customer because nobody checked whether this customer owned that object.
Now look at what your security scanner reported that quarter. Missing headers. A TLS configuration note. An injection candidate that turned out to be a false positive. Nothing about the one flaw that actually gets exploited, because the scanner had no way to know the record belonged to someone else. It saw a 200 and valid JSON, which is exactly what success looks like.
That is the central problem in this category. Broken object level authorization is the most common serious API flaw, and it is the one automated tools are structurally worst at finding, because detecting it requires business context: knowing which objects belong to which identity, and having at least two identities to compare. Everything else in an API security testing purchase is secondary to how a tool handles that.
This guide covers what the OWASP taxonomy is and is not, why authorization flaws resist automation and what technique actually finds them, how to fit any of this into a pipeline without making the pipeline hated, and then the tools. Most readers are adding security testing to an API estate that already exists and is already in production, so the emphasis is on retrofitting rather than on a clean start.
Key takeaways
- Broken object level authorization cannot be found by a single-identity scan. Detection requires replaying one identity’s requests with another identity’s credentials and comparing the responses.
- Unguessable identifiers are not authorization. A UUID makes enumeration harder and does nothing about an attacker who legitimately obtained the identifier from a share link, an export, or a previous role.
- Spec-driven scanning only covers endpoints the spec knows about, so discovery of undocumented endpoints comes first. A shadow endpoint is invisible to every spec-based tool you own.
- The hard part of CI integration is authenticated, stateful scanning. A scanner that cannot keep a session, or that pollutes shared data, gets disabled within a month regardless of what it finds.
The OWASP API Security Top 10: a taxonomy, not a product
Every vendor in this category advertises coverage of the OWASP API Security Top 10, which makes it worth being precise about what that is. It is a community-produced awareness document listing the categories of risk most commonly found in APIs, maintained as a specification-style artifact with no vendor, no licence and no bill. You cannot buy it, you cannot install it, and no tool “implements” it in any meaningful sense.
Its value is that it gives the industry shared names for problems that used to be described differently by everyone: object level authorization, function level authorization, property level authorization, unrestricted resource consumption, broken authentication, unsafe consumption of third-party APIs, improper inventory management, and so on.
What it gives you
- A shared vocabulary, so “we have a BOLA problem on the orders endpoint” means the same thing to your engineers, your pentester and your auditor
- A prioritised starting point for threat modelling that reflects what is actually found in real API assessments, rather than a generic web application list
- A checklist structure that maps cleanly onto review gates and onto the questions a customer security questionnaire will ask
- Explicit recognition that authorization, not injection, is the dominant API risk category, which is the correct framing and the one older web-focused lists get wrong
What it does not do
- It does not tell you whether your API has any of these flaws. It is a list of categories, not an assessment
- It does not define test procedures, so two tools claiming full coverage may be doing entirely different and non-comparable things
- Coverage claims against it are largely unfalsifiable marketing, because a tool that sends one authorization probe and a tool that systematically replays every recorded request across identities can both claim to cover the same item
- It says nothing about your business logic, which is where the exploitable instances of its top categories actually live
- It is a periodic snapshot of community consensus, not a standard with conformance testing behind it
Use it to structure your threat model and your reporting. Do not use it as a procurement checklist, because every vendor ticks every box.
Why BOLA resists automation
Broken object level authorization is simple to describe. A request identifies an object, usually by an identifier in the path, a query parameter, a request body, or a nested field inside a body. The server authenticates the caller, then acts on the object without verifying that this caller is entitled to that object. Change the identifier, get somebody else’s data.
The reason scanners struggle is the oracle problem. To know that a request succeeded improperly, the tool must know three things simultaneously: that this object belongs to a different principal, that the response contains that principal’s data, and that returning it was not intended. A conventional scanner operating with one set of credentials knows none of these. It sends a request, gets a 200, and has no basis for calling it a finding.
The technique that works is cross-identity replay. Provision two accounts in different tenants or with different roles, call them A and B. Exercise the API as A, recording every request including the object identifiers involved. Then replay each of A’s requests using B’s credentials and examine what comes back. A 403 or 404 is correct. A 200 carrying A’s data is a finding, and it is a finding with a reproduction attached, which is what makes it actionable rather than a maybe.
Three refinements separate a tool that does this well from one that does it superficially:
Identifiers are not only in the path. They appear in query strings, in JSON bodies, in nested arrays of objects, in batch operations that carry a list of identifiers, in filter expressions, and in GraphQL variables and global node identifiers. A tool that only mutates path segments will miss most real instances. Batch and bulk endpoints are particularly rich, because authorization is frequently checked once for the request and not per item in the list.
The response comparison is the hard part. A 200 alone is not proof, because a correctly behaving API might return an empty result or a redacted view. The useful signal is a diff: replay the same request as A and as B and compare the response bodies. Identical non-empty bodies mean B saw A’s data. Structurally different bodies mean something is being filtered, which may be correct or may be partial exposure. This is why tools that record a baseline per identity produce far better results than tools that probe blindly.
The neighbouring categories need the same treatment. Broken function level authorization is the same test aimed at operations rather than objects: can a normal user call the administrative endpoint, and can a read-only role perform a write. Broken object property level authorization splits into two directions: can B read a field in the response they should not see, and can B write a field in the request they should not be able to set, which is mass assignment. The write direction is the one most tools neglect and the one that escalates privileges.
A few things that look like defences and are not. Unguessable identifiers are not authorization; they are an obstacle to enumeration, and identifiers leak constantly through share links, exports, support tickets, referrer headers and previous employment. Client-side filtering is not authorization; if the server returned the data, it was disclosed. Checking the tenant identifier supplied by the client is not authorization; that value came from the attacker. The only correct check derives the tenant from the authenticated session and applies it in the data access layer, which is exactly why centralised policy engines exist and why the authorization services decision matters more than the scanner you buy.
Needs first-hand data: Set up two tenants with known data, record a full functional test run as tenant A, then replay every recorded request with tenant B’s token and classify each response as correctly denied, correctly empty, or improperly returning A’s data. Report the count of endpoints in each bucket alongside the total endpoint count. That ratio is the only honest measure of your API’s authorization posture, and running it once will tell you more than a year of scanner reports.
Getting this into CI without the pipeline becoming useless
An active security scan is slow, stateful and noisy. A pull request check is expected to be fast, deterministic and quiet. Reconciling those is the practical problem, and getting it wrong is how security testing ends up permanently disabled with a Jira ticket nobody will action.
Tier the checks by what changed. A specification lint and a static audit of the OpenAPI document are fast enough to run on every pull request, and they catch the whole class of problems where an endpoint declares no security scheme, accepts an unbounded array, or omits a response schema. A targeted authorization replay limited to the routes touched by the diff is the next tier, and it is the highest-value gate you can run on a pull request. A full active scan belongs on a schedule against a dedicated environment, not in the pull request path.
Authenticated scanning is where most implementations fail. The scanner needs to obtain a token, refresh it before expiry, and avoid invalidating its own session. This breaks in predictable ways: the scanner hits the logout endpoint and loses its session, a request triggers a password change or a token revocation, multi-factor authentication blocks programmatic login, or the token expires mid-scan and every subsequent finding is a spurious 401. Budget real time for this. It is the difference between a scan that covers your API and a scan that covers your login page, and an unauthenticated scan of an authenticated API is close to worthless.
Plan for state. Active scanners create, modify and delete data, and they do it with fuzzed values. Point one at a shared staging environment used by QA and you will break QA. Point it at anything integrated with a real payment or email provider and you will send real things to real people. The setup that works is an environment that can be reset to a known state before each run, with third-party integrations stubbed, and with a scan-scoped account whose blast radius is bounded.
Baseline aggressively. The first full scan of an existing API produces a wall of findings and the team’s reaction determines whether the tool survives. Accept the initial set as a baseline, fail the build only on findings that are new relative to it, and work the baseline down as a separate stream of work. A gate that fails on pre-existing findings gets bypassed on day three and never re-enabled.
Do not run active scans against production unless you have deliberately decided to, with rate limits, a scoped account, and the on-call team informed. The polite version, which is a spec audit plus passive analysis of mirrored traffic, is safe and still finds the inventory problems.
Needs first-hand data: Measure your scan’s actual endpoint coverage rather than trusting the summary. Instrument the target application to log every route that received a request during the scan, then compare that list against your full route table. The gap, especially for authenticated and deeply nested routes, is usually much larger than the tool reports, and it is the number that tells you whether your scan means anything.
42Crunch
42Crunch is built around the OpenAPI document rather than around traffic. It statically audits a spec against a large set of security rules and scores it, then runs a conformance scan that generates traffic directly from the spec to check the implementation actually matches what it declares, and finally offers a runtime firewall that enforces the spec at the edge. The chain from design-time to runtime is the distinctive idea: the same document is the gate, the test and the policy.
Pros
- Static spec audit is fast enough to run on every pull request and catches declared-but-insecure design before any code exists, which is the cheapest possible place to fix it
- Conformance scanning checks whether the implementation matches the contract, which catches the gap between a well-written spec and a permissive implementation
- The runtime enforcement layer turns the spec into a positive security model that rejects anything the contract does not describe, which is a genuinely strong control
- Scoring gives teams a concrete, trackable target, which works better than a findings list for driving improvement across many services
Cons
- Everything depends on the spec being accurate and complete, so an estate with hand-written or stale specs gets little value until that is fixed first
- Spec-driven means blind to undocumented endpoints by construction, and shadow endpoints are exactly where the unreviewed risk lives
- Business logic and cross-identity authorization testing are weaker than the specialists, because a spec describes shape and not entitlement
- Enterprise-oriented in packaging and process, which is heavy for a small team wanting a scanner in a pipeline
Best for: Organisations that already treat OpenAPI as the source of truth and want design-time, test-time and runtime enforcement derived from one document.
Pricing: Enterprise subscription tiering on APIs and users with the runtime enforcement component licensed separately, negotiated rather than self-serve.
Escape
Escape approaches API security testing from the business-logic direction, with roots in GraphQL testing where conventional scanners are especially weak. It discovers APIs, explores them by building a model of the schema and relationships, and generates tests driven by that model rather than by a fixed payload list, which is the approach that has a chance of finding authorization flaws rather than only injection candidates.
Pros
- Model-driven exploration produces far better coverage on GraphQL than payload-list scanners, which mostly fail against a single endpoint with a typed schema
- Business logic and authorization tests are the design centre rather than an add-on, which is the right emphasis for API-specific risk
- Discovery of exposed APIs across your estate addresses the inventory problem before scanning, which is the correct order of operations
- Agentless operation removes the deployment friction of installing collectors or proxies across many services
Cons
- Newer and smaller than the established players, so third-party operational knowledge and integration breadth are thinner
- Automated business logic testing is genuinely hard, and the honest expectation is that it surfaces candidates a human must confirm rather than delivering certainties
- Cross-identity testing quality depends entirely on how well you configure the identities and their expected entitlements, which is setup work nobody enjoys
- Managed platform orientation makes a fully self-contained deployment a weaker story than the open-source options here
Best for: Teams with substantial GraphQL surface or complex authorization models where payload-based scanners have already proved useless.
Pricing: Subscription tiered by number of APIs or applications scanned, with enterprise agreements above that.
Akto
Akto builds its API inventory from observed traffic, typically through mirroring or a connector, then generates security tests against the discovered endpoints, with explicit support for multiple authentication contexts so that authorization tests can compare what different roles and tenants can reach. An open-source core makes self-hosting a real option, which matters when the tool will hold your full API inventory and sample payloads.
Pros
- Traffic-based discovery finds endpoints no spec knows about, which fixes the inventory gap that makes every spec-driven tool incomplete
- First-class support for multiple authentication contexts is what makes genuine cross-identity authorization testing possible rather than simulated
- Open-source core with a self-hosting path keeps API inventory and captured payloads inside your network
- Test templates are editable and extensible, so organisation-specific authorization rules can be encoded rather than approximated
Cons
- Traffic mirroring is real infrastructure work to set up correctly, and incomplete mirroring produces a confidently incomplete inventory
- Captured traffic includes sensitive payloads, so redaction and access control on the inventory store are load-bearing from day one
- Broad feature surface across discovery, testing and posture means depth varies, and the automated tests still need tuning to be trustworthy
- Self-hosting means operating a traffic-processing pipeline and datastore, which is a platform commitment rather than a tool install
Best for: Teams who do not know their full API inventory and need discovery and authorization testing from the same tool, with a self-hosting option.
Pricing: Open-source core with no licence cost when self-hosted, plus a managed tier metered on API endpoints monitored and tests run.
StackHawk
StackHawk is dynamic application security testing shaped for the pull request. It runs inside the pipeline against a running instance of the service, driven by an OpenAPI, GraphQL or gRPC definition so that it exercises real routes rather than crawling blindly, and it reports findings with the request that produced them so a developer can reproduce it without security expertise.
Pros
- Designed for pipeline execution from the start, so runtime, configuration and output are shaped for a developer audience rather than a security team’s console
- Spec-driven scanning of REST, GraphQL and gRPC means it exercises routes that a crawler would never discover on its own
- Findings ship with the reproducing request, which removes the argument about whether a report is real and cuts triage time sharply
- Per-application configuration lives in the repository, so scan setup is reviewed and versioned with the service
Cons
- Built on a general DAST engine, so it is strongest on injection and configuration classes and weaker on the authorization logic that dominates API risk
- Requires a running, seeded instance of the service in the pipeline, which is straightforward for a self-contained service and painful for one with many dependencies
- Coverage is bounded by the spec you supply, so an inaccurate spec silently shrinks the scan
- Authenticated scanning configuration remains fiddly, and a misconfigured session produces a scan that quietly tested almost nothing
Best for: Engineering teams that want automated DAST running per-service in CI with findings developers can act on without a security intermediary.
Pricing: Subscription tiered by the number of applications or APIs under scan, with enterprise plans adding governance and integrations.
Burp Suite
Burp is the tool actual penetration testers use, and that is the reason it belongs here even though it is not primarily a CI tool. Its proxy, repeater and intruder components make manual exploration and hypothesis testing fast, its scanner automates the well-understood classes, and its extension ecosystem includes the authorization-testing workflows that automated products approximate. When a finding needs a human to confirm exploitability, this is where that human works.
Pros
- The best environment available for manual authorization testing, where an operator can hold two sessions and compare responses request by request
- Extensions cover exactly the cross-identity replay workflow that automated tools struggle with, driven by someone who knows what the data should be
- The proxy makes any client’s traffic inspectable and modifiable, which is how you test mobile and native clients that no scanner can drive
- Enterprise Edition adds scheduled automated scanning, so the same engine covers both manual assessment and continuous coverage
Cons
- Fundamentally an operator’s tool, so the value scales with the skill of the person using it and not with the licence
- Weak fit for pull request gating; the automated edition is a separate product with different economics and a different workflow
- Interactive, stateful usage does not translate into reproducible pipeline runs without significant scripting
- Licensing separates the professional workstation product from the enterprise scanning product, so covering both needs costs twice
Best for: Security engineers doing manual API assessment and confirming exploitability, especially for authorization flaws that need human judgment.
Pricing: Per-user annual licence for the professional edition, with the enterprise scanning edition sold separately on scan capacity and agents.
ZAP
ZAP is the open-source dynamic scanner that most of this category learned from, with a proxy, an active scanner, passive analysis and an automation framework that runs the whole thing headlessly from a configuration file. It is the tool to reach for when you want continuous scanning and cannot justify a commercial licence, and its passive mode is a safe way to get value from traffic you are already generating in test.
Pros
- No licence cost at any scale, so scanning every service in a large estate is a capacity question rather than a budget negotiation
- The automation framework makes headless, configuration-driven runs reproducible in CI without writing a harness
- Passive scanning of traffic generated by your existing functional tests finds real issues with no active attack traffic and no state pollution
- A large extension ecosystem and long history mean most problems you hit have already been discussed somewhere
Cons
- Authorization and business logic testing are not its strength; it is a general web scanner applied to APIs rather than an API-shaped tool
- Configuration and tuning are substantial, and the default profile against a real API produces noise that will exhaust a team’s patience
- Findings are written for security practitioners, so triage and translation for developers is manual work you absorb
- No vendor to escalate to, which means an unexplained result is yours to investigate with community help
Best for: Teams that want dynamic scanning across many services with no licence cost and have someone willing to own the configuration.
Pricing: Open source with no vendor and no bill. Your only costs are the compute it runs on and the engineering time to tune and triage it.
Nuclei
Nuclei is a template-driven scanner: checks are declarative files describing a request and the conditions that indicate a match, and it executes them at high concurrency across many targets. It is not an authorization tester and does not pretend to be. What it is excellent at is knowing, quickly and across your whole estate, whether any host is exposing a known vulnerable component, an unauthenticated administrative interface, a leaked configuration file, or a misconfiguration with a published signature.
Pros
- Declarative templates make organisation-specific checks trivial to write and review, so an internal finding becomes a permanent fleet-wide check in an afternoon
- Extremely fast across large target lists, which makes continuous estate-wide coverage practical rather than aspirational
- A large community template corpus covers newly published issues quickly, which is the fastest way to answer “are we exposed to this” during a disclosure
- Low false positive rate for what it does, because matches are based on specific response signatures rather than heuristics
Cons
- Signature-based by design, so it finds known patterns and is structurally incapable of finding authorization flaws specific to your business logic
- No understanding of application state or sessions, which limits it severely against authenticated API surface
- Template quality across the community corpus is uneven, so running everything unfiltered produces noise
- It complements rather than replaces a DAST tool, so it is an addition to your stack and not a consolidation of it
Best for: Rapidly checking a large estate for known vulnerable components, exposed interfaces and misconfigurations, and for codifying internal findings as repeatable checks.
Pricing: Open source with no licence cost and no bill for the scanner and template corpus; the maintainers sell a separate hosted platform priced independently if you want it.
How to choose
Three questions, in order.
Do you know every endpoint you expose? If not, start with discovery, not scanning. A spec-driven tool scanning an inaccurate spec will report a clean result on an incomplete surface, which is worse than no result because it produces confidence. Traffic-based discovery, or an inventory derived from your gateway, comes first.
Is your spec true? If your OpenAPI document is generated from code and checked in CI, spec-driven tools (42Crunch, StackHawk) are efficient and cheap to run. If it is hand-maintained and drifting, they will scan a fiction. The related discipline is covered in the OpenAPI tooling guide, and fixing it is a prerequisite rather than a parallel task.
Is authorization your actual risk? For almost every multi-tenant API, yes. That means the deciding capability is multi-identity testing with response comparison, which points at Akto or Escape for automation, and at Burp for the human confirmation step. A general scanner will not get you there no matter how it is configured.
The realistic end state for most teams is three layers rather than one product: a fast spec audit on every pull request, a scheduled authenticated scan with cross-identity authorization testing against a resettable environment, and a periodic manual assessment by someone who can reason about your business logic. Automated tools narrow the search space. They do not replace the human for this flaw class, and any vendor telling you otherwise is selling.
| Tool | Approach | Cross-identity authz | CI fit | Picks itself when |
|---|---|---|---|---|
| OWASP API Top 10 | (standard, not a product) | n/a | n/a | You need shared vocabulary, not an assessment |
| 42Crunch | Spec audit, conformance, runtime | Weak | Excellent for the audit tier | OpenAPI is genuinely your source of truth |
| Escape | Model-driven business logic testing | Strong | Good | GraphQL or complex authorization dominates |
| Akto | Traffic discovery plus generated tests | Strong | Good | You do not know your full inventory |
| StackHawk | Spec-driven DAST in pipeline | Weak | Excellent | You want per-service DAST developers will act on |
| Burp Suite | Operator-driven assessment | Strongest, manual | Poor | A human must confirm exploitability |
| ZAP | Open-source DAST | Weak | Good with effort | Licence cost is the binding constraint |
| Nuclei | Template signature matching | None | Excellent | Estate-wide checks for known exposures |
Frequently asked questions
Why do scanners miss broken object level authorization?
Because detecting it requires knowing that a returned object belongs to a different principal, and a scanner running with one set of credentials has no way to know that. A successful exploitation looks identical to correct behaviour: a 200 with valid JSON. Only a tool configured with at least two identities, which replays one identity’s requests as the other and compares responses, has the information needed to call it a finding.
Are random UUIDs enough to prevent object level authorization flaws?
No. Unpredictable identifiers raise the cost of enumeration and change nothing about entitlement. Identifiers leak through share links, exported reports, support tickets, referrer headers, browser history, and simply from a user who used to have access and no longer should. The only fix is a server-side check that derives the tenant or owner from the authenticated session and applies it at the data access layer.
Can I run a security scanner against production?
Passive analysis of mirrored traffic and static spec auditing are safe against production and worth doing. Active scanning is not, unless you have explicitly planned for it with a scoped account, rate limits, and the on-call team informed, because active scans create and mutate data with fuzzed values. The usual arrangement is active scanning against a resettable pre-production environment and passive coverage in production.
How do I stop security scanning from blocking every pull request?
Tier it. Spec lint and static audit on every pull request because they are fast and deterministic. Targeted authorization replay on pull requests that touch routes. Full active scans on a schedule against a dedicated environment. Then baseline the existing findings and fail builds only on new ones, because a gate that fails on pre-existing debt gets bypassed immediately and never comes back.
Does an API gateway or WAF protect against these flaws?
Against some, not the important one. A gateway enforces authentication, rate limits, schema validation and can reject requests that do not match a declared contract, all of which is worthwhile and covered in the API gateway guide. It cannot determine whether this authenticated caller is entitled to this particular object, because that requires knowledge of your data model. Authorization is an application concern and a gateway will never fix it.
Related reading
- Best API management platforms — where the endpoint inventory and policy enforcement your scanners depend on actually lives.
- Best authorization services — centralising the entitlement checks whose absence these tools are hunting for.
- Best API authentication tools — the layer below authorization, and the one scanners find easier to test.
- Best OpenAPI and Swagger tooling — an accurate spec is the prerequisite for every spec-driven scanner here.
- Best API testing tools — the functional suites whose recorded traffic makes cross-identity replay possible.
- Best API monitoring tools — detecting the undocumented endpoints that security scanning never sees.