API exposure is outpacing security controls in digital platforms

At a glance

What this is: This is an analysis of why APIs have become a critical security surface as digital platforms absorb more business activity and attacker attention.

Why it matters: It matters because IAM, application security, and data security teams need visibility into API exposure, authentication boundaries, and the privilege attached to machine-to-machine access.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Salt's analysis of API exposure and security controls for digital platforms

Context

APIs have become the control plane of modern digital platforms, which means exposure is no longer limited to a few known production endpoints. Development environments, partner integrations, and fast-moving release cycles create a wider and less predictable attack surface, especially where identity and access decisions are embedded in machine-to-machine traffic. In practice, API security is also NHI security, because service accounts, tokens, and keys often govern access behind the scenes.

The governance gap is that many security teams still depend on tools that assume known signatures, stable patterns, and complete inventory. That model fails when business logic is unique and the set of APIs is constantly changing. Where APIs carry sensitive data or privileged workflows, organisations need visibility, prioritisation, and identity-aware controls rather than only perimeter detection.

Key questions

Q: What breaks when endpoint inventory is incomplete?

A: When endpoint inventory is incomplete, patching, configuration enforcement, and access restrictions all become partial controls. Unseen devices cannot be updated, monitored, or quarantined reliably, so attackers and unmanaged devices gain a path into the environment. The control failure is not just visibility, but unenforced policy.

Q: Why do APIs create identity risk even when the application code is secure?

A: APIs create identity risk because the code can be clean while the credentials behind it remain exposed, over-privileged, or reused. Attackers usually target the secret, not the endpoint. Once they have a valid key or token, they can impersonate the workload and inherit whatever access that identity already has.

Q: How do security teams know if API abuse controls are working?

A: Security teams know API abuse controls are working when repeated credential use drops, abnormal request volume is detected early, and hostile client behaviour is blocked before backend systems see sustained load. Effective controls reduce both attack success rate and the time abuse can persist unnoticed.

Q: How do organisations reduce API abuse without slowing delivery too much?

A: The best approach is to standardise policy at the gateway and delegate only narrow, pre-approved access patterns to development teams. Use rate limits, schema validation, and consistent authorization checks so every new API inherits controls by default. That reduces manual review overhead while keeping risky exceptions visible.

Technical breakdown

Why unknown APIs create persistent exposure

APIs are often created faster than they are catalogued. That leaves shadow endpoints in development, test, partner, or legacy environments that are reachable long after teams think they are retired. Because APIs frequently expose data through business logic rather than obvious vulnerabilities, attackers can abuse legitimate functionality instead of breaking encryption or authentication outright. The problem becomes sharper when access is mediated by service accounts or tokens, because the API itself may look harmless while the underlying identity remains over-permissioned and difficult to track.

Practical implication: build an inventory that includes non-production and partner-facing APIs, not just production routes.

Why signature-based security misses API abuse

Traditional security tooling looks for known attack patterns, but API abuse often arrives as valid-looking requests that only become malicious when viewed in context. That makes authentication, object-level authorisation, and business-logic validation more important than raw payload inspection. A request can be syntactically correct, use a valid token, and still retrieve data it should never access. This is why API security must include identity context, request semantics, and behavioural baselines rather than relying on static signatures alone.

Practical implication: pair runtime monitoring with authorisation testing, not just WAF or IDS rules.

How API security and NHI governance overlap

Every API environment depends on non-human identities such as service accounts, access tokens, and certificates. If those identities are hard to discover, over-privileged, or weakly rotated, then API risk becomes an identity governance problem. This is where the API layer and NHI layer converge: the attack surface is not only the endpoint, but also the credential lifecycle behind it. Controls that improve inventory, rotation, offboarding, and least privilege reduce the blast radius when an API is targeted or misused.

Practical implication: treat API authentication material as governed NHI, with lifecycle controls and access review.

Threat narrative

Attacker objective: The attacker aims to use legitimate API access paths to reach data, functions, or backend systems that should have remained inaccessible.

1. Entry occurs through exposed APIs in development, partner, or production environments that were not fully inventoried or monitored.
2. Escalation happens when attackers use valid-looking requests or weak object-level checks to reach data or functionality beyond intended access.
3. Impact follows as sensitive data is exposed, business logic is abused, or the attacker uses machine credentials to persist inside critical digital platforms.

NHI Mgmt Group analysis

API exposure is now an identity governance problem as much as an application security problem. The article describes a world where digital services depend on machine access, not just human sessions. That means service accounts, tokens, and certificates become part of the control surface, even when the security conversation starts with application logic. Practitioners should treat API inventory and NHI lifecycle management as a single governance problem, not two separate programmes.

Signature-based control is the wrong mental model for modern API defence. Attackers do not need malformed traffic when they can abuse valid requests against weak authorisation logic or undocumented endpoints. That is why the detection challenge is context, not just pattern matching. Security teams should expect the hardest API abuse to look legitimate at the packet level and focus on identity context, object-level permissioning, and behavioural monitoring.

Blind API sprawl creates a verification trust gap. When teams cannot say which APIs exist, who uses them, and what identity each endpoint trusts, they lose the ability to govern exposure decisively. Verification trust gap: the state where a platform accepts machine requests without reliable assurance about the identity, scope, or lifecycle of the caller. Practitioners should close that gap through inventory, access review, and token governance.

API programmes will increasingly converge with zero-trust and least-privilege design. The article’s central message is that business velocity expands attack surface faster than conventional security workflows can keep pace. That shifts emphasis toward continuous verification, narrow entitlements, and rapid removal of stale access. Teams that leave API governance inside development alone will keep inheriting preventable identity risk into production.

Security leaders need to measure exposure by reach, not by endpoint count alone. A large API estate is not automatically the problem; the problem is unknown reach, hidden privilege, and unmanaged access paths into data and business functions. The practical implication is to prioritise APIs by sensitivity of data, privilege of the backing identity, and likelihood of external exposure.

What this signals

API security programmes are increasingly forced to answer identity questions, not just application questions. If the organisation cannot govern service accounts, tokens, and certificates with the same discipline it applies to human access, the API layer becomes a hidden extension of IAM drift. The practical shift is toward shared ownership between application security and identity governance.

Verification trust gap: teams need to know which endpoints trust which identities, and for what scope, before they can reduce exposure confidently. That makes authorisation testing, lifecycle controls, and machine-identity review more important than perimeter-only tooling. For practitioners, the near-term signal is that API security metrics should start including identity ownership and credential hygiene.

The broader programme implication is that digital platform security will keep converging with least-privilege and zero-trust design. Security teams should expect more pressure to prove what APIs exist, who can reach them, and how quickly stale access can be removed. That governance requirement is now part of resilience, not an optional hardening exercise.

For practitioners

• Inventory every API surface Map production, development, partner, and internal APIs in one authoritative register, then tie each endpoint to the data it can reach and the identity that authenticates to it. Use the register to find endpoints that are active but not owned, documented, or reviewed.
• Bind API access to governed non-human identities Treat tokens, service accounts, and certificates as managed identities with owners, expiry, rotation, and offboarding rules. Remove shared credentials where possible and ensure each integration has a named business owner and a technical steward.
• Test object-level authorisation, not just authentication Validate whether authenticated callers can only reach the objects and functions they are meant to use. Include partner integrations and test for broken access control, because valid tokens do not prevent data exposure when authorisation checks are weak.
• Prioritise remediation by exposed data and business logic Rank APIs by the sensitivity of the data they can return, the business actions they can trigger, and whether they are externally reachable. That gives development and security teams a common basis for eliminating the exposures that matter most first.

Key takeaways

• API security failures increasingly reflect weak visibility and governance, not only technical flaws in code or transport.
• Machine credentials turn API exposure into an identity problem, because tokens and keys can outlive the systems that use them.
• Teams should prioritise inventory, authorisation testing, and lifecycle control if they want to reduce API risk without slowing delivery.

Key terms

• API Exposure: API exposure is the set of externally or internally reachable interfaces that can be discovered, accessed or abused by a third party. In practice, exposure becomes a governance issue when teams cannot inventory every endpoint, which leaves policy, logging and abuse detection uneven.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.

What's in the full article

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

• How to catalogue unknown APIs across development, partner, and production environments before they become shadow exposure.
• How to validate API authorisation paths and identify object-level access failures that signatures will not catch.
• How to connect API exposure findings to the service accounts, keys, and tokens that govern backend access.
• How to prioritise remediation when release velocity keeps changing the attack surface.

👉 Salt's full post covers API exposure, attacker targeting, and the control gaps behind custom platform risk.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners apply lifecycle controls where APIs, service accounts, and access tokens create governance risk.