API security best practices are really identity governance in disguise

At a glance

What this is: This is a StackHawk guide to 11 API security practices, with the central finding that strong authentication, authorization, and lifecycle controls are the foundation of API defence.

Why it matters: It matters because API exposure is now a primary identity problem: IAM teams must govern human, NHI, and service-to-service access consistently across auth, tokens, and permissions.

By the numbers:

• APIs now account for more than 80% of all internet traffic, making them prime targets for cyberattacks.
• 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.

👉 Read StackHawk's API security best practices guide

Context

API security is not just a developer concern. It is an identity governance problem because every API call depends on proving who or what is calling, what it can do, and how long that access should last. In practice, the most common failures are weak authentication, overbroad authorization, and credentials that outlive the workload or user they were issued for.

The article frames API security as a set of practical controls across the development lifecycle, from token validation and TLS to rate limiting, logging, testing, and gateway enforcement. For identity teams, the relevant question is how those controls map to human accounts, service accounts, tokens, and API keys without creating standing privilege or blind spots.

Key questions

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. That means assigning ownership, defining scope, logging use, and removing credentials when the business process ends. The same lifecycle logic used for service accounts applies here, because stale API credentials are a common path to misuse and data exposure.

Q: Why do APIs create governance problems for IAM teams?

A: APIs turn identity decisions into machine-to-machine enforcement problems. Tokens, scopes, service accounts, and roles all shape what a caller can do, but those controls are easy to overextend when teams optimise for delivery speed. IAM teams need to treat APIs as a place where identity scope must be tested continuously, not assumed from design.

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. In practice, this turns a valid token into a broad entitlement, which is how exposed accounts and weak scopes become data leakage. Fine-grained checks are what keep a legitimate session from becoming overbroad access.

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.

Technical breakdown

Authentication and authorization at the API edge

APIs usually fail when authentication proves identity but authorization fails to constrain actions. Authentication answers who is calling, while authorization answers what that caller may do at the endpoint, object, or field level. That distinction matters because a valid token can still be abused if it carries broad scopes, stale roles, or missing object checks. In API-heavy environments, the gateway often becomes the policy choke point, but only if the same identity context is enforced consistently across all calls.

Practical implication: enforce endpoint, object, and field-level checks so a valid token never becomes a blanket entitlement.

Tokens, secrets, and transport protection

API security depends on the safe handling of secrets and the integrity of traffic in transit. OAuth 2.0 and OpenID Connect reduce reliance on static credentials, while JWTs must be signed, validated, and expired correctly. TLS protects credentials and session data from interception, but only if weak protocol versions are disabled and certificate hygiene is maintained. For machine-to-machine access, API keys and certificates are still identities, not just configuration values, so their protection and rotation are part of access governance.

Practical implication: treat tokens, keys, and certificates as governed identities with rotation, expiry, and transport controls.

Rate limiting, logging, and testing as control feedback

Security controls are incomplete without feedback loops. Rate limiting reduces brute force and scraping risk, logging provides evidence of misuse, and automated testing exposes broken auth or injection flaws before release. None of these controls replace authorization, but they reveal whether access policy is behaving as intended under load and abuse. The strongest pattern is layered control at the gateway and in CI/CD, where misconfigurations are detected before they become persistent exposure.

Practical implication: pair runtime throttling with continuous test coverage so access failures surface before attackers exploit them.

Threat narrative

Attacker objective: The attacker wants to convert one valid API foothold into repeatable access, data exposure, or automated abuse across business services.

1. Entry occurs when an attacker finds an exposed credential, a weak auth flow, or an unprotected endpoint that accepts requests without adequate verification.
2. Escalation follows when the caller retains broad authorization or field-level access, allowing resource enumeration, data extraction, or privileged actions beyond the intended scope.
3. Impact is achieved through data theft, account abuse, service disruption, or automated scraping at scale, often without triggering obvious alarms.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Standing API credentials are the real blast-radius problem. API keys, bearer tokens, and service credentials create durable access paths that are easy to forget and hard to scope cleanly. The article correctly emphasises rotation, TLS, and gateways, but the deeper issue is that long-lived credentials outlast the business justification that created them. The practical conclusion is that exposure window, not just secret strength, determines real risk.

Endpoint-level control is necessary but not sufficient for API-era least privilege. Many teams stop at authenticating the caller, yet object-level and field-level authorization are what prevent one authenticated identity from seeing too much. That is why three of the OWASP API Top 10 risks still map back to authorization failure. IAM teams should measure entitlement precision, not just login success.

Secret sprawl is the named concept this article points to. APIs accumulate credentials across code, gateways, CI/CD, and third-party integrations, and each copy becomes a separate governance problem. When the same secret is reused across environments or services, revocation becomes partial and accountability becomes unclear. Practitioners need to manage secret sprawl as an identity lifecycle issue, not an operations nuisance.

API control maturity now depends on how well security and engineering share enforcement responsibility. The strongest pattern in the article is centralized policy with gateway enforcement, but that only works when developers and identity teams align on scopes, logs, and review cadence. The field is moving toward programmable access governance for machine traffic. Teams that still treat APIs as a separate security domain will keep missing the identity layer underneath.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, which explains why API governance often fails at inventory and ownership.
• Forward-looking implication: Read the Guide to the Secret Sprawl Challenge for a deeper view of how hidden credentials accumulate across delivery pipelines and runtime systems.

What this signals

Secret sprawl is the control problem most API programmes underestimate. When credentials are scattered across code, gateways, and CI/CD tools, revocation becomes incomplete and ownership becomes fuzzy. The governance response is to stop treating API secrets as configuration and start treating them as lifecycle-managed identities with review, expiry, and offboarding. For teams building or maturing API governance, that shift matters more than another layer of perimeter policy.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, API programmes that still rely on broad scopes will keep creating avoidable blast radius. The practical signal is that least privilege must be proven in the entitlement model, not assumed from token format or gateway placement.

API security teams should also align with NIST SP 800-53 Rev 5 Security and Privacy Controls where access control, authentication, and audit logging intersect. The next maturity step is not only stronger auth, but better proof that every API credential has a purpose, an owner, and an expiry condition.

For practitioners

• Classify every API credential as an identity object Inventory API keys, bearer tokens, service accounts, and certificates with owners, scopes, expiry, and revocation paths. If a credential cannot be traced to a business purpose, treat it as unmanaged access and remove it from production.
• Push authorization checks below the endpoint layer Require object-level and field-level authorization for any API that returns customer, payment, or administrative data. Validate the authenticated principal against the specific resource on every request, not only at login.
• 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. Link rotation to service ownership so revocation happens when integrations change or workloads are retired.
• Centralise policy at the gateway, not in scattered services Use an API gateway to enforce authentication, throttling, TLS termination, and logging consistently across services. Then backstop that control with continuous testing in CI/CD so broken auth, CORS, and injection issues are caught before release.
• Measure access drift with regular reviews Review scopes, dormant keys, and unused permissions on a fixed cadence, then remove access that no longer matches the workload or user. Pair the review with logging analysis so you can distinguish legitimate traffic from credential abuse.

Key takeaways

• API security is fundamentally an identity control problem because every request depends on a governed caller, a scope, and a trust boundary.
• The biggest practical risk is not just exposed credentials, but long-lived access that outlasts the business need behind it.
• Teams that combine fine-grained authorization, secret lifecycle control, and gateway enforcement will reduce exposure far more than teams that rely on authentication alone.

Key terms

• API Message Credential: An API message credential is the browser-side credential used to transport authorised requests to backend APIs. In this article's context, it is not a general login session but a constrained transport mechanism that should be short-lived, tightly scoped, and protected from browser exposure.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Gateway Enforcement: Gateway enforcement is the use of the API gateway as the place where policy is applied before traffic reaches backend services. It combines authentication, rate limiting, quotas, segmentation, and logging so the organisation can control both access and consumption in one place.

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

👉 StackHawk's full guide covers the implementation detail behind auth, TLS, gateways, and testing

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.