TL;DR: APIs now account for more than 80% of internet traffic, and a single exposed credential or broken auth flow can open the door to unauthorised access, data theft, and abuse, according to StackHawk. The practical lesson is that API security is identity governance, access control, and lifecycle management applied at machine speed.
NHIMG editorial — based on content published by StackHawk: API Security Best Practices: 11 Essential Strategies to Protect Your APIs
By the numbers:
- Three of the OWASP API Security Top 10 risks relate directly to authorization failures.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
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 governance problems for IAM teams?
A: APIs turn identity decisions into machine-to-machine enforcement problems.
Q: What breaks when authorization is only checked at the endpoint level?
A: Endpoint-only authorization lets authenticated callers see or modify data they should not reach at the object or field level.
Practitioner guidance
- Classify every API credential as an identity object Inventory API keys, bearer tokens, service accounts, and certificates with owners, scopes, expiry, and revocation paths.
- Push authorization checks below the endpoint layer Require object-level and field-level authorization for any API that returns customer, payment, or administrative data.
- Shorten the lifetime of machine credentials Replace long-lived API keys where possible, set explicit expiry for tokens and certificates, and rotate anything that cannot be eliminated.
What's in the full article
StackHawk's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on authentication patterns for REST, GraphQL, and gRPC APIs
- Concrete rate-limiting examples for login, search, password reset, and write-heavy endpoints
- Implementation notes for gateway enforcement, observability, and CI/CD security testing
- OWASP API Security Top 10 mapping with remediation priorities for development teams
👉 Read StackHawk's API security best practices guide →
API security and identity controls: are your access checks enough?
Explore further
API security is identity governance, not just application hardening. The article is about controls, but the underlying problem is who or what is allowed to act through an API and for how long. That means IAM, PAM, and NHI lifecycle governance all apply at the API boundary. Practitioners should treat API policy as identity policy with a network-facing enforcement layer.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why API governance often fails at inventory and ownership.
A question worth separating out:
Q: How do teams reduce abuse without slowing legitimate API traffic?
A: Use rate limits, quotas, and throttling differently for authentication, read, and write operations. Then combine those controls with logging and alerting so you can distinguish normal bursts from brute force or scraping. The goal is not just to block volume, but to make abuse visible and containable.
👉 Read our full editorial: API security best practices are really identity governance in disguise