Business logic testing still needs human context, not just scanners

At a glance

What this is: StackHawk argues that traditional scanners miss business logic flaws because they cannot understand the workflow rules and intent behind otherwise functioning APIs.

Why it matters: IAM and API security teams need to test authorisation, sequence, and business-rule enforcement as part of access governance, not treat scanner output as proof that workflows are safe.

By the numbers:

• APIs now handle 71% of all web traffic, putting the most critical business logic behind machine-readable interfaces that scanners still struggle to interpret.

Context

Business logic testing looks for flaws in how an application is supposed to behave, not just whether code has a classic technical vulnerability. In API-heavy environments, the security question is often whether the system enforces the intended workflow, authorisation, and sequence controls when requests are valid on the surface but wrong in context.

That gap matters for identity and access governance because APIs increasingly decide who can do what, to which object, and in what order. When scanners cannot understand those conditions, teams can mistake functional behaviour for safe behaviour, especially in workflows that move money, personal data, or account privileges.

Key questions

Q: What breaks when business logic is not tested in APIs?

A: The main failure is that the API can behave correctly at a technical level while still producing unauthorised business outcomes. Requests may pass syntax checks, but the workflow can still leak data, skip approval steps, or allow users to act on objects and functions they should not control. That is why business logic testing must validate outcomes, not just endpoint responses.

Q: Why do business-logic flaws create more risk than simple scanner findings?

A: Because they often sit inside valid application behaviour, not obvious misconfigurations. An attacker can use normal login flow, then move through allowed states until the application exposes data or actions outside the intended role. That makes business-logic flaws harder to spot, more likely to survive release, and more damaging when they are discovered by an adversary first.

Q: How do security teams know if API authorisation is actually working?

A: They should test whether each identity can only complete the specific actions it is supposed to perform, then compare that result with runtime logs and anomaly patterns. If valid credentials can still retrieve excessive data, call restricted methods, or chain privileged actions, the policy is not holding.

Q: Should organisations use automated scanners or manual testing for business logic flaws?

A: They should use both, but for different purposes. Automated scanners provide broad coverage of technical issues and repeatable regression checks, while human analysis is still needed to understand workflow intent, edge cases, and abuse paths that depend on business context. The right model is hybrid: automation for scale, human review for meaning.

Technical breakdown

Why scanners miss business logic flaws in APIs

Traditional DAST scanners are built to detect known classes of technical defects such as injection or cross-site scripting. They can probe inputs and spot predictable weaknesses, but they do not understand application intent, business sequencing, or whether a valid request is actually allowed in context. That is why a workflow can be technically functional and still be insecure. Business logic flaws often live in the gap between what the API permits and what the business rules should permit. The problem becomes harder when the same endpoint behaves differently depending on role, object ownership, transaction state, or prior steps in the workflow.

Practical implication: Treat scanner results as a baseline and add tests that verify workflow rules, not just payload handling.

How broken object level authorisation turns valid API calls into data exposure

Broken object level authorisation, or BOLA, happens when an API lets a user request an object they should not be allowed to access. The request may be syntactically correct and the endpoint may function exactly as designed, yet the authorisation decision is wrong. This is common when object identifiers are predictable, when tenant boundaries are weak, or when the API assumes the caller is entitled to any object they can name. BOLA is especially dangerous because it often looks like ordinary application traffic until you compare the requester’s identity with the object’s ownership and access policy.

Practical implication: Validate object ownership and tenant boundaries on every request, not only at login or session creation.

Why workflow abuse and broken function level authorisation are hard to automate

Business logic attacks often rely on abusing allowed functions in the wrong order, at the wrong speed, or under the wrong account context. Broken function level authorisation appears when a user can reach administrative or privileged actions without the correct role checks. Workflow abuse goes further by exploiting missing rate limits, missing state validation, or missing sequence controls, for example by repeating discounts, skipping payment verification, or triggering actions before prerequisites are complete. Automated tools struggle because they can see the endpoint but not the business meaning of each step, which makes state-aware testing essential.

Practical implication: Test privileged functions and multi-step flows with role, state, and rate-limit assertions built into the test design.

Threat narrative

Attacker objective: The attacker wants to abuse valid API behaviour to access, modify, or trigger actions on data and workflows they should not control.

1. Entry begins with a legitimate API request or predictable parameter that the application accepts as valid.
2. Credential or identity checks are bypassed because the workflow trusts the request context more than the caller’s actual entitlement.
3. Escalation occurs when the attacker reuses the same pattern at scale across objects or business flows, enabling unauthorised reads, changes, or transactions.
4. Impact is data exposure, account abuse, or financial manipulation through a functioning API that enforces the wrong business rule.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Business logic testing is an identity and access problem disguised as application testing. APIs increasingly sit on the decision path for object access, role enforcement, and transaction approval. When security teams focus only on technical defects, they miss the governance question of whether the right identity can perform the right action in the right state. The practical conclusion is that API testing and access governance now overlap.

Scanner coverage without business context creates a false sense of control. A tool can confirm that an endpoint responds, that validation exists, or that traffic is parseable, while still missing the fact that the workflow is allowing unauthorised outcomes. This is not a tooling failure alone. It is a control-design failure where the security objective is measured at the wrong layer. Practitioners should treat business rules as security requirements, not implementation details.

Broken object level authorisation is the clearest named concept in this problem space. The article’s examples show that when object identity and request identity are not bound tightly enough, the API will happily serve the wrong tenant, record, or account. That creates a repeatable governance gap across digital services, especially where access is mediated by APIs rather than direct human interaction. Teams should prioritise per-object authorisation checks as a core control boundary.

Business logic flaws are most dangerous when workflow state is invisible to the test strategy. Multi-step processes, pricing rules, and privilege-dependent functions all depend on state, sequence, and context. If testing does not model those conditions, the organisation is effectively validating functionality while leaving abuse paths open. The practitioner takeaway is to move from static endpoint testing to stateful workflow validation.

AI-assisted testing may help with pattern discovery, but it does not replace human intent modelling. The article’s core argument is that the hardest cases depend on understanding what the business means, not just what the API returns. That means security programmes should use automation to scale coverage, but retain human review for workflow semantics, edge cases, and privileged paths. Human context remains the deciding factor.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Read next: API Key Management Guide

What this signals

Business logic flaws are easiest to miss where APIs carry both identity decisions and transaction logic. That makes API security and IAM adjacent disciplines rather than separate queues. Teams that treat authorisation as a one-time login check will keep missing the request-time decisions that determine whether an object, workflow, or entitlement is actually safe to use.

Workflow context is the real control boundary. A scanner can verify endpoint behaviour, but it cannot reliably prove that a request is valid for the caller, the object, and the current state of the transaction. That is why business rules need to be encoded as security tests, not left as undocumented application knowledge.

APIs now handle 71% of all web traffic, according to the 2024 State of Secrets Management Survey. As more business logic shifts behind APIs, the test strategy has to move closer to the workflow itself, especially where object ownership and privileged actions are involved.

For practitioners

• Map critical API workflows to business rules Identify the endpoints that move money, expose personal data, change account state, or deliver privileged functions, then document the exact rules that determine whether each action is allowed.
• Add state-aware tests to CI/CD Build tests that validate sequence, role, ownership, and transaction-state requirements so that a request only passes when the full business context is satisfied.
• Write explicit authorisation checks for object access Verify that each request is checked against object ownership, tenant scope, and caller identity before the API returns data or performs a change.

Key takeaways

• Business logic vulnerabilities can leave APIs fully functional while still allowing unauthorised data access, state changes, or workflow abuse.
• The central weakness is that scanners do not understand business intent, so they miss errors in sequence, role checks, and object-level authorisation.
• Security teams need state-aware tests and human review of critical workflows because the control problem is at the business-rule layer, not just the code layer.

Key terms

• Business logic vulnerability: A business logic vulnerability is a flaw in how an application’s workflow or rules are enforced, allowing an attacker to misuse a process rather than break code directly. These issues often evade signature-based tools because the weakness lies in authorisation, sequence, or state handling.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Broken Function Level Authorization: A failure where an API allows a caller to invoke a function reserved for a more privileged role. The problem appears when the API checks whether a user is logged in but not whether they are allowed to perform that action. It is a privilege boundary failure at the application control layer.
• Workflow Abuse: Workflow abuse is the use of legitimate business processes such as onboarding, support, or approval chains to gain access that would be harder to obtain through a direct technical exploit. It succeeds when process trust is stronger than identity verification.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners responsible for access decisions. It gives security and identity teams a shared language for governing the identities that APIs, services, and agents rely on.