Topic starter
01/08/2026 9:00 pm
TL;DR: APIs now underpin core business systems, but 94% of organisations have seen API security problems in production and 19% have already had an API-related breach, according to SALT. That shifts API security from a technical hygiene task into a governance problem where discovery, runtime control, and change velocity all matter.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “Get Smart(er) about the business value of API security”.
By the numbers:
- 94% of survey respondents had experienced API security problems in production, according to Salt research.
- 19% admitted to an API-related breach, according to Salt research.
- 11% of respondents update their APIs daily, according to Salt research.
Key questions
Q: What breaks when API authentication is weak or token governance is missing?
A: The API stops behaving like a controlled interface and starts behaving like a standing access path.
Q: Why do poorly controlled APIs increase breach and compliance risk?
A: APIs often expose sensitive data and business functions, so weak authentication, missing authorization, or inconsistent policy enforcement can let attackers access records, disrupt services, or move laterally through connected systems.
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.
Practitioner guidance
- Implement continuous API discovery and ownership mapping Track every exposed API, its owner, its data scope, and its consumer set so security decisions are based on live inventory rather than stale documentation.
- Enforce function-level authorisation checks Validate that each API function only performs the business action it is intended to expose, especially where partner integrations or service accounts can reach sensitive records.
- Bind service credentials to API scope Limit tokens, keys, and service accounts to the minimum API functions and datasets they need, and review that scope whenever integrations change.
Bottom line: API security is now a governance issue because fast-changing interfaces create control gaps that static reviews do not close.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 9:06 pm
API security is now an access governance problem, not a niche application problem. Once APIs become the front door to customer data, partner integrations, and machine-to-machine workflows, the question is who can call what, under which conditions, and how that access is governed over time. That is an identity and authorisation problem as much as an application problem. Practitioners should stop treating API abuse as an isolated technical event and start treating it as a control-plane failure.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: How should organisations align IAM with API security governance?
A: They should treat APIs as access paths that carry identity, privilege, and lifecycle obligations. That means service accounts, OAuth applications, and workload tokens need the same ownership, scope review, and retirement discipline that human accounts receive. Without that alignment, API security remains fragmented across teams.
👉 Read our full editorial: API security is now a governance issue, not just a breach issue