Notifications
Clear all
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.
NHIMG editorial — based on content published by Salt: API security predictions and governance risks for 2022
Questions worth separating out
Q: How should security teams handle API keys and tokens as part of identity governance?
A: Security teams should treat API keys and tokens as governed identities, not just technical secrets.
Q: Why do APIs create so many authorization failures in practice?
A: APIs expose business logic directly, so a valid login does not guarantee a valid action.
Q: What do security teams get wrong about API perimeter controls?
A: They assume syntax inspection and request reputation are enough.
Practitioner guidance
- Map API credentials to identity lifecycles Inventory API keys, OAuth clients, service accounts, and certificates as governed identities.
- Enforce server-side authorization on every object and function Review API handlers for broken object level authorization and broken function level authorization.
- Correlate runtime signals across sessions Instrument telemetry to link user and machine behaviour across an entire session, including unusual call sequences, privilege changes, and data access patterns.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- The article walks through the specific API security predictions that informed the analysis, including supply chain risk, authentication failures, and runtime control gaps.
- It expands on why API gateway, WAF, and access-control assumptions break down across first-party and third-party integrations.
- It includes the author’s discussion of how machine assistance and runtime correlation change detection expectations for API abuse.
- It outlines the governance and compliance implications that make APIs relevant to GRC and privacy teams.
👉 Read Salt's analysis of API security predictions and governance gaps →
API security and IAM gaps: what practitioners need to watch now?
Explore further
02/08/2026 1:22 pm
API security is now an identity governance problem, not just an application security problem. The article is right to connect API incidents with authentication, authorization, and machine identity because API calls are effectively identity decisions at runtime. When service accounts, OAuth scopes, and static secrets are left outside lifecycle governance, the organisation creates privileged pathways that conventional app testing cannot fully see. Practitioners should treat API governance as a shared IAM and runtime responsibility.
A question worth separating out:
Q: How should teams respond when API abuse is coming through trusted integrations?
A: They should narrow the trust boundary, reduce standing access, and review what each integration can read or invoke. Trusted does not mean safe when the caller is overprivileged or compromised. The immediate priority is to contain blast radius by tightening scopes, rotating exposed secrets, and segmenting high-risk API paths.
👉 Read our full editorial: API security governance is failing where identity and automation meet
