API security strategy is lagging behind discovery and response needs

At a glance

What this is: This is a survey-based analysis of why API security remains under-governed, with visibility gaps, slow auditing, and legacy controls leaving organisations exposed to shadow APIs and business logic abuse.

Why it matters: It matters to IAM practitioners because APIs increasingly sit on the same trust fabric as application access, secrets, and service identities, so weak API governance can undermine NHI controls, privilege boundaries, and broader access assurance.

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 admit to being 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 the volume of API-related security alerts in real-time.

👉 Read Salt's analysis of the API security strategy gap and shadow API risk

Context

API security is now an access governance problem as much as a software protection problem. When APIs change faster than security teams can inventory, review, and monitor them, organisations accumulate unknown entry points, undocumented data flows, and privilege paths that traditional perimeter tools do not understand.

That creates a clear identity and governance intersection. APIs expose service accounts, tokens, keys, and delegated permissions, so weak discovery and weak runtime oversight can turn application drift into a broader credential and access control issue across both human and non-human identity programmes.

Key questions

Q: What breaks when API discovery is missing from the security programme?

A: Security teams lose the ability to prove coverage. They may monitor known endpoints well, but undiscovered services still carry live access paths, stale credentials, and undocumented business logic. In practice, that means access reviews, policy enforcement, and incident triage all start from an incomplete asset list.

Q: What problem does ownership attribution solve for service accounts and API keys?

A: It closes the gap between exposure detection and accountable remediation. Many organisations can find the secret, but not the human who introduced it, maintains it, or can safely replace it. Ownership attribution gives security teams a practical way to assign action without relying on informal knowledge that disappears during staff changes.

Q: How can security teams tell whether API risk controls are actually working?

A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

Q: Which frameworks help teams align API discovery with security governance?

A: NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 are useful starting points because they connect asset visibility, access control, and continuous monitoring. For API-heavy estates, map discovery outputs to those controls so inventory, authentication, and testing are managed as one process.

Technical breakdown

Why shadow APIs create a governance gap

Shadow APIs are interfaces that exist in production but are not fully documented, owned, or monitored. They often emerge through fast release cycles, environment sprawl, or forgotten internal endpoints. The security problem is not just exposure, but governance failure: if teams cannot see an API, they cannot classify its data exposure, map its identity dependencies, or apply policy consistently. That leaves blind spots in authentication, authorisation, and change control, especially where service tokens and delegated access are involved.

Practical implication: build continuous API discovery into change and access governance so undocumented endpoints are identified before they become standing risk.

Why WAFs and gateways miss business logic abuse

Web Application Firewalls and API gateways are useful control points, but they are not designed to understand whether an allowed request is abusing legitimate business logic. Business logic attacks use valid syntax, valid sessions, or valid permissions to trigger unintended outcomes such as data overreach, workflow manipulation, or authorisation bypass. The control gap is semantic, not syntactic. That is why traditional signature-based tools can appear effective while still missing object-level access flaws and unexpected request chaining across APIs.

Practical implication: pair perimeter controls with context-aware detection that can evaluate request intent, not just request format.

How update speed outpaces security review in API environments

When APIs change weekly or daily, monthly or quarterly auditing creates a long exposure window. During that period, new routes, methods, schemas, and permissions can accumulate without review, and risk controls become stale relative to the service state. This is where governance breaks down in practice: the security team is working from an outdated map while developers are operating on the current one. The result is a control lag that favours attackers probing for undocumented or newly exposed functions.

Practical implication: align API review cadence to release cadence, or treat every unreviewed change as an active control gap.

Threat narrative

Attacker objective: The attacker objective is to exploit trusted API functionality to access data or trigger actions that should have remained out of scope.

1. Entry begins when attackers find undocumented or poorly monitored APIs that are not covered by normal inventory and review processes.
2. Escalation follows when valid API functions are abused with legitimate credentials or sessions to reach data and workflows beyond intended scope.
3. Impact occurs through data exposure, sensitive workflow manipulation, or exfiltration that looks like normal traffic until the loss is already underway.

NHI Mgmt Group analysis

API security is becoming an identity governance problem, not only an application security problem. APIs carry service identities, tokens, delegated permissions, and access paths that often outlive the change records that created them. When teams cannot reconcile API inventories with credential ownership and authorisation scope, the real control gap sits in access governance. Practitioners should treat undocumented APIs as unmanaged identities with data reach.

Shadow API discovery is the new prerequisite for effective least privilege. Least privilege cannot be enforced against assets that are not in scope of discovery, review, or ownership. The article shows a familiar but dangerous pattern: security teams rely on policy after deployment while the asset landscape is already moving. Practitioners should make discovery continuous and tie it to access review, not periodic cleanup.

Business logic attacks expose the limits of signature-led defence. WAFs and gateways can block known patterns, but they do not prove that an allowed request is authorised for the business action it triggers. That leaves a governance blind spot around object-level access, workflow abuse, and delegated privileges. Practitioners should judge API controls by whether they reduce abuse of legitimate functionality, not by block counts alone.

Control lag is the real exposure multiplier. When APIs change daily but governance runs monthly, the organisation accumulates unmanaged drift faster than it can be triaged. That creates a visibility debt that also affects NHI programmes, because the same APIs often rely on service accounts, keys, and tokens that are not rotated or reviewed at the same pace. Practitioners should align inventory, review, and credential governance to release velocity.

OWASP and PCI only help when enforced at runtime, not just on paper. Policy mapping is useful, but the article’s core issue is operational enforcement at the point of access. A named concept here is API visibility debt: the growing gap between the APIs that exist and the APIs security teams can confidently account for. Practitioners should treat that debt as a measurable governance risk, not an abstract tooling issue.

What this signals

API visibility debt: security programmes that cannot keep pace with API release velocity will struggle to maintain any reliable inventory, let alone consistent authorisation and logging. The practical signal is not just more tooling, but tighter linkage between change management, ownership, and access review so unreviewed endpoints do not drift into production unnoticed.

For identity teams, the pressure point is service credentials rather than endpoints alone. APIs are frequently powered by tokens, keys, and delegated identities, so the next control conversation should extend beyond discovery into credential rotation, ownership attestation, and revocation discipline. A useful reference point is Ultimate Guide to NHIs , The NHI Market, which helps frame the broader governance surface.

For practitioners

• Establish continuous API discovery Inventory every internal, external, managed, and unmanaged API on a cadence that matches release velocity, then reconcile ownership, authentication method, and data sensitivity after each change window.
• Tie API review to identity and secrets governance Map each API to the service accounts, tokens, and API keys it depends on, then verify rotation, offboarding, and scope reduction whenever an endpoint changes.
• Measure unowned and undocumented API exposure Track the number of APIs with no named owner, no recent review, or no documented data flow, and treat growth in that metric as a governance exception requiring escalation.
• Test for business logic abuse paths Validate whether allowed requests can trigger unintended actions, overbroad data retrieval, or workflow chaining that bypasses simple perimeter enforcement.

Key takeaways

• API security fails when discovery, ownership, and review operate on different cadences than development.
• Legacy perimeter tools can miss abuse of legitimate API behaviour, leaving business logic flaws outside their detection model.
• Treat undocumented APIs and their service identities as a governance problem, not only a technical scanning problem.

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 Attack: A business logic attack uses valid application behaviour to cause an unintended outcome. Instead of breaking syntax or exploiting a known vulnerability, the attacker manipulates workflow, authorisation, or data access rules so the system does something it was never meant to do.
• AI Visibility Debt: AI visibility debt is the growing gap between how quickly employees adopt AI and how slowly the organisation discovers and governs that use. It builds when sanctioned tools lag behind user demand, leaving security teams with incomplete inventories, weak policy enforcement, and limited evidence for access reviews.
• Service Identity: A service identity is a non-human identity used by applications, workloads, or automation to authenticate and access resources. It may be a role, token, key, or certificate, and it needs the same lifecycle discipline as any privileged identity because it can directly expose data.

What's in the full article

Salt's full analysis covers the operational detail this post intentionally leaves for the source:

• Detailed breakdown of Salt Illuminate's discovery workflow for internal, external, managed, and unmanaged APIs.
• Examples of how the platform maps data flows and attack signals across API relationships.
• Policy Hub coverage showing how the vendor frames OWASP and PCI alignment at the point of access.
• Context-rich alerting examples for business logic abuse and data exfiltration scenarios.

👉 Salt's full post covers the survey breakdown, visibility findings, and runtime protection detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the broader security programme that APIs and automation now depend on.