Security

Why 34% of API Breaches Bypass Traditional Security Tools | StackHawk

0

Guest: Scott Gerlach
Company: StackHawk
Show Name: Secure By Design
Topic: Security

Your security scanners catch SQL injection and cross-site scripting. But can they detect when User A can change User B’s password? Business logic vulnerabilities are among the most damaging security gaps in modern applications, accounting for 34% of all API breaches according to recent OWASP data. Yet they remain invisible to traditional SAST and DAST tools because they’re not about buggy code, they’re about how applications behave.

StackHawk has built its reputation as a leading API security platform, but the company is now tackling a security challenge that’s plagued development teams for years: testing business logic at scale. Scott Gerlach, Chief Security Officer and Co-Founder at StackHawk, explains that business logic testing has historically been a manual, brain-intensive process requiring deep knowledge of application context and business rules.

The challenge intensifies in the API-driven world. Traditional examples like applying 59 coupons to force a refund still exist, but modern business logic flaws are more subtle and harder to detect. Authorization issues dominate the landscape. Broken function-level authorization, often abbreviated as BFLA, represents the most common category. These are scenarios where Company C can access Company D’s data, or where users can modify resources they shouldn’t touch.

The AI-Powered Testing Revolution

StackHawk’s expansion into business logic testing leverages artificial intelligence to solve problems that were previously impossible to address at scale. The platform now uses AI to automatically generate OpenAPI specifications from code, eliminating a major barrier for teams without existing documentation. More importantly, the AI analyzes these specifications to understand intended API workflows and business context.

The system can now traverse APIs intelligently, registering accounts, capturing returned data, and using that information in subsequent requests. This allows testing that mirrors real user behavior rather than simple endpoint probing. Gerlach emphasizes that this approach bridges the gap between probabilistic AI analysis and deterministic testing results. The AI understands the application, but the testing delivers concrete, repeatable outcomes: it’s broken or it’s not.

Authorization Testing in Production

The new StackHawk capability focuses initially on multi-user authorization testing. Development teams can now test whether User A can inappropriately access User B’s resources or modify User C’s data. These checks happen before production deployment, integrated directly into CI/CD pipelines and user acceptance testing environments.

This represents a fundamental shift from detect-and-respond security to preventive testing. Rather than waiting for production traffic to expose vulnerabilities, teams catch authorization flaws during the build process. Gerlach notes this becomes increasingly critical as AI-assisted coding tools generate more code with less human oversight.

The AI Code Generation Challenge

The explosion of AI-generated code creates both risks and opportunities. Development teams are 8-10x more productive with AI assistance, but they also have less intimate knowledge of what the code actually does. Early concerns about AI tools producing vulnerable code have largely subsided. Current data shows AI-generated and human-written code contain similar vulnerability rates from a static analysis perspective.

The real issue is volume. More code means more potential attack surface, more alerts to triage, and more uncertainty about what’s actually running in production. Behavioral testing becomes essential. Rather than analyzing every line of AI-generated code, teams can test how the deployed application actually behaves with real data and multiple user contexts.

Integration and Adoption

StackHawk’s business logic testing requires slightly different environments than traditional API security scanning. While developers can run standard StackHawk tests directly in their IDEs during development, business logic testing benefits from more realistic data in user acceptance testing or staging environments. The testing takes longer than quick developer-focused scans but provides deeper insight into authorization models and business rule enforcement.

Teams already using StackHawk for API security can adopt the new capabilities within their existing workflows. The smart crawl functionality that powers business logic testing also enhances the entire StackHawk testing suite, making traditional vulnerability detection more thorough and context-aware.

The Competitive Landscape

StackHawk isn’t alone in pursuing business logic testing. Companies like Semgrep have announced similar capabilities, reflecting industry-wide recognition that behavioral security testing must complement traditional vulnerability scanning. Gerlach argues StackHawk’s differentiator lies in pre-production testing philosophy. While some competitors focus on analyzing production traffic to detect attacks in progress, StackHawk emphasizes catching problems before deployment.

This approach gives security and development teams confidence rather than scramble mode. Instead of discovering authorization flaws through production incidents and then hunting through code to identify the problem and responsible team, organizations can test and fix before users are exposed.

Looking Forward

As applications become increasingly API-driven and development teams lean more heavily on AI assistance, business logic testing will only grow in importance. The combination of more code, less intimate developer knowledge of that code, and faster deployment cycles demands automated, intelligent testing that goes beyond pattern matching for known vulnerability types.

StackHawk’s expansion into this space reflects a broader industry evolution. Security testing must adapt to how modern applications actually fail. Sometimes the most dangerous vulnerabilities aren’t in the code at all, they’re in how that code behaves when real users start clicking buttons and making API calls.

How Akamai & Fermyon Are Making Security Effortless for Edge Developers

Previous article

Mirantis Introduces AdaptiveOps Services to Help Enterprises Operationalize Model Context Protocol

Next article