Notifications
Clear all
Topic starter
25/06/2026 12:50 am
TL;DR: API-related attacks are accelerating as insecure APIs and exposed tokens keep creating direct paths into sensitive systems, with the article citing 439 AI-related CVEs in 2024 and more than half of organisations reporting an API-related incident in the past 12 months, according to Apono. The real issue is not checklist fatigue but whether API governance now treats NHIs, scoped permissions, and request-level accountability as first-class controls.
NHIMG editorial — based on content published by Apono: The Required API Security Checklist [XLS download]
By the numbers:
- In 2024, researchers catalogued 439 AI-related CVEs, a staggering 1,025% increase over the prior year, and nearly 99% were tied to insecure APIs.
- 12 months., of organizations reported an API-related incident in the past 12 months.
Questions worth separating out
Q: How should security teams govern API access for service accounts and tokens?
A: Security teams should treat API callers as identities with owners, scopes, and lifecycles, not as anonymous technical plumbing.
Q: Why do APIs create so much risk for non-human identities?
A: APIs give non-human identities direct execution paths into applications, data stores, and partner systems.
Q: What breaks when API keys are long lived and hard to revoke?
A: Long-lived API keys keep access alive after the original task, owner, or environment has changed.
Practitioner guidance
- Inventory every API-exercising identity Create a complete register of service accounts, API keys, bots, partner credentials, and automation accounts.
- Replace standing API privilege with short-lived scopes Issue narrowly scoped, time-bound permissions for API calls and automate revocation when the task ends.
- Enforce request-level authorisation checks Apply RBAC or ABAC at the endpoint, resource, and object level instead of relying on coarse gateway authentication.
What's in the full article
Apono's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step control guidance for each checklist area, including authentication, secrets handling, and API inventory
- Implementation patterns for JIT and JEP access flows, including how temporary permissions are issued and revoked
- Practical logging and audit design details for tying identity, scope, and request activity together
- Operational examples for shadow API discovery, partner credential scoping, and incident response runbooks
👉 Read Apono's API security checklist for identity, logging, and least privilege →
API security checklists and NHI governance: what teams miss?
Explore further
25/06/2026 9:51 am
API security has become an identity governance problem, not just an application problem. The article is right to treat authentication, authorization, logging, and lifecycle control as one checklist because APIs are now where machine identities actually exercise privilege. Once service accounts and tokens are in play, traditional application security boundaries are no longer enough. Practitioners should treat the API as an identity enforcement point, not a transport layer.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the Secret Sprawl Challenge.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
A question worth separating out:
Q: Who should own API security in a large enterprise?
A: API security should be shared across application security, platform engineering, IAM, and compliance, but ownership must be explicit for each API and each machine identity. The critical issue is not which team has the budget line, but whether every endpoint and token has a named accountable owner.
👉 Read our full editorial: API security checklists are becoming NHI governance controls
