API security strategy is lagging behind discovery and response needs

At a glance

What this is: This is an API security strategy analysis showing that recognition is high but discovery, governance, and response capability are lagging badly.

Why it matters: It matters because IAM, application security, and cloud teams cannot govern API access, abuse, or business-logic risk without an accurate inventory and response model.

By the numbers:

• 73% of CISOs consider API security a top or critical concern.
• Only 17% of CISOs report having a comprehensive and implemented API security strategy.
• 74% of security leaders are often surprised by the discovery of new, undocumented APIs in their environments.
• Only 16% of security leaders feel they are adequately staffed to triage and respond to API-related security alerts in real time.

Context

APIs now sit in the control path for mobile applications, cloud integrations, and digital business processes, so API security has become an identity and access problem as much as an application security problem. The issue is not whether APIs matter, but whether security teams can inventory them, understand who or what can call them, and react before unmanaged change becomes exposure.

Salt's survey points to a structural mismatch between software delivery speed and security governance speed. When APIs change weekly or daily but discovery and audit cycles lag behind, undocumented endpoints, shadow integrations, and business-logic abuse can sit outside normal review and response processes for weeks at a time.

Key questions

Q: What breaks when API discovery only happens on a monthly or quarterly audit cycle?

A: Unknown APIs can exist long enough for teams to lose control of ownership, data exposure, and access paths. In fast-moving environments, a periodic audit cycle cannot keep up with weekly or daily API changes, so the inventory becomes stale before it is used. That leaves security teams reacting to exposures after they have already been deployed.

Q: Why do legacy API tools miss business logic attacks?

A: Legacy perimeter tools are built to spot known malicious signatures and coarse policy violations, not requests that are technically valid but operationally abusive. Business logic attacks succeed when the caller uses an intended function in an unintended way, so the system must evaluate access intent, object relationships, and transactional behaviour, not only traffic shape.

Q: What are the signs that API governance is failing at runtime?

A: Common signs include undocumented endpoints, duplicated ownership, inconsistent responses, rising retry loops, and frequent discovery of APIs that are not in the catalogue. Those signals show that the live estate and the formal control model no longer match. Once that happens, security and reliability teams are managing assumptions instead of actual behaviour.

Q: Should teams prioritise API discovery or enforcement first?

A: Discovery comes first when shadow endpoints or incomplete inventories exist, because enforcement cannot protect what the team has not identified. Once the exposed surface is known, prioritise the most sensitive and most attacked APIs for schema validation, bot controls, and runtime enforcement.

Technical breakdown

Why API discovery breaks at development speed

API discovery fails when security governance assumes an inventory can be reconciled on a slow audit cadence while engineering changes the interface surface continuously. An API is not just a technical endpoint; it is a contract that defines who can request what, under which conditions, and with which data exposure. If that contract changes weekly or daily, monthly or quarterly review leaves long visibility gaps. In practice, shadow and unmanaged APIs accumulate because teams optimise for release velocity, while security tools often see only known assets or periodic snapshots. That creates blind spots around unknown endpoints, deprecated versions, and untracked data paths.

Practical implication: security teams need API discovery tied to change events, not periodic inventory review.

Why WAFs and gateways miss business logic abuse

Web application firewalls and API gateways are built primarily to block known malicious patterns, enforce coarse routing, and mediate access at the edge. They are not sufficient on their own for business-logic attacks, where the request is syntactically valid but the intended use is abusive, overbroad, or data-bearing in ways the system still accepts. That is why an attacker can exploit legitimate functionality, object relationships, or workflow design without tripping signature-based controls. In API security, the real question is not only whether traffic looks hostile, but whether the caller is exercising a function beyond the business rules the organisation intended.

Practical implication: control selection must include behavioural and authorization testing, not only perimeter inspection.

How alert triage becomes a governance bottleneck

API security monitoring produces value only if teams can convert alerts into decisions fast enough to matter. When only a small fraction of security leaders feel adequately staffed to triage alerts in real time, the operating model itself becomes a control weakness. The problem is not merely volume; it is that every unknown API, policy exception, or abnormal request pattern creates an investigation burden that competes with release work and incident response. Without enough people, standardised playbooks, and clear ownership, security stacks up findings faster than it can reduce risk.

Practical implication: assign clear ownership and prioritise automated enrichment for API findings so triage can scale.

Threat narrative

Attacker objective: The attacker wants to use trusted API functionality to reach data or actions that security controls have not effectively governed.

1. Entry often begins when undocumented or shadow APIs are exposed through normal development changes that security teams have not yet discovered.
2. Escalation follows when legacy edge controls allow legitimate but abusive requests to use business logic in ways the organisation did not intend.
3. Impact occurs when attackers access or exfiltrate sensitive data through API workflows that remain outside effective monitoring and response coverage.

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.
• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

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

API discovery debt is now a governance failure, not a tooling inconvenience. When 74% of leaders are surprised by new undocumented APIs, the organisation no longer has a reliable asset boundary. That means access policy, testing, and incident response are all operating against an incomplete map. The practical conclusion is that API inventory must be treated as a control plane, not a reporting exercise.

Business logic abuse is the real test of API security maturity. Signature-based defenses are designed for hostile payloads, but many API attacks stay within valid syntax and exploit intended functionality. That makes authorization quality, workflow constraints, and behavioural detection more important than perimeter filtering alone. The governance lesson is that APIs need policy enforcement at the transaction level, not just at the network edge.

Identity governance now extends to machine-to-machine access paths. Every unmanaged API is also an unmanaged access path, which means API security and IAM are converging operationally. Security teams need to know not only which APIs exist, but which services, applications, and partners can call them, and whether those permissions still match business need. The practitioner takeaway is that API governance must be aligned with entitlement review and access ownership.

Alert volume without response capacity produces security theatre. If only 16% of leaders feel staffed to triage API alerts in real time, the organisation is absorbing findings faster than it can turn them into action. That creates a false sense of control because coverage metrics improve while actual remediation lags. The field implication is that API programs must be measured by response throughput and inventory completeness, not by tool count.

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.
• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

API governance now lives or dies on inventory freshness. When change happens weekly or daily but review happens monthly or quarterly, discovery debt becomes an operational exposure window rather than a reporting problem. Security leaders should expect the API estate to drift faster than manual control processes can track it.

Shadow APIs expose a broader identity and access gap. Every undocumented API is a machine-to-machine access path that may not be reflected in entitlement review, ownership records, or incident response runbooks. That creates a control gap between what applications can call and what security teams believe is exposed.

Business logic abuse changes the control conversation from filtering to governance. The relevant question is no longer whether the edge blocks hostile payloads, but whether the organisation can prevent valid requests from being used in abusive ways. That pushes API programmes toward transaction-level policy and measurable response capacity.

For practitioners

• Build continuous API discovery into change workflows Trigger discovery when applications, integrations, or versions change so shadow and unmanaged APIs are identified as part of release governance, not after the fact.
• Map every API to an accountable owner Require each API to have a business owner, technical owner, and access decision record so unknown endpoints cannot persist without clear responsibility.
• Test for business-logic abuse paths Add authorization and workflow abuse tests that verify whether valid requests can still reach data, functions, or objects outside intended use.
• Separate discovery from triage metrics Track inventory completeness, alert closure time, and the percentage of APIs under active review so teams can see whether response capacity matches exposure.

Key takeaways

• API security programmes are failing less because teams ignore the risk and more because discovery, ownership, and response cannot keep pace with API change.
• The survey shows a severe gap between priority and practice, with undocumented APIs and understaffed triage creating long exposure windows.
• A workable API strategy has to combine continuous discovery, behavioural detection, and accountable ownership rather than relying on legacy edge tools.

Key terms

• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Business Logic Abuse: Business logic abuse occurs when an attacker uses a valid API in a way the application designer did not intend, such as exceeding limits, chaining actions, or misusing workflow assumptions. The API is functioning technically, but governance and policy are failing at the intent layer.
• API Discovery: API discovery is the process of finding and cataloging APIs across an environment so security teams know what exists, what data it exposes, and how it behaves. It is essential because shadow, zombie, unmanaged, and third party APIs are frequent blind spots that attackers can exploit without being noticed.
• Runtime API Protection: Runtime API protection is the practice of securing application programming interfaces while they are actively handling live traffic. It combines authentication, authorization, schema validation, rate controls, anomaly detection, and abuse prevention to reduce misuse, data exposure, and unauthorized actions across internal, external, and machine-to-machine API interactions.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the access paths that APIs and service accounts create across modern environments.