Topic starter
02/08/2026 12:21 pm
TL;DR: API incidents now center on broken authorization, static machine credentials, and chained abuse inside trusted sessions, with Salt in the middle of the finding. Correlated identity and API activity must be analysed together, because isolated alerts can miss abuse that only shows up across a full session.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “Seven API Security Predictions for 2022”.
Key questions
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.
Q: What breaks when authentication and authorization are conflated in API security?
A: The system starts treating identity proof as if it were permission.
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.
Glossary terms: Broken Object-Level Authorization, Broken Function Level Authorization, Machine Identity, API Dependency
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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