API threat patterns are rising faster than common controls can track

At a glance

What this is: This is an analysis of API threat trends, showing that vulnerability volume, OAuth exploitation, and detection activity are all increasing across public and internal data sources.

Why it matters: It matters because APIs often carry delegated access and tokens, so IAM, PAM, and NHI teams need to treat API security as an identity and authorisation problem, not only an application-layer one.

By the numbers:

• In 2020, SQL injection-related CVEs were at 466, and by 2023 that number had soared to 2,159, a 363.30% increase.
• OAuth vulnerabilities rose from just one CVE in 2012 to 42 CVEs in 2023.
• At the beginning of 2024, Salt’s internal detections in key web vulnerability categories were 1.5 times higher than those recorded in 2023.

👉 Read Salt’s analysis of rising API threats and OAuth exploitation patterns

Context

API security is the discipline of controlling how software systems authenticate, authorise, and exchange data through interfaces. In practice, the risk is not just injection flaws or broken endpoints. It is that APIs routinely extend trust across services, tenants, and identities, including tokens, service accounts, and delegated access paths.

This article is useful because it frames API security as a measurement problem as much as a prevention problem. For identity and security teams, the intersection with IAM and NHI governance is direct: OAuth flows, API keys, and service-to-service access all create identity surfaces that can be overused, under-monitored, or left outside normal lifecycle controls.

Salt’s starting position is typical of the current market discussion. Teams can see more API activity than before, but they still lack a consistent way to prioritise the threats that matter most to identity, application, and runtime controls.

Key questions

Q: How should security teams govern OAuth 2.0 in enterprise environments?

A: Security teams should govern OAuth 2.0 as a delegated access model with lifecycle controls. That means inventorying clients, limiting scopes, reviewing grants on a schedule, and revoking stale tokens and client secrets. OAuth is safest when it is treated as managed NHI behaviour rather than a one-time integration choice.

Q: Why do AI agents create new risk for IAM and NHI programmes?

A: Because they can execute actions, inherit permissions, and connect to sensitive systems without a human acting each time. That shifts risk from static account management to runtime behaviour, delegated access, and lifecycle control. IAM programmes must therefore track both the agent and the identities it uses.

Q: What do security teams get wrong about API security scanning?

A: They often treat API scanning as a vulnerability-only exercise. In practice, API findings frequently point to authentication failures, overexposed data, and broken trust between services. That means the response must involve IAM, token governance, and service identity review, not just patching the API surface.

Q: How should security teams reduce risk from exposed API secrets?

A: Start by assuming any exposed API secret will be copied, shared, and reused. The most effective response is immediate revocation, reissuance, and workload scoping, followed by short-lived credentials and replay detection. Detection without automated kill-switches only tells you that the secret was found, not that the risk has been removed.

Technical breakdown

Why CVE growth matters for API security posture

CVE counts are not a complete measure of risk, but they do show where disclosure pressure and attacker attention are concentrating. In this article, SQL injection, XSS, CSRF, SSRF, and OAuth-related weaknesses all trend upward, which suggests expanding attack surface rather than isolated incidents. For practitioners, the key issue is that API programmes often treat vulnerability intake and API authorisation as separate tracks. That separation breaks down when an exposed endpoint also handles tokens, delegated scopes, or machine-to-machine access.

Practical implication: tie API vulnerability triage to identity and access scope, not just to exploitability scores.

How OAuth exposure becomes an identity problem

OAuth is a delegated authorisation framework, so abuse rarely starts with a password in the traditional sense. The issue is often weak consent handling, over-broad scopes, missing validation, or poor visibility into third-party connected applications. When those controls fail, the API layer becomes an identity layer by another name. That matters to IAM and NHI teams because tokens, refresh grants, and app-to-app integrations can persist after the business owner has lost sight of them.

Practical implication: treat OAuth-connected apps and tokens as governed identities with ownership, scope, and lifecycle rules.

What bug bounty and telemetry data reveal about runtime risk

Bug bounty findings and internal telemetry are both useful because they show what attackers and researchers actually find after deployment, not just what static scans predict. The article’s combined view points to recurring web vulnerability patterns and a rising volume of detections over time. That suggests API risk is not simply a backlog of old flaws. It is a live operational condition that changes with release pace, integration sprawl, and access design.

Practical implication: use runtime detection and posture signals together, then feed findings back into identity and application control owners.

Threat narrative

Attacker objective: The attacker seeks to turn insecure API trust relationships into access to sensitive data, delegated accounts, or privileged system actions.

1. Entry occurs through exposed or weakly governed API attack surfaces, especially where OAuth flows, code injection paths, or misconfigured endpoints are present.
2. Escalation follows when attackers abuse delegated authorisation, over-broad scopes, or vulnerable request handling to move from probe to meaningful access.
3. Impact lands in data exposure, account abuse, or platform compromise when APIs expose sensitive records or privileged actions without sufficient control separation.

NHI Mgmt Group analysis

API security is now an identity governance problem as much as an application security problem. APIs frequently carry delegated access, machine tokens, and service-to-service trust, which means the control failure is often not code alone but ownership and lifecycle ambiguity. When teams cannot map which identities are allowed to call which APIs, security gaps persist even if individual flaws are patched. The practitioner conclusion is that API security must sit inside IAM and NHI governance, not beside it.

OAuth has become a durable non-human identity risk surface. OAuth-connected applications behave like governed identities because they hold scopes, tokens, and authorization paths that can outlive human awareness. The article’s rising CVE counts reinforce a broader point: delegated trust is easier to create than to review. That creates a persistent verification trust gap, especially when third-party apps and workload integrations are not fully inventoried. The practitioner conclusion is to treat OAuth consent and scope management as lifecycle controls, not one-time setup.

Elastic detection without ownership creates posture management fatigue. The article combines public vulnerability data, bug bounty signals, and internal telemetry, but the deeper lesson is that visibility alone does not equal control. Security teams can accumulate findings faster than they can assign remediation ownership across application, platform, and identity teams. That creates a blind spot where repeated API findings become normalized noise. The practitioner conclusion is to link detections to accountable control owners and measurable remediation SLAs.

API threat monitoring should converge with workload identity and secrets governance. APIs are often protected by API keys, tokens, and service accounts rather than by strong human authentication flows. That means the same environments that expose injection flaws also expose identity sprawl if secrets are unmanaged. The practical governance shift is to unify API security with NHI oversight, especially where machine identities authenticate into production services. The practitioner conclusion is to stop treating API protection as a purely perimeter or runtime issue.

What this signals

API security programmes are likely to keep converging with identity governance because the most consequential failures are now around delegated trust, not just vulnerable code. The practical signal for teams is clear: if you cannot answer who owns an integration, what it can do, and when it should be removed, you do not yet have control of the API surface.

Delegated trust sprawl: this is the accumulation of OAuth grants, service credentials, and API keys that no longer map cleanly to a current business need. The more that sprawl grows, the more likely security teams will face access paths that bypass ordinary review cycles. That is where identity and application governance must be aligned, not siloed.

For identity and cloud teams, the next step is to pair API posture data with workload identity and secrets telemetry so exposure can be prioritised by business impact. The relevant control question is not simply whether an API has a weakness, but whether that weakness opens a live access path into production data or privileged workflows.

For practitioners

• Inventory OAuth-connected applications and scopes Build a current register of every third-party and internal app connected through OAuth, then record the scopes, owners, and business purpose for each one. Reconcile that register against the 85% visibility gap highlighted in the 52 NHI breaches analysis so hidden app-to-app trust paths do not persist.
• Bind API findings to identity owners Route API vulnerability findings to the team that owns the affected token, integration, or workload identity, not only to the application backlog. Use ownership, scope, and lifecycle metadata so remediation is traced to the actual control gap.
• Review delegated access for excessive scopes Audit tokens, refresh grants, and service credentials for scopes that are broader than the API function requires, then narrow them before the next release cycle. Where third-party integrations remain active, verify they still have a documented business owner.
• Add runtime signals to posture management Correlate API detections, bug bounty findings, and scanning results into one queue so repeated patterns are visible as a systemic issue rather than isolated noise. Use that queue to prioritise the endpoints most likely to expose sensitive data or privileged actions.

Key takeaways

• API vulnerability trends matter most when they expose delegated identity paths, not just when they increase raw CVE counts.
• OAuth-connected apps, service accounts, and tokens should be governed as identities with ownership, scope, and lifecycle controls.
• The operational shift is to combine vulnerability data, runtime detection, and identity metadata before remediation priorities are set.

Key terms

• OAuth-connected integration: An OAuth-connected integration is a third-party application that receives delegated permission to act inside a user or workspace boundary. In NHI governance, it must be treated as a non-human identity with explicit scope, ownership, and review, because compromise of the integration can inherit the access it was granted.
• API Lifecycle Management: API lifecycle management is the practice of governing APIs from creation through versioning, change, retirement, and revocation. For security teams, the important part is tying identity controls to each phase so credentials, permissions, and integrations do not outlive the service they support. That keeps machine access from becoming permanent by default.
• Delegated trust sprawl: Delegated trust sprawl is the accumulation of OAuth grants, API keys, service accounts, and integrations that outgrow their original business purpose. The risk is not only excess access, but also poor visibility into who owns each trust relationship and when it should be removed or narrowed.

What's in the full article

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

• The CVE-by-CVE breakdown behind the API vulnerability trend analysis.
• Salt's internal telemetry examples for SQL injection, code injection, XSS, and path traversal.
• The OAuth detection and posture rule changes described in the source article.
• The vendor's own action items for responding to the observed API threat patterns.

👉 Salt’s full post covers the CVE tables, bug bounty trend comparisons, and internal telemetry behind the findings.

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 wider security programmes their organisations depend on.