Intro to Microservices Security

This is the start of a new series on microservices security. In this series, we're going to break down how to actually protect these systems in architecture level.

But before we design a defense for a whole city of services, we need to understand how we used to guard a single apartment — and why that was so much simpler. Because here's the uncomfortable truth that most tutorials skip:

The monolith wasn't secure because we were good at security. It was secure because of its architecture.

When we broke it apart, we achieved flexibility and scalability. But also, we removed the thing that was doing our security for us.

So, let’s go.

Picture a building with one or two doors. In web terms, that's usually just port 80 for HTTP and port 443 for HTTPS.

That's it.

That's the whole entrance.

Because there are so few ways in, your attack surface — the total area an attacker can probe and target — is small. Every request in the entire system goes through the same point, and that choke point is where you enforce your rules.

In engineering terms, we call this centralized policy enforcement. When a request arrives, it hits a single component at the entrance before it touches any business logic.

Depending on your stack, that's a Servlet Filter (Java), an Interceptor, or a piece of Middleware (Express, ASP, Django). Whatever you call it, its job is the same: it's the guard for the entire application.

This guard does all the heavy lifting on the way in. It checks your credentials, verifies your session, and confirms you're allowed to be here.

No active session? The request gets stopped at the door and is challenged to log in. Nothing behind that door has to think about authentication, because nothing unauthenticated ever gets that far.

And of course, in this whole discussion we were assuming that we’ve developed our code securely !!

Once you're past the front door, you've entered what's often called the circle of trust. Inside the building, the Order component needs to talk to the Inventory component to check stock. So how does that call get secured?

It doesn't — and that's the point.

Because both components live inside the same process (say, the same JVM), they talk to each other directly in memory.

This is an in-process call, and it's secure by default for one simple reason: there's no network for an attacker to sit on and eavesdrop. There's no wire to tap, no packets to intercept, no man-in-the-middle to worry about. The conversation happens inside the boundaries of a single running program.

So the internal components trust each other implicitly. Inventory never re-checks your identity, because it assumes that if you made it past the middleware, you're legitimate.

Your identity just... exists, sitting in a shared web session that makes your name, email, and permissions instantly available to every corner of the app.

It's fast. It's simple. It's straightforward. And it works beautifully — right up until the moment those components become separate applications that have to talk to each other over a network.

That's when everything changes.

So if the monolith was this secure and this manageable, why did the entire industry walk away from it?

Two words: scalability and development velocity.

In a monolithic architecture, the whole application is a single unit of deployment. Want to fix one tiny function in the checkout flow? You rebuild and redeploy the entire codebase. Every team is coupled to every other team's release schedule.

Scaling is just as painful. You can scale a monolith vertically (throw more CPU and RAM at the one machine) or horizontally (clone the entire monolith behind a load balancer).

But that's inefficient.

If only your image-processing logic is under load, you're forced to replicate the payment logic, the user logic, and everything else along with it — paying a cost, much more than you need.

Technically, a microservices architecture breaks a single application into a suite of small, independent services.

Each service runs its own process and communicates with the others over the network — typically an HTTP-based API or an asynchronous message broker.

Instead of one big binary, you get a distributed system of components:

one service for Identity, one for Payments, another for Inventory. Each one owns its part of the domain.

This gives you three advantages that matter:

Here's the part nobody wants to talk about.

The moment you split the monolith, every one of those cozy in-process calls becomes a remote procedure call (RPC) or a REST request traveling over a network.

And this network is hostile territory. Every time one service calls another, that data crosses a network where it can be intercepted, tampered with, or accessed by something that shouldn't have it.

By pivoting to microservices, we gained a lot of flexibility. But at the same time, we destroyed the internal trust model that was silently protecting us.

The guard at the front door is still there — but now there are a hundred back doors, and none of them have a guard.

So let’s talk about the core security issues of microservices that we are going to cover and solve in this series.

Breaking a monolith apart fixes your scaling problems and creates a fresh set of security problems that you should understand.

1. Broader attack surface.
In a monolith, internal communication happens privately, inside the memory of one process. In microservices, every service-to-service call is a remote call over the network, and every service exposes its own entry points. You've gone from one front door guard to hundreds. And your system is only as strong as its weakest service — one insecure, forgotten internal API is all an attacker needs.

2. Screening latency.
The monolith checked your credentials once, at the entrance. In microservices, every service has to perform its own independent security screening. If each of them calls out to a remote Security Token Service (STS) to validate every incoming request, you've just added a network round-trip to every internal call, and your performance drops massively. (Spoiler: this is a big part of why self-contained, cryptographically signed tokens like JWTs exist. A service can validate the token locally and skip the call to the STS entirely.)

3. Bootstrapping trust.
If you run 1,000 services, all 1,000 need a way to prove who they are to each other. That usually means managing thousands of certificates and key pairs, and rotating and revoking them on a schedule. Without automation, this becomes a mess. This is exactly the problem that projects like SPIFFE/SPIRE and service meshes were built to automate: issuing, rotating, and revoking service identities so no human has to handle a certificate store.

4. The difficulty of tracing requests.
When something breaks in a monolith, your stack trace is all in one place. In microservices, a single user request might hop through ten services before it fails. Without distributed tracing like Jaeger, Zipkin, or the OpenTelemetry standard, you are effectively blind to how data actually moves through your system, which makes both debugging and incident forensics brutal.

5. User context sharing.
Monoliths share a web session. Microservices share nothing. You have to explicitly carry the user's identity — their context — from Service A to Service B to Service C. And you have to do it in a way that can't be forged in transit, which is why you reach for a signed JWT rather than a header anyone on the network could rewrite.

6. Polyglot architecture and expertise.
The same freedom that lets each team pick Go, Java, or Python means you can't lean on one central security team that understands one stack. Every team now needs its own security expertise for the specific vulnerabilities of its own language, framework, and dependencies. Security stops being a department and becomes a shared responsibility.

None of these is unsolvable. But to solve them, we have to go back to the fundamentals of security and apply them to this new, distributed world.

Before we reach for tools, we need the basic principles of security. In microservices, these six are what everything else sits on.

1. Authentication — Who are you?
This is about identifying the caller, whether it's a human, a system, or a system acting on behalf of a human. For humans, we use passwords and MFA. For system-to-system calls, we lean on certificates or JWTs. And when a web app needs to call a microservice for a user, OAuth 2.0 is the industry standard for delegating that access safely.

2. Integrity — Was the data changed?
We need to guarantee that data isn't tampered with in between. Digital signatures let us detect changes, and TLS (HTTPS) protects data in transit. This applies to your observability data too: if an attacker can quietly edit your audit trail in Jaeger or Zipkin, you'll never know they were in your system.

3. Non-repudiation — Can you prove it?
This ensures a service can't later deny an action it took. If a microservice signs a transaction with its private key, it is technically (and often legally) accountable for that action. Keep signed records with timestamps, and you have real accountability there.

4. Confidentiality — Who else can see this?
Only the intended recipient should be able to read the data. That means encryption at rest (your databases) and in transit (TLS). But there's a point here worth pausing on;

Two different flavors of TLS:

The mistake is assuming "we use TLS" means "no one in the middle can read this."

Bridging quietly breaks that assumption.

5. Availability — Is the system up?
Security isn't only about keeping attackers out — it's about keeping legitimate users in. The good news in microservices: if one service crashes, the whole system doesn't have to go down with it. The bad news: you still have to defend against DDoS and abuse, which means rate-limiting and throttling at your network perimeter before that traffic ever reaches your services.

6. Authorization — What are you allowed to do?
Once we know who you are, we decide what you can touch. In microservices, we typically split this into two layers:

Understanding these six principles is the theory. The natural next question is where we actually enforce them.

For most modern systems, it starts at the very edge of the network.

We don't leave our microservices hanging out on the public internet, exposed one by one. Instead, we put an API Gateway in front of the whole system. Think of it as the front door for your entire architecture, the guard we lost when we tore down the monolith, rebuilt for a distributed world.

The gateway acts as a centralized policy enforcement point. Its job is to handle the non-functional concerns — security, throttling, logging — so your microservices can stay focused purely on business logic.

Here's what it does, mapped to the principles above.

When a request hits the gateway, step one is identifying the caller. You'll usually see two methods:

(We'll go deep on both mTLS and OAuth 2.0 in their own dedicated posts — they each deserve one.)

The gateway also handles coarse-grained authorization — the high-level rules.

Is this user allowed to touch the Payments API at all?

If they fail that check, the request is rejected there and never reaches your internal network.

The fine-grained questions — can this specific user edit that specific invoice? — We deliberately leave it to the individual services, because only the service that owns the invoice has the context to answer it correctly.

Once the gateway is satisfied, it has to hand the request off to an upstream microservice. But now we hit challenge #5 from earlier.

How does that service know who the user is?

We could just put the identity in a plain HTTP header — but headers are trivial to spoof. Anything sitting on the network could rewrite X-User-Id or … and walk right in.

The right answer is a signed JWT. The gateway (or an internal Security Token Service) generates a cryptographically signed token containing the user's identity and claims. Because it's signed, any upstream service can verify it locally and instantly — checking the signature against a trusted key — and know exactly who it's talking to without re-authenticating the user and without a call back to the STS.

Read that last part again, because it's the whole trick: the signed token is simultaneously how we share user context (challenge #5) and how we avoid screening latency (challenge #2). One mechanism, two problems solved. That's not a coincidence — it's the core design pattern this entire series is built on.

Let's recap, because it matters more than any single term:

Thanks for reading.
Stay tuned for the next parts.