Broken Authentication in Microservices and Service-to-Service APIs

The attack surface multiplication: microservices architectures and authentication boundaries

Broken authentication in a microservices setup doesn't look like a stolen password or a login form you can brute-force. It looks like a service mesh policy that never got applied to one namespace, a JWT that a downstream service trusts without checking its signature, or a token sitting in a JavaScript bundle that anyone can read. Broken authentication is a top-ranked entry on OWASP's API Security Top 10, and the 42Crunch State of API Security 2026 report puts it as the single most common API vulnerability, appearing in 23.5% of all reported cases. That number carries the whole argument here: broken authentication is the thing most likely wrong in your environment right now, in a service nobody's looked at since it shipped.

Most teams treat splitting a monolith into services as a scaling decision, and assume authentication just comes along for the ride. That assumption is wrong, and it's wrong in a way that costs real money later. A monolith has one front door. Lock it well, and the authentication problem is basically solved. A fleet of microservices has a front door for every service, and each one can be locked, half-locked, or standing wide open, independent of every other door in the building. Breaking a monolith apart turns authentication from one decision into dozens, sometimes hundreds, of separate decisions made by separate teams on separate timelines. Nobody ends up owning the full picture, because nobody was ever handed that job.

Three places generate most of these new trust boundaries.

Internal service-to-service calls are the biggest source: service A talks to service B, and "authentication" quietly becomes an assumption that anything already inside the network must be trustworthy. Third-party integrations come second. An outside partner gets a door into internal systems that nobody on the internal team watches closely, and unsafe consumption of third-party APIs accounted for 27% of incidents across an analysis of 60 disclosed API breaches in 2025, over a quarter of real-world cases. The third source is AI agents and automated workflows built on language models, each one spinning up new API endpoints as a matter of course and adding surface area faster than security teams can track it.

You can't authenticate what you haven't inventoried, and shadow APIs make the whole problem worse. Industry estimates consistently find that a significant share of organizations are running APIs they don't even know exist. Meanwhile the probing keeps climbing: average daily API attacks have risen from around 121 to 258. Attackers are mapping these internal boundaries with tooling faster than most engineering teams can draw the architecture diagram by hand, and that gap is the whole problem in miniature.

The specific forms broken authentication takes across service-to-service boundaries

Implicit internal trust is the oldest failure and still the most common one. A service sees a call coming from inside the network and treats that origin as proof enough, no further questions asked. Sometimes mTLS isn't enforced. Sometimes mTLS is technically configured but doesn't require a valid client certificate, which amounts to the same exposure as having no mTLS. Configuration-based authorization in a service mesh can look airtight on paper and still miss a workload or two, and that gap is visible only in the mesh config itself, never in application code a reviewer would normally read. The only real test is trying to hit a service directly with no valid token and watching whether the policy actually blocks you; a policy's mere existence in a configuration file proves nothing.

JWT validation gaps run a close second. A downstream service takes a token forwarded by whatever called it and trusts it outright instead of checking the signature itself. Some services read claims straight out of the token body, role: admin, say, without ever confirming the signing key that produced them. Expiration checks get skipped too, and a leaked token stays usable indefinitely with no clock running out on the attacker. Any serious test has to forward a token between services and check whether the receiving side actually re-validates it, or just waves it through because it arrived from the right direction.

Leaked and long-lived service tokens follow a depressingly simple mechanism: a secret gets hardcoded into source, a build artifact, or a JavaScript bundle, then sits there until someone finds it. In May 2025, researchers at CloudSEK documented exactly this at a major aviation company. A JavaScript bundle contained a hardcoded, unauthenticated endpoint, and that endpoint issued a Microsoft Graph API token with elevated permissions, exposing data tied to roughly 50,000 Azure AD users. Separately, thousands of Postman workspaces are publicly accessible, some holding live API keys and OAuth tokens sitting in plain sight, indexed and searchable by anyone who knows to look. Credential rotation adds its own failure window on top of that: if an API doesn't handle a credential update cleanly, the old token often keeps working right alongside the new one, so rotation gives you a false sense of closure while the door stays propped open.

Third-party trust overextension rounds this out, and the Paradox.ai and McDonald's case is the clearest illustration on record. Weak admin credentials combined with an IDOR flaw let someone enumerate around 64 million applicant records through the partner system. The trust extended too far into a partner's system, which is the point most companies get backwards: broken authentication between you and your vendor's API is still your breach. Ownership doesn't stop at the integration boundary just because the code does.

Failure modes invisible to standard blackbox tests and automated scans

Automated scanners match known vulnerability signatures against common misconfigurations. That's useful for catching the obvious stuff, but it's a different skill entirely from reasoning about whether a specific mesh policy actually covers a specific workload in a specific namespace. That's a judgment call, not a pattern match, and scanners don't make judgment calls.

BOLA and IDOR flaws prove the point. Static analysis tools consistently struggle with authorization logic bugs, because the vulnerability is a business logic decision rather than a bad code pattern. It's a business logic decision that happens to be wrong in a way only a human reading the intent behind the code would catch. Reported figures suggest that 60% of APIs get no security testing beyond basic authentication checks, so the authorization layer, where most of these bugs actually live, goes unexamined more often than not.

Blackbox testing carries a structural blind spot on top of that. If a service-to-service endpoint isn't exposed externally, a tester working from outside the perimeter simply can't see it. That's a gap built into the method itself, not effort or diligence. It's a gap built into the method itself. Misconfigured Istio policies or IAM role bindings stay invisible to anyone who can't read the infrastructure-as-code where those decisions actually get made, and no amount of poking at the public-facing app will ever reveal a mesh policy scoped to the wrong namespace.

What whitebox access to source code and configs reveals in service-to-service auth

Handing a tester the source code lets them read the JWT validation logic line by line, find the conditional branch that skips signature verification whenever the caller is flagged "internal," and point to the exact line where it happens. No guessing, no inference from behavior. Just the code doing the wrong thing in plain sight.

Giving that same tester access to the cloud configuration and infrastructure-as-code lets them audit every IAM policy, every service account binding, every mesh authorization rule that exists. That's the full set of trust decisions an organization has made, laid out in one place instead of scattered across a dozen systems nobody ever cross-references.

Hardcoded secrets get caught the same way, through direct inspection rather than guesswork. Scanning the actual codebase and CI/CD pipeline finds an embedded token before it ever makes it into a public bundle. The aviation incident from May 2025 is the textbook case: the flaw sat in a JavaScript bundle that anyone reading the source could have spotted well before it reached production. Reading through service registries, deployment manifests, and infrastructure configs also reveals the shadow APIs and abandoned endpoints that blackbox enumeration has no way of finding, because those endpoints were built for internal use only and never exposed to outside discovery.

A technical checklist for rigorously testing service-to-service authentication

Start with mutual TLS. Try hitting a service directly without a valid token and confirm the mesh policy actually rejects the request, not merely that a policy exists somewhere in a config file. Check whether mTLS runs in PERMISSIVE or STRICT mode across every workload namespace, because one namespace left in PERMISSIVE mode undoes the protection everywhere else in the mesh. This is the single most common gap, and it's the cheapest one to check.

Move to JWT validation next. Test whether a downstream service checks a token's signature independently, or just accepts whatever an upstream caller forwards on trust. Submit a token that's expired but otherwise valid to every internal endpoint and track which ones let it through. Then try the classic algorithm confusion attack, swapping the JWT header to "none" or a weak algorithm, and see if any service still accepts it without complaint.

Audit service accounts and credential hygiene after that. Confirm that rotating a credential doesn't cause a service interruption, and confirm the old credential stops working the moment the new one goes live, not sometime later. Check that service account scopes follow least privilege the same way human accounts are supposed to, since non-human identities get audited far less often and tend to accumulate permissions nobody remembers granting. Scan source code, build artifacts, and bundled JavaScript for hardcoded secrets, the exact pattern behind the aviation breach.

Finally, map every third-party integration and test whether trust is bounded by explicit validation or just assumed because of where the traffic originates. Run IDOR and BOLA tests against any endpoint that accepts an identifier handed to it by a third-party system, the same pattern that let the Paradox.ai enumeration happen at scale.

Broken-auth findings in service-to-service tests and their implications for SOC 2, HIPAA, and ISO 27001 audits

SOC 2 doesn't technically mandate a penetration test, but auditors expect one anyway, and the Trust Service Criteria are far easier to evidence with a test that covers internal service boundaries, not just the perimeter. A report that only checks external-facing endpoints leaves an obvious question hanging: how does anyone know the internal services aren't quietly trusting each other by default?

Hardcoded secrets and service tokens that never rotate are concrete findings, and they map directly onto SOC 2's logical access controls and ISO 27001's access management requirements. Auditors reading a pen test report treat these as findings that need remediation, not footnotes to skim past on the way to the summary page.

HIPAA's technical safeguards, access controls, audit controls, transmission security, all have a direct equivalent inside service-to-service authentication. A mesh policy that quietly allows unauthenticated internal calls into a service handling protected health information is a technical safeguard failure, and it reads that way to anyone reviewing the environment against the regulation. There's no gray area to argue here.

Questions to ask a pen testing vendor about their service-to-service and internal API coverage

Ask directly whether the engagement tests internal service-to-service authentication, or only endpoints reachable from outside the network. A vendor who can't answer that specifically is scoping the perimeter and calling it the whole system, and that distinction is the one that actually matters when the report lands on an auditor's desk.

Ask what access the team needs going in: source code, infrastructure-as-code, cloud configs. A blackbox-only engagement has no way of catching a mesh misconfiguration, a JWT bypass buried in internal logic, or a hardcoded secret sitting in a build artifact. If the vendor doesn't ask for that access up front, they can't find those things, and no amount of experience makes up for not looking in the right place.

Ask what portion of the work is manual versus automated. Push for specifics rather than a percentage pulled from a sales deck. Vendors leaning heavily on scanners tend to talk about tool names, Nessus, Qualys, Burp Suite's automated scan modules, rather than describing an actual methodology, and that tendency is worth catching early. Behavior-based abuse testing, the kind that catches logic flaws rather than known signatures, accounted for 61% of API attacks in 2025, according to breach data analysis. That category needs a person doing the thinking, since a scanner running a signature list on autopilot cannot catch behavior-based abuse.

Asking exactly who runs the engagement, by name, and what their background is reveals a great deal. A vendor who answers with a team roster and specific certifications is telling you something different than one who answers with a brand name and a glossy deck. Pick the vendor who can name the person and describe what that person actually does on day one of the engagement. That difference tends to be the whole story.