Why do microservices and APIs make broken access control harder to control?

Microservices and APIs multiply the number of places where authorization can fail. When permission logic is duplicated across services, the same user or machine identity can be treated differently depending on which endpoint it reaches. That creates drift, weak auditability, and a much larger attack surface.

Why This Matters for Security Teams

Microservices and APIs do not just increase the number of endpoints; they fragment the authorization decision itself. A request may be accepted by an API gateway, forwarded by one service, and then trusted by a downstream service that never rechecks whether the caller should have that privilege. That is how broken access control becomes persistent drift instead of a single misconfiguration. Current guidance from the OWASP Non-Human Identity Top 10 treats this as an identity and privilege governance problem, not just an application bug.

The risk is amplified by non-human identities that outnumber human users and often carry broad, reusable permissions. NHIMG notes that NHIs outnumber human identities by 25x to 50x in modern enterprises in its Ultimate Guide to NHIs. In distributed systems, those identities are reused across CI/CD, service-to-service calls, and third-party integrations, so a single access-control mistake can propagate quickly across environments and teams. In practice, many security teams encounter privilege creep only after an internal service has already been used as the easiest path to data or admin functions, rather than through intentional authorization design.

How It Works in Practice

Broken access control becomes harder to manage when each microservice implements its own rules, especially if teams mix RBAC, ad hoc allowlists, and endpoint-specific checks. A user or service account may be validated at the front door, but later calls are assumed to be trusted because they came from inside the network. That is a weak model for modern API estates, where service meshes, asynchronous workers, and partner APIs all create different trust boundaries.

Practical control starts by making authorization explicit and consistent at runtime. A common pattern is to centralise policy decisions in a policy engine, then enforce them in each service or via an API gateway. That gives teams one place to express least privilege, separation of duties, and context-aware conditions such as tenant, environment, request type, and data sensitivity. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it highlights how secret sprawl and excessive privilege usually travel together.

• Use unique identities for services instead of shared credentials across environments.
• Apply authorization at the gateway and again in the service when the data or action is sensitive.
• Prefer short-lived tokens and scoped permissions over long-lived static secrets.
• Log both the decision and the context so auditors can reconstruct why access was granted.

For regulated environments, PCI DSS v4.0 reinforces the need to restrict access to system components and cardholder data by business need. These controls tend to break down when legacy services trust network location more than identity, because east-west traffic bypasses the checks that exist at the edge.

Common Variations and Edge Cases

Tighter authorization often increases latency, engineering overhead, and policy maintenance, requiring organisations to balance strong control against delivery speed. That tradeoff is real in high-throughput systems, event-driven architectures, and hybrid estates where not every service can call a central policy engine on every request.

There is no universal standard for exactly where authorization must live in a microservice chain. Current guidance suggests that high-risk actions should be rechecked close to the resource, while lower-risk read paths may rely on shared policy enforcement if the identity and context are still preserved. Teams should be cautious with “trusted internal traffic” assumptions, because internal APIs are often the easiest route for lateral movement once one service account is compromised.

Edge cases include batch jobs, async queues, and machine-to-machine integrations where the original caller context can be lost. In those cases, security teams should preserve actor identity, requested action, and approval context in the message itself or in an attached token chain. The 52 NHI Breaches Analysis shows how identity abuse often starts with a narrow compromise and expands because downstream systems fail to distinguish legitimate service activity from abused privilege. Where services were designed before zero trust became a baseline, broken access control is hardest to control because the architecture assumes trust after the first hop.

Related resources from NHI Mgmt Group

• What breaks when broken access control is treated as a purely application-layer issue?
• Why do NHIs make access control harder to govern than human users?
• Why do shared workstations make CJIS access control harder?
• Layer 7 access control