The Authorization Testing Challenge
Authorization flaws are the #1 and #5 vulnerabilities in the OWASP API Security Top 10, responsible for 34% of security breaches. These are the vulnerabilities attackers actually exploit: accessing other users’ data, escalating privileges, bypassing payment flows.
The problem? These flaws only appear at runtime when testing with multiple users simultaneously. “Can User A access User B’s orders?” “Can a standard user escalate to admin privileges?” You need actual multi-user testing to answer these questions.
Traditional automated security tools fundamentally can’t do this. Single-user DAST tools test with one authenticated session, making cross-user authorization testing architecturally impossible. Static analysis tools flag suspicious code patterns but can’t validate whether authorization actually works at runtime with real user sessions, actual data, and complex permission logic.
Manual penetration testing has remained the go-to solution for business logic testing, but it’s expensive, point-in-time, and can’t keep pace with modern development velocity. When developers ship code multiple times daily (accelerated further by AI code assistants) manual authorization testing becomes a bottleneck that scales poorly. StackHawk’s Business Logic Testing automates this work, enabling authorization validation at development velocity.
What Business Logic Flaws StackHawk Finds
StackHawk has always detected technical vulnerabilities in APIs—SQL injection, XSS, insecure configurations, and single-user authorization issues like IDOR (Insecure Direct Object References). Business Logic Testing goes deeper, finding authorization flaws that only manifest when testing how different users interact with the same resources:
BOLA (Broken Object Level Authorization)
User A creates an order and receives order_id: 12345. BLT tests whether User B can call GET /orders/12345 and access User A’s order details. If the API returns User A’s data instead of 403 Forbidden, that’s a BOLA vulnerability, and it’s responsible for more data breaches than any other API vulnerability class.
BFLA (Broken Function Level Authorization)
A standard user calls DELETE /admin/users/123 or PUT /users/me with {“role”: “admin”}. If the API allows these operations instead of returning 403 Forbidden, that’s BFLA, vertical privilege escalation, where lower-privileged users perform higher-privileged functions.
These authorization vulnerabilities consume significant penetration testing time with systematic work that must be repeated every release cycle—work that can now be automated to run continuously in your development pipeline.
How Business Logic Testing Works
StackHawk’s BLT automates the multi-user authorization testing that previously required manual penetration testing, integrating it directly into your existing runtime application security testing workflow.
This launch includes three major enhancements: context-aware test orchestration via Smart Crawl, multi-user testing capabilities, and updated UI showing complete request/response evidence for authorization findings.
Context-Aware Test Orchestration with Smart Crawl
Smart Crawl is the intelligence layer that makes business logic testing possible. It analyzes your OpenAPI specifications (either user-provided or StackHawk-generated) and creates an execution plan that simulates how users or applications actually call your API. It maps inputs from one API operation to others and clusters related operations into logical execution flows.
Unlike tools that use AI to probabilistically guess at API relationships, Smart Crawl’s approach is transparent and deterministic. You can see exactly what’s being tested, configure the test sequences, and understand precisely why findings were flagged. When authorization tests fail, you know exactly which user, which endpoint, and which business logic caused the issue—no black box to debug.
Smart Crawl is now the foundation of all StackHawk scanning, dramatically reducing custom configuration requirements while improving scan accuracy and completeness. When combined with multi-user testing, it enables comprehensive business logic testing.
Configurable Multi-User and Custom Tests
To get started with BLT, StackHawk customers just need to define 2-3 user profiles (admin, member, guest) with different privilege levels in the stackhawk.yml. BLT executes coordinated tests where higher-privileged users create resources and lower-privileged users attempt unauthorized access. This isn’t simulated—it’s actual multi-user runtime testing that proves exploitability with full request/response evidence.
For complex business logic scenarios—testing whether users can modify subscription tiers without payment validation, or validating that shared document permissions revoke correctly when team members leave—write custom test scripts in JavaScript or Kotlin that stay version-controlled alongside your code.
Complete Evidence for Fast Remediation
When authorization flaws are identified, StackHawk provides detailed vulnerability reports showing exactly which user accessed what resource and how authorization was bypassed. Each finding includes the complete test sequence: which user attempted access, what resource they targeted, and the full request/response for both privileged and unprivileged users.
Remediation guidance integrates directly into your development workflow through Jira tickets, Slack notifications, and pull request comments—delivering findings where developers actually work, while they’re still in context of the code they wrote.
Expanding our Definition of DAST
From day one, StackHawk has always been dedicated to providing the most flexible and fast testing on the market. We firmly believe that is the only way to truly shift left into development pipelines where developers have the context and attention needed to fix critical vulnerabilities.
With Business Logic Testing, we’re encouraging our customers to add layers to their runtime testing strategy so they get the best of both worlds. Quick feedback in CI/CD pipelines catches obvious configuration errors (missing auth checks, exposed admin endpoints, basic IDOR issues) while developers are still in context, and fixes are cheapest.
On top of that, you can now execute thorough business logic testing in test/staging environments where you can safely:
- Test destructive operations (DELETE endpoints, privilege escalation)
- Use realistic user roles with actual permission hierarchies
- Validate against seeded test data for reproducible results
- Run complex multi-step authorization flows
This isn’t a limitation—it’s intelligent architecture. Production-focused tools cannot safely test privilege escalation or destructive operations in live environments, meaning they miss entire classes of authorization vulnerabilities. Staging environments enable the thorough testing that actually finds exploitable flaws.
Get Started
Combined with StackHawk’s API discovery from source code and AI-generated OpenAPI specs, StackHawk’s BLT provides the most comprehensive and programmatic way to test APIs for authorization flaws. We know how many cycles this type of manual testing takes up for internal and external pen testing teams, and we’re excited to lighten the load for our customers.
In the era of AI-driven development, AppSec teams need every advantage they can get to reduce breach risk without adding headcount or budget.
Ready to try it out? Business Logic Testing is available now for all StackHawk customers, scaling authorization testing as part of your existing StackHawk testing suite. Visit our documentation to configure your first multi-user test, or schedule a demo to see BLT in action.
