API security gaps are widening as microservices expand attack surface

At a glance

What this is: This is an API security explainer that says the risk is expanding because modern organisations now expose hundreds or thousands of endpoints, with broken authentication, broken object level authorization, and misconfiguration creating common paths to data access.

Why it matters: It matters because API endpoints often sit behind human and service identities, so IAM, authorization, logging, and least-privilege controls must cover both user-facing and machine-to-machine access patterns.

👉 Read SecurityScorecard's full API security guide

Context

API security is the discipline of protecting application programming interfaces from unauthorized access, data exposure, and abuse. The core problem is not just encryption in transit, but the combination of authentication gaps, authorization errors, undocumented endpoints, and monitoring blind spots that appear as organisations move to microservices and cloud-native architectures.

That creates a genuine identity governance issue as well as a cyber operations issue, because APIs are accessed by users, service accounts, tokens, and federated identities. If access controls do not bind those identities tightly to specific resources and actions, attackers can abuse valid pathways rather than break through a perimeter. The article’s starting position is typical for enterprises that grew their API estate faster than their governance model.

Key questions

Q: How should security teams implement API security in microservices environments?

A: Security teams should combine API discovery, consistent gateway policy, per-endpoint authorisation, and continuous logging. In microservices, the risk is not one exposed application but many small trust decisions spread across services. The strongest programmes treat each API as a governed access path with named owners, reviewed scopes, and monitored behaviour.

Q: Why do broken API authentication controls create such a large breach risk?

A: Broken API authentication is dangerous because a valid caller can be accepted before any deeper control has a chance to stop abuse. Once a token or key is trusted, an attacker can access the same functions and data that the legitimate integration can reach, which makes overprivilege and stolen credentials especially costly.

Q: What breaks when API discovery is incomplete?

A: When discovery is incomplete, security teams miss shadow APIs, forgotten integrations, and endpoints that no longer have an obvious owner. Those gaps prevent consistent authentication, logging, rate limiting, and offboarding, which creates an easy path for attackers to find overlooked access points. An API estate cannot be governed if it cannot be inventoried.

Q: How do organisations know if API monitoring is actually working?

A: Good monitoring shows who called which endpoint, with what scope, how often, and whether the request pattern matches normal business use. If teams can only see traffic volume but not identity and request intent, they do not have enough context to detect scraping, overuse, or delegated abuse. Monitoring must answer behaviour questions, not just availability questions.

Technical breakdown

Broken object level authorization in API requests

Broken object level authorization happens when an API checks that a caller is authenticated but fails to confirm that the caller is allowed to access the specific object requested. In practice, an attacker changes an identifier in the request and retrieves another user’s record, invoice, or file. This is especially common in REST-style designs where object identifiers are easy to enumerate and backend logic assumes the client will behave. The weakness sits in the authorization layer, not the transport layer, so TLS does not prevent it.

Practical implication: enforce object-level authorization checks on every request, not just session-level authentication.

Why API gateways and CORS settings matter

API gateways centralise routing, authentication, rate limiting, and logging, which makes them powerful control points but also attractive targets. Weak gateway policy or overly permissive Cross-Origin Resource Sharing settings can expose endpoints to unintended callers, especially when browser-based clients are involved. CORS does not replace authorization, but misconfigured policies can widen the set of origins that can interact with an API. Gateways help, yet they only work when each backend service inherits the same policy discipline.

Practical implication: standardise gateway policy and review CORS rules as part of every API security change.

OAuth, OpenID Connect, and service-to-service trust

OAuth tokens and OpenID Connect are common ways to authenticate and authorise API access, but they also create failure modes when scopes are too broad, tokens last too long, or validation is inconsistent. In machine-to-machine environments, certificate-based mutual TLS can strengthen trust between services, but identity still needs to be bound to least privilege. The issue is not the protocol itself. It is whether the organisation treats token scope, audience, rotation, and revocation as governance controls rather than implementation details.

Practical implication: review token scope, expiry, and revocation paths as part of API identity governance.

Threat narrative

Attacker objective: The attacker wants to use legitimate-looking API traffic to reach sensitive data, backend functions, or downstream systems without triggering traditional perimeter controls.

1. Entry begins when attackers discover exposed, undocumented, or weakly protected API endpoints and test them for authentication and authorisation flaws.
2. Escalation follows when they manipulate object identifiers, abuse tokens, or exploit permissive gateway and CORS policies to reach data they should not see.
3. Impact occurs when stolen or misused API access enables data exfiltration, downstream compromise, or large-scale abuse across connected services.

NHI Mgmt Group analysis

API security is now an identity problem as much as an application problem. The article correctly frames APIs as the connective tissue of modern digital services, but the real governance issue is who or what is calling those APIs and with what authority. Human users, service accounts, OAuth tokens, and federated identities all need tighter scoping than many API programmes currently enforce. Practitioners should treat API access as part of identity governance, not a separate technical afterthought.

Broken object level authorisation is the most operationally useful concept in this discussion. It captures the gap between being authenticated and being allowed to act on a specific object, and that gap is what attackers exploit in real API abuse cases. For IAM teams, this is a reminder that identity proof alone does not solve access control if resource-level checks are inconsistent. Practitioners should map API authorisation failures to concrete entitlement boundaries.

Shadow APIs create the same governance problem that shadow identities do in NHI estates. If teams cannot inventory every endpoint, they cannot reliably apply authentication, logging, rate limits, or lifecycle controls. That is why API discovery and identity inventory belong in the same governance conversation. Practitioners should align API discovery with access review and offboarding processes, especially where service accounts and integration tokens are involved.

API security programmes fail when control ownership is fragmented. Development teams, platform teams, IAM teams, and SOC functions each see a different part of the risk, so no one owns the whole control path from discovery to response. The article’s strongest implication is that operational monitoring must be tied to identity governance and remediation accountability. Practitioners should build one control model that spans API inventory, authentication, authorisation, and monitoring.

API governance fatigue is becoming a real risk signal. As organisations accumulate hundreds or thousands of endpoints, teams often compensate with broader tokens, looser gateway policy, and weaker review discipline. That may preserve delivery speed, but it also expands blast radius. Practitioners should measure whether their control stack is reducing the number of trusted API paths or merely documenting them.

What this signals

API estates are converging with NHI governance whether teams recognise it or not. Once service accounts, OAuth apps, API keys, and certificates become the practical way to call business services, identity inventory and access review have to extend beyond human users. The programmes that manage this well will treat API identities as governed assets with owners, scopes, and lifecycle controls, not as hidden implementation details.

Shadow API exposure and shadow identity exposure now fail in the same place: visibility. If organisations cannot see the endpoint, they cannot reliably secure the credential or the caller behind it. That is why inventory discipline, revocation readiness, and logging context need to be measured together, with access to the 52 NHI breaches Report providing useful pattern recognition for control gaps.

Governance maturity will increasingly be judged by blast-radius containment rather than endpoint count. The question is not how many APIs exist, but whether a compromised token, mis-scoped integration, or broken object check can reach beyond its intended boundary. Teams that align API controls with NIST SP 800-53 Rev 5 Security and Privacy Controls will be better placed to reduce that blast radius.

For practitioners

• Inventory every exposed and shadow API Build a complete list of public, partner, internal, and undocumented APIs, then tie each endpoint to an owner, authentication method, and data classification. Without a current inventory, you cannot enforce policy, logging, or offboarding consistently.
• Enforce object-level authorisation on each request Validate the caller’s entitlement against the specific resource being requested, not just the session or token. Test for identifier tampering, record enumeration, and broken access checks across high-value endpoints.
• Tighten token scope and revocation paths Limit OAuth and other API token permissions to the smallest viable scope, reduce lifetime where possible, and make revocation operationally fast. Tokens should be treated as governed credentials with lifecycle controls, not static implementation artefacts.
• Standardise gateway policy and logging Apply the same authentication, rate limiting, and audit requirements across all gateway-managed APIs, and verify that logs capture identity, request path, and resource context. This gives SOC and IAM teams the evidence they need for triage and review.
• Test APIs throughout the lifecycle Run automated security testing in CI, then supplement it with manual review for logic flaws, misconfiguration, and authorisation bypasses before release and after material changes. Lifecycle testing is the only way to catch regressions introduced by fast-moving services.

Key takeaways

• API security fails most often at the boundary between authentication and object-level authorisation, where valid identities are allowed to do too much.
• The scale problem is real: enterprise API estates now stretch into the hundreds or thousands, which multiplies inventory, logging, and review challenges.
• The most effective response is lifecycle governance, with discovery, scoped tokens, gateway policy, and continuous testing tied to named owners.

Key terms

• 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.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Mutual TLS: A two-way authentication method where both client and server present certificates and verify each other before communication begins. It is often used for service-to-service trust, but it still needs least-privilege policy, certificate lifecycle management, and logging to be operationally useful.
• API gateway: An API gateway is the enforcement layer that sits in front of backend services and decides how requests are authenticated, authorized, routed, logged, and rate limited. In partner ecosystems it functions as a control point for machine access, not just a traffic router, because it can unify identity and transport checks.

What's in the full article

SecurityScorecard's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance on API authentication mechanisms and where broken authentication typically appears in implementations
• Detailed comparisons of mutual TLS, OAuth, OpenID Connect, and WS-Security for different API deployment patterns
• Practical discussion of API security testing, monitoring, and vulnerability management across the development lifecycle
• Additional examples of security misconfiguration patterns, including default credentials, CORS exposure, and verbose error handling

👉 SecurityScorecard's full article covers the testing, monitoring, and lifecycle controls in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It is designed for practitioners who need to connect API access, service identity, and governance decisions across their broader security programme.