Topic starter
02/08/2026 12:21 pm
TL;DR: API incidents increasingly stem from leaky interfaces, broken authorization, static authentication values, and chained abuses that evade conventional controls, according to Salt. The governance problem is no longer API exposure alone but the combination of identity, automation, and third-party integration that outpaces review, detection, and runtime enforcement.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “Seven API Security Predictions for 2022”.
Key questions
Q: What breaks when authentication and authorization are conflated in API security?
A: The system starts treating identity proof as if it were permission.
Q: Why do machine credentials increase API security risk so quickly?
A: Machine credentials are hard to challenge interactively, easy to reuse across systems, and often remain valid far longer than their intended task.
Q: What are the warning signs that API abuse is being chained across services?
A: The main warning signs are unusually broad access after a normal login, repeated calls across nested endpoints, and activity that looks legitimate at each individual step but not across the whole session.
Practitioner guidance
- Inventory APIs as governed dependencies Classify first-party, partner, infrastructure, and internal APIs together so ownership, exposure, and trust assumptions are visible in one control plane.
- Tighten object and function authorisation Review BOLA and BFLA exposure by testing whether authenticated callers can access objects, actions, or nested queries beyond their intended scope.
- Remove static authentication values from automation Replace embedded API keys and long-lived secrets with short-lived machine credentials and owner-managed rotation, especially in CI/CD and partner integrations.
Bottom line: API incidents are increasingly shaped by authorization failure, static machine credentials, and chained abuse inside trusted sessions rather than by simple exposure alone.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:22 pm
API security governance fails when identity decisions are treated as a login problem instead of a runtime authorisation problem. Salt’s analysis shows that most damaging abuse happens after a session is already trusted, which means the real control gap is not authentication alone but authorization drift across objects, functions, and service boundaries. Practitioners should treat API access as continuous entitlement governance, not a one-time identity check.
A few things that frame the scale:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: How should security teams govern APIs that support third-party and partner integrations?
A: They should treat partner-facing APIs as governed access paths, not just technical interfaces. That means maintaining endpoint inventories, mapping exposed data, applying policy based on business context, and monitoring for behavioural deviation. Where APIs underpin regulated workflows, IAM, application security, and compliance teams should share the same policy model and response process.
👉 Read our full editorial: API security governance is failing where identity and automation meet