APIs are one of the most important technologies in digital business ecosystems. And yet, the responsibility for their security often falls to AppSec teams – and that’s a problem. 

This organizational mismatch creates systemic risk: business teams assume APIs are “secured,” while attackers exploit logic flaws, authorization gaps, and automated attacks in production. As Tim Erlin noted recently, “These are not exploits of a specific vulnerability, but abuse of an API.”  

How API Security Became an AppSec Problem (and Why That Model Broke)

Years ago, APIs were considered the internal “plumbing” for web applications. Security teams relied on a “Castle and Moat” strategy: if the front-end UI was secure and the perimeter (defended by WAFs) was intact, teams assumed the backend was safe. 

As such, AppSec teams focused on catching “malformed” web requests through input validation and vulnerability scanning. This approach worked while APIs were few, static, and internally consumed. 

However, the fundamental nature of software has changed. Modern APIs are inherently exposed and continuously changing through CI/CD pipelines (let’s all remember that stands for continuous integration/continuous deployment). As a result, organizations are left with shadow APIs that bypass traditional governance. What’s more, third parties, mobile apps, and AI agents now consume APIs at an unprecedented scale.

The problem is that AppSec teams can’t govern runtime at this scale. Most modern breaches involve well-formed, legitimate traffic that abuses business logic, an activity that looks normal to traditional security controls. To understand why this breaks the AppSec model entirely, we need to look deeper at how modern API attacks actually work. 

The Modern API Threat Landscape AppSec Was Never Designed to Own

Modern API attacks look like normal usage. Business logic abuse, Broken Object-Level Authorization, credential stuffing and token abuse, low-and-slow data exfiltration; all of these techniques use valid authentication, conform to API schemas, and operate entirely within what the application technically allows. 

That’s why they work, and why AppSec teams can’t stop them. 

The key point to understand is that attackers no longer break APIs; they (ab)use them. They chain legitimate calls in ways developers didn’t anticipate, enumerate object IDs that weren’t meant to be exposed, and siphon data over time to avoid detection. Critically, from the API’s perspective, everything is working as it should. 

As noted, traditional AppSec tooling is vulnerability-centric and pre-production focused. It’s great at finding injection flaws, missing headers, or insecure dependencies before release. It’s terrible at spotting runtime abuse patterns unfolding across thousands or millions of API calls in production. 

The temptation here is to double down on a familiar strategy: shift left. That instinct is understandable, but, used in isolation, it’s also misguided. 

Why “Shift-Left” Alone Is Not a Strategy for API Security

Shift-left is crucial, but it’s only part of the equation. Embedding security earlier in the software development lifecycle improves developer awareness, catches basic authorization mistakes, and minimizes obvious implementation flaws before they reach production. 

However, shift-left makes some dangerous assumptions: 

• Complete API visibility: CI/CD pipelines, microservices, and decentralized teams continuously introduce new and modified APIs. That creates shadow and zombie endpoints that never pass through centralized review. 
• Predictable usage patterns: Mobile apps, partners, automation, and AI agents consume modern APIs. Because behavior changes constantly, expected usage patterns are impossible to define during design. 
• Static, well-defined consumers: Tokens are reused, shared, rotated, and abused; identities are ephemeral; and automation blurs the line between legitimate users and attackers.

As such, over-reliance on pre-production controls creates a false sense of security. Why? Because real abuse unfolds at runtime. We must start treating API security as a continuous control problem, not a development milestone. We must “shift left, shield right.”

API Security Is a Business Risk, Not an AppSec Function

As you have probably gathered, API security failures don’t stay contained at the application layer. They touch every part of the business, impacting: 

• Revenue: Fraud, automated abuse, and large-scale scraping exploit API business logic and monetizable workflows.
• Availability: Automated attacks and abusive traffic exhaust backend services without triggering traditional denial-of-service controls.
• Data protection: APIs enable quiet, low-and-slow access to PII and sensitive business data that often goes undetected.
• Brand trust: When API abuse becomes public, the loss of customer and partner trust is immediate and difficult to recover.

Effective API security requires security leadership to own and prioritize risk, platform and infrastructure teams to enforce controls where APIs actually run, and AppSec and DevOps teams to contribute expertise. Ultimately, we should treat APIs like identity and cloud security: cross-functional, risk-based, and continuously monitored. 

What Security Leaders Must Do Instead

So, how do security leaders achieve that?

Forget more tooling or earlier scans – effective API security relies on changing the operation model. Remember: modern API risk doesn’t originate in development mistakes alone; it emerges from how APIs are used, abused, and automated in production. Addressing that reality requires a fundamentally different approach. 

Shift from Inventory-First to Attack-Aware Security

Visibility must include behavior, not just endpoints. 

Wallarm builds API visibility from live traffic, not specs or static discovery. It learns APIs as attackers and users interact with them, exposing shadow or undocumented endpoints because real attacks hit them first. Ultimately, we treat inventory as an outcome of observed behavior – not the starting point. 

Prioritize Runtime Protection

Detect abuse patterns, not just malformed requests.  

Wallarm protects APIs at runtime – automatically decoding complex, nested payloads, learning normal application behavior, and blocking attacks as they occur. It focuses on how requests behave in context, not whether they merely look legitimate. 

Align API Security with Business Impact

Identify which APIs expose revenue, data, or critical workflows.  

Wallarm identifies which APIs actually power authentication, payments, and data access by observing real production usage. Teams prioritize protection based on business impact, not endpoint volume, so security decisions map directly to the risk the business cares about. What’s more, with Revenue Protection for APIs, you can quantify the impact of attacks on revenue. 

Treat Automation as the Default Attacker

Design defenses assuming bots, scripts, and AI agents – not humans.  

Wallarm assumes attackers automate. It detects malicious bots using behavioral analysis rather than browser challenges or IP reputation, allowing it to stop credential abuse, scraping, and enumeration without breaking legitimate API consumers

Break Ownership Silos

AppSec enables, platform security enforces, and leadership owns risk.  

Wallarm provides a shared runtime control layer. AppSec defines intent, platform teams enforce protection, and leadership sees real, measurable API risk. This eliminates handoffs and closes the gaps that attackers exploit. 

The Road Ahead: APIs, AI, and the Next Expansion of Risk 

APIs now connect AI models, autonomous agents, and machine-to-machine systems. If ownership stays unclear, organizations will repeat today’s API failures across AI systems. Teams that treat API security as a strategic, runtime discipline will secure what comes next – not just what ships today. 

API security maturity isn’t about how early you scan. It’s about how effectively you detect and stop abuse in production.

Protect APIs – and what they enable – with Wallarm Security Edge. 

The post Why API Security Is No Longer an AppSec Problem – And What Security Leaders Must Do Instead appeared first on Wallarm.

*** This is a Security Bloggers Network syndicated blog from Wallarm authored by Annette Reed. Read the original post at: https://lab.wallarm.com/why-api-security-no-longer-appsec-problem-what-security-leaders-must-do/