Modern web applications increasingly rely on microservice architectures. In industries like banking and fintech, it’s common to see dozens, or sometimes hundreds, of microservices communicating with each other behind a single user-facing application. From a development and DevOps perspective, microservices provide flexibility, scalability, and faster deployment cycles. But from a security researcher’s perspective, they also introduce entirely new attack surfaces. More services mean more communication paths, internal APIs, tokens, and opportunities for misconfiguration.
While testing several programs on Synack, I encountered multiple vulnerabilities that stemmed directly from microservice communication patterns. In this article, I’ll walk through three real-world attack vectors that demonstrate how microservices can introduce unexpected security weaknesses.
1. SSRF to Other Internal Subdomains PDF Microservice
During one assessment, I noticed that the application allowed users to download their monthly transaction history as a PDF document. Naturally, I decided to inspect how this feature worked.
When I analyzed the request used to download the PDF, I noticed something interesting. The application was using a URL parameter to fetch the document from an internal microservice. The request structure looked like this:
http://extractinternal.redacted.corp/path/endpoint/123456789_XIM00.PDF
Instead of directly serving the document, the application was acting as a proxy to another internal service responsible for generating or retrieving the PDF. At this point, I immediately suspected a potential Server-Side Request Forgery (SSRF) scenario.
I began testing typical SSRF targets such as:
- 127.0.0.1
- 10.x.x.x
- 192.168.x.x
- AWS metadata endpoints
However, those requests returned errors because the application expected a valid PDF response.
This actually provided an important clue: the application was likely only accepting responses that looked like valid PDFs.
Discovering Other Internal PDF Services
Instead of targeting generic internal hosts, I focused on other internal PDF microservices. By modifying the path within the same internal service, I was able to access PDF files belonging to other users. For example:
http://extractinternal.redacted.corp/path/endpoint/123456789_XIM00.PDF
By simply changing the identifier in the path, the server returned another user’s PDF document.
This demonstrated that the backend microservice did not properly validate ownership of the requested document. I then expanded the attack by fuzzing internal subdomains. Eventually I discovered additional internal PDF services such as:
http://extractinternal_another_subdomain.redacted.corp
Using the same SSRF primitive, I was able to access documents stored in multiple internal services. This showed how a seemingly small SSRF issue could lead to cross-service data exposure within a microservice architecture.
2. Token Scope Misconfiguration Between Microservices
Another interesting vulnerability I encountered involved token scope misconfiguration across microservices. Modern applications often bundle multiple services into a single platform. For example, a banking application might include:
- financial services
- e-commerce functionality
- loyalty programs
- food delivery integrations
Each service may rely on its own authentication mechanisms, but they often share tokens across services. If token scopes are not properly defined, this can create dangerous privilege escalation and account takeover scenarios.
In one case I tested, a banking application included an integrated e-commerce platform. When a user attempted to access the e-commerce service, the system generated a new JWT token for authentication.
However, the authentication logic contained a flaw. Instead of validating that the authorization code belonged to the requesting user, the service allowed the client to supply any code value. As a result, it was possible to generate a JWT token for another user simply by modifying the code parameter. Additionally, the token generated in this step is used to create another token at another endpoint for the e-commerce service. Once the token was generated, it could be used to request an access token from the e-commerce microservice.
The root cause was a common microservice security mistake: The downstream service trusted the upstream JWT token without verifying who generated it. This allowed attackers to obtain valid access tokens for other accounts.
3. SSRF via Proxy Routing Between Microservices
The third case demonstrates how microservice communication through proxies can introduce SSRF risks. While reviewing a GDPR consent management page in a banking application, I noticed that clicking a document link redirected the user to a PDF endpoint. The request looked like this:
/api/endpoint/pdf_number.pdf?proxytohost=172.21.69.153&pdf=pdf
This suggested that the application was using an internal proxy to retrieve the document from another service.
This immediately raised a question: What happens if we change the value of proxytohost parameter? If the server used this parameter to determine where to forward requests, it could potentially allow attackers to access internal services. I began testing different internal IP addresses. Eventually I discovered several responsive internal hosts such as:
172.21.69.9
172.21.69.10
172.21.69.153
When sending repeated requests to these internal addresses, the application began returning internal intranet portal content.
At this point it became clear that the application proxy was capable of communicating with multiple internal services within the organization’s network. This effectively allowed external users to pivot into the internal network via the application server.
Final Thoughts
Microservice architectures bring enormous benefits to modern development workflows. However, they also introduce complex trust relationships between services. During security testing, I often see the same recurring patterns:
- Internal services trusting each other too much
- Tokens reused across services without proper scope validation
- Proxy mechanisms forwarding requests without strict controls
- Internal APIs exposed indirectly through public endpoints
Each individual issue may seem small, but in a microservice ecosystem they can quickly combine into serious attack chains. For security teams, this means traditional perimeter-focused testing is no longer enough.
Instead, it is critical to analyze:
- How services communicate
- How tokens are exchanged
- How proxies route internal requests
Because in modern architectures, the most interesting vulnerabilities often appear between services not at the edges of the application.
Thanks for reading. Be sure to follow Synack and the Synack Red Team on LinkedIn for upcoming blogs in this series.
Frequently Asked Questions
What makes microservice architectures particularly risky from a security perspective?
Microservices multiply the number of communication paths, internal APIs, tokens, and configuration points within an application. Each additional service is an additional opportunity for misconfiguration. More critically, services in these architectures often develop implicit trust relationships with one another, meaning a compromise of one service can quickly pivot into others.
How does SSRF manifest differently in a microservice environment compared to a traditional monolithic application?
In a microservice context, SSRF doesn’t just expose a single server—it can expose an entire internal service mesh. In the cases described here, an SSRF primitive in a PDF download feature allowed access to documents across multiple internal subdomains and services, demonstrating cross-service data exposure that would not exist in a monolithic design.
How can token scope misconfigurations lead to account takeover?
When microservices share authentication tokens without properly validating their origin or intended scope, attackers can exploit the trust gap between services. In one case described here, a banking application’s e-commerce integration accepted any authorization code value without verifying it belonged to the requesting user—allowing an attacker to generate a valid JWT for another account entirely.
What makes proxy-based routing between microservices a security concern?
Proxies that accept user-controlled parameters to determine where to forward requests are effectively giving external users a foothold into the internal network. In the third case, a proxytohost parameter allowed an attacker to enumerate live internal IP addresses and retrieve content from internal intranet portals—a textbook internal network pivot via the application layer.
Is traditional perimeter-based security testing sufficient for microservice architectures?
No. The vulnerabilities outlined here all occurred between services, not at the application’s external boundary. Security teams need to analyze how services communicate with each other, how tokens are issued and validated across service boundaries, and how internal proxies route requests—none of which are visible through external perimeter testing alone.
What recurring patterns should security teams prioritize when assessing microservice environments?
The most common weaknesses observed are: internal services trusting one another without strict validation, tokens being reused across services without scope controls, proxy mechanisms that forward requests based on user-supplied input, and internal APIs that are indirectly reachable through public-facing endpoints. Individually these issues may appear minor, but in combination they can form serious attack chains.
About the Author
Mustafa Bilgici is an Application Security Researcher specializing in web application security and penetration testing. He is a member of the Synack Red Team, where he ranks in the top 30 globally and was inducted into the Acropolis program in 2024. He has spoken at DEFCON and Black Hat conferences on secure source code analysis.
