The Risk Isn’t in the Endpoint—It’s in the Interaction

Most API Vulnerabilities Don’t Live in a Single Request

You can test every endpoint in your application.

And still miss the biggest risks.

That’s because modern vulnerabilities—especially in APIs—don’t always come from insecure code or broken endpoints.

They come from how those endpoints interact.

The real threat isn’t just “is this endpoint vulnerable?”
It’s “what happens when these three endpoints interact with different roles and timing?”

This is the fundamental shift that most security teams haven’t made yet. They’re still thinking about API security like it’s 2015—test each endpoint, check for SQL injection, call it good.

But modern applications are built as interconnected systems where the real business logic happens across API boundaries. A user creation API might be secure in isolation, but what happens when it’s called immediately after a user deletion? What if the deletion API doesn’t properly clean up permissions, and the creation API inherits those leftover privileges?

These interaction-based vulnerabilities are where the sophisticated attacks happen. And they’re completely invisible to scanners that test one endpoint at a time.

---

What We Hear from Teams

“We scanned every endpoint we knew about… and still missed the actual exploit.”

A fintech company told us they had comprehensive API coverage—every endpoint documented, every service mapped, every scan passing. Then a penetration tester discovered they could manipulate account balances by exploiting the timing between their transaction processing API and their balance update API. The individual endpoints were secure, but the race condition between them created a window for exploitation.

“The vulnerability wasn’t in the POST or the GET—it was in how they worked together.”

An e-commerce platform shared a similar story: Their product pricing API was secure, their discount API was secure, and their checkout API was secure. But by calling them in a specific sequence with carefully crafted timing, attackers could stack discounts that should have been mutually exclusive, getting products for free.

“One team built the object creation. Another built the approval. Nobody noticed what happened when we chained them.”

This is the microservices reality. A healthcare platform had separate teams building patient record creation APIs and medical record approval APIs. Each worked perfectly in isolation. But when chained together, the approval API would approve any record ID that existed—even records from different patients. The vulnerability existed in the interaction between services, not in either service individually.

The Real-World BOLA Discovery:

One security team told us they found a Broken Object-Level Authorization (BOLA) issue only after simulating a workflow where an attacker re-used an object ID from one user to another—something no scanner flagged when endpoints were tested in isolation.

Here’s what happened: Their application had separate APIs for creating documents and sharing documents. The creation API properly validated user ownership. The sharing API properly validated permissions. But the sharing API never re-validated ownership when sharing existing documents. An attacker could:

1. Create a document (legitimate)
2. Note the document ID
3. Use that ID pattern to guess other users’ document IDs
4. Share other users’ documents without owning them

The sharing API wasn’t broken—it was working exactly as designed. But the design assumption that “users can only share documents they own” was never enforced across the interaction.

The Timing-Based Discovery:

Another team discovered an internal refund API could be triggered after an account was deleted—because their scanner didn’t simulate that sequence.

The refund API checked that the requesting user had permission to issue refunds. The account deletion API properly removed user access. But there was a 30-second window between marking an account for deletion and actually removing permissions. During that window, a malicious user could trigger refunds for transactions they were no longer supposed to access.

The Resource Exhaustion Pattern:

And the pattern we hear again and again: “We’re spending so much time just trying to figure out what APIs we have, and get those under test… we don’t have time to actually do the interesting attacker-based security work.”

Security teams are stuck firefighting:

• Building inventory: Discovering shadow APIs, tracking API changes, maintaining documentation
• Wrangling broken scans: Fixing authentication failures, managing false positives, troubleshooting scanner failures
• Wrestling token auth into legacy tools: Configuring OAuth flows, managing token refresh, debugging authentication workflows

The result? They’re forced to test what’s easy to reach—not what’s most risky.

That’s why deeper issues—like logic flaws, authorization failures, or exploit chains—don’t get touched until it’s too late. Security teams spend 80% of their time on tooling problems and 20% on actual security analysis.

Here’s what changes when you solve the foundation problems: When you have complete API discovery from source code, reliable authentication that doesn’t break, and comprehensive endpoint testing that runs automatically—then your security team can focus on the real work: designing attack scenarios, modeling business logic flaws, and testing the interaction patterns that matter most to your application.

And here’s the game-changer: Once you identify a business logic vulnerability or interaction flaw, you can codify that test scenario to run automatically in every CI/CD pipeline. That refund-after-deletion vulnerability? Build a custom test that checks for it continuously. That cross-tenant data access pattern? Create a repeatable test that validates tenant isolation across all your APIs.

This transforms one-time security discoveries into permanent security coverage.

---

Vulnerabilities That Only Show Up Across Interactions

Here are the kinds of risks that often get missed when tools test APIs one endpoint at a time:

Vulnerability Type	Why Interaction Matters	Real-World Example
BOLA (Broken Object-Level Authorization)	Object ID reuse between users across workflows	User A creates document with ID 123, User B can access document 124 by manipulating the sharing API call sequence
BFLA (Broken Function-Level Authorization)	Role-based access assumed—but not enforced in cross-service logic	Standard user can trigger admin functions by calling user creation API followed by permission assignment API
Business Logic Flaws	Unintended behaviors from edge cases, e.g., refund → delete → reauth	Refund API can be triggered after account deletion during permission cleanup window
Replay Attacks	Session tokens reused outside the intended context	Authentication token from mobile app can be replayed against web API with elevated permissions
Privilege Escalation	Permissions shift over time or through chained requests	User role changes during multi-step workflow, gaining access to resources they shouldn’t see
Race Conditions	Timing-dependent vulnerabilities in concurrent operations	Balance update API and transaction API create window for double-spending
State Manipulation	Application state assumptions violated through request ordering	Password reset API bypassed by manipulating user status through profile update API

Why Legacy Tools Miss This

Legacy DAST tools and black-box API scanners focus on endpoint behavior, not workflow behavior.

They:

• Test individual requests out of context
• Don’t simulate role changes, replays, or object flows
• Lack understanding of application logic across microservices or domains
• Rarely model attacker behavior beyond the login page
• Are unable to relate these scenarios to custom tests
  

Result: the scanner says “you’re secure,”
but your business logic says “here’s the breach.”

The Architectural Problem:

Legacy DAST tools were built for monolithic web applications where business logic lived in a single codebase. Modern applications distribute that logic across microservices, serverless functions, and third-party integrations.

Consider a typical SaaS application architecture:

• User authentication service
• Permission management service
• Data processing service
• Notification service
• Billing service
• Audit logging service

Each service has its own APIs, its own authentication requirements, and its own business logic. But the real application behavior emerges from how these services interact. Scanners can’t model these cross-service relationships.

The Context Problem:

When a scanner tests the billing API, it might verify that authenticated users can view their invoices. But it can’t test whether:

• Users can view invoices after their account is suspended
• Users can modify invoices during the payment processing window
• Users can access invoices from other tenants by manipulating API calls during user role changes

These scenarios require understanding the application’s state transitions and business logic—context that single-endpoint testing can’t provide.

The Timing Problem:

Many vulnerabilities only appear under specific timing conditions:

• Race conditions: Two APIs updating the same resource simultaneously
• State transitions: APIs called during user role changes or account status updates
• Token lifecycle: APIs called during authentication token refresh or expiration
• Async processing: APIs called while background jobs are running

All make sequential API calls with predictable timing. They can’t simulate the concurrent, asynchronous reality of modern applications.

The Scope Problem:

Modern applications often have APIs with different scopes and permissions:

• Public APIs for mobile apps
• Internal APIs for web frontends
• Service-to-service APIs for microservice communication
• Partner APIs for third-party integrations
• Admin APIs for system management

A vulnerability might exist when tokens from one scope are used against APIs from another scope. But legacy scanners typically test each API in isolation with the “correct” authentication—they don’t test cross-scope token usage.

---

What Scenario-Based API Testing Looks Like

Modern API security testing isn’t just about coverage—it’s about contextual testing that fits your unique environment.

Because here’s the reality: Every company is different. Every API is different. And every attack scenario is different.

The Customization Imperative:

The business logic behind your APIs—how they authorize users, how they process state, how they interact across services—is unique to your application. Cookie-cutter security testing misses the nuances that create real vulnerabilities.

Consider these different business logic patterns:

• Healthcare: Patient data access controls, provider authentication hierarchies, insurance validation workflows
• Financial Services: Transaction limits, account verification sequences, regulatory compliance checks
• SaaS Platforms: Tenant isolation, subscription tier enforcement, feature flag management
• E-commerce: Inventory management, pricing logic, payment processing flows

Each of these domains has unique interaction patterns that create unique vulnerabilities. Generic scanners can’t understand these business-specific risks.

The Scenario Design Process:

Effective scenario-based testing starts with understanding your application’s critical workflows:

1. Map Business-Critical Interactions:

• User lifecycle (creation, activation, suspension, deletion)
• Data access patterns (read, write, share, delete)
• Permission changes (role assignments, access grants, revocations)
• State transitions (pending, approved, rejected, expired)

2. Identify Vulnerable Interaction Points:

• Where do APIs make assumptions about previous API calls?
• Where do different services handle the same data differently?
• Where do timing dependencies create windows of vulnerability?
• Where do role changes affect ongoing operations?

3. Design Attack Scenarios:

• What happens if we reverse the expected order of operations?
• What happens if we skip steps in multi-step workflows?
• What happens if we manipulate data between dependent API calls?
• What happens if we exploit timing windows in async operations?

4. Codify and Automate Discovered Vulnerabilities:

• Turn manual security discoveries into automated, repeatable tests
• Ensure business logic vulnerabilities stay fixed across code changes
• Build custom test scenarios that run in CI/CD pipelines
• Create organization-specific security knowledge that persists beyond individual team members

The Tooling Requirements:

To implement scenario-based testing effectively, security teams need:

Discovery That Leads to Action: Complete visibility into every API (including the ones no one told you about), discovered automatically from source code repositories. This gives you the foundation to understand what needs testing before you design interaction scenarios.

Reliable Endpoint Testing: Comprehensive testing of individual API endpoints with authentication that actually works. This eliminates the false positives and authentication failures that consume security team time, creating space for deeper analysis.

Workflow Design on Solid Foundation: Time and tools to design meaningful test scenarios because you’re not stuck fixing basic scanning problems. This requires platforms that let security teams and developers collaborate on defining realistic attack scenarios based on actual application logic.

Custom Test Development: The ability to build and automate custom test scenarios without relying on brittle, one-off hacks. Test scenarios need to be maintainable and reliable enough to run in CI/CD pipelines. More importantly, once you discover a business logic vulnerability, you need to codify that discovery into a repeatable test that ensures the vulnerability stays fixed and doesn’t reappear in future code changes.

The Time Investment Problem:

When teams spend all their time just figuring out what exists and getting basic endpoint testing working, they never get the chance to go deeper. To actually model how attacks happen.

But here’s the opportunity: With comprehensive API discovery, reliable authentication, and automated endpoint testing as your foundation, you can move from “checkbox scanning” to real, proactive risk analysis.

That’s where the real security value emerges—designing custom scenarios that test your specific business logic, understanding your unique attack surface, and modeling the interaction patterns that are most valuable to attackers targeting your application.

📘 See how to build workflows in StackHawk 🛠️ Passing data across API calls

The Business Logic Vulnerability Gap

Here’s what makes interaction-based vulnerabilities especially dangerous: They’re invisible to traditional security measures.

Code Review Blind Spots: Individual API endpoints might pass code review with flying colors. The authentication logic is correct, input validation is proper, and database queries are parameterized. But code review typically focuses on single functions or services—not cross-service interactions.

Penetration Testing Limitations: Even skilled penetration testers struggle with interaction-based vulnerabilities because they require deep understanding of business logic and application workflows. A pen tester might find individual API vulnerabilities, but miss the subtle logic flaws that emerge from specific interaction sequences.

Compliance Gap: Security frameworks like SOC 2 and ISO 27001 focus on process controls and individual system security. They don’t typically address cross-system interaction risks or business logic vulnerabilities that span multiple services.

The Developer Knowledge Problem: In large organizations, no single developer understands all the interaction patterns across all services. The team that built the authentication service might not understand how the billing service uses authentication tokens. The team that built the permission system might not know how the data export service validates permissions.

This knowledge fragmentation creates interaction vulnerabilities that no individual team would ever create intentionally.

The Microservices Multiplication Effect: Each new microservice adds exponential complexity to interaction testing. With 5 services, you have 10 potential service interactions. With 10 services, you have 45 interactions. With 20 services, you have 190 interactions.

Traditional security tools can’t scale to test all these interactions. But attackers can focus on the most valuable interaction paths—the ones that lead to data access, privilege escalation, or business logic bypasses.

Real World: API Coverage ≠ Security Coverage

A customer once shared: “We had 100% coverage. The scanner hit every endpoint. But the real exploit didn’t show up until we tested what a user could do after they got deleted.”

Here’s the full story: This SaaS company had comprehensive API security testing. Every endpoint was documented, every service had authentication, every API call was logged. Their security dashboard showed green across the board.

But their actual vulnerability was in the user deletion workflow:

1. User requests account deletion
2. User data is marked for deletion (but not immediately removed)
3. Background job processes deletion over 24-48 hours
4. During that window, some APIs still recognized the user as valid
5. Other APIs had already revoked access

The exploit: A malicious user could request deletion, then immediately use APIs that hadn’t yet processed the deletion to access data they should no longer be able to see. Even worse, they could manipulate their user profile during deletion to change their role or permissions—changes that would persist even after the deletion was complete.

The coverage wasn’t the problem. The test scenario was.

Their scanner had tested:

• ✅ User authentication (working)
• ✅ User data access (properly authorized)
• ✅ User deletion (successfully processed)
• ✅ Post-deletion access (properly blocked)

But it never tested the transition states between these operations. It never modeled the real-world timing of async operations. It never considered what happens when a user is “partially deleted.”

The Resolution:

Once they implemented scenario-based testing, they discovered similar timing vulnerabilities in:

• User role changes (brief window of elevated privileges)
• Subscription downgrades (temporary access to premium features)
• Password resets (token validity during email delivery delays)
• Data exports (access to deleted data during processing)

These weren’t coding errors—they were architectural assumptions that broke down under adversarial conditions.

The Custom Test Solution: Here’s where it gets powerful: Once they identified these timing-based vulnerability patterns, they built custom tests for each scenario. Now every code deployment automatically tests for:

• User deletion timing windows
• Role change privilege escalation paths
• Subscription downgrade access gaps
• Token validity during async operations

What started as manual security discoveries became permanent, automated security coverage. When developers make changes to user management or subscription logic, the tests immediately flag if they’ve reintroduced timing vulnerabilities.

---

The Bottom Line

If your scanner only tests endpoints in isolation, it’s missing the real threats.

• Business logic is where security assumptions break.
• Roles and tokens shift across time and sequence.
• The app behaves differently depending on what just happened.

You don’t need to brute-force every flow.
You need to test the right interactions—the ones attackers exploit.

---

✅ Want to see how StackHawk helps teams test real-world API behavior, not just endpoints?→ Get a Demo