API Security in Microservices

At a Vietnamese e-commerce platform I worked with last year, they had perfectly valid mTLS certificates, but a compromise of their inventory service meant an attacker could query the payment service's API with those certificates and potentially access transaction data. The authentication was solid. The authorization was nonexistent.

The fix? Implement scope-based access control for your APIs. Use JWT tokens with specific claims that indicate what resources a service can access. Something like:

{ "service": "inventory-service", "scopes": ["products:read", "products:write"], "exp": 1234567890 }

Not every service needs every scope. Inventory doesn't need payment scopes. Period.

Rate Limiting: The Unglamorous Essential

Nobody gets excited about rate limiting. It's not a cool technology. But it's one of the most effective defenses against both accidental and malicious API abuse.

I've seen companies take down their own services because they didn't rate limit internal APIs. One service gets a bug, starts hammering another service in an infinite loop, and suddenly your entire platform is on its knees. No external attacker needed.

Implementation matters here. A naive approach—counting requests in memory on a single server—falls apart when you have multiple instances. You need distributed rate limiting. Redis is the standard. Look at libraries like node-rate-limiter-flexible for Node, go-rate for Go, or slowhttptest for testing your rate limits.

And here's the thing most people miss: rate limit differently for different endpoints. Your login endpoint should be hammered with restrictions (5 attempts per minute per IP). Your read endpoints can be more generous (1000 requests per minute). Authentication attempts are way more valuable to an attacker than regular reads.

The Versioning Problem

Backwards compatibility sounds good until it becomes a security nightmare.

When you version your APIs (v1, v2, v3), you're often maintaining multiple code paths. And if you're not careful, old versions inherit new security features—or old vulnerabilities persist in new versions. I worked at a company where we patched a critical SQL injection vulnerability in our v3 API, but v2 was still live and vulnerable. Nobody was using v2. But it was still running.

The best teams I've seen deprecate aggressively and maintain security across all active versions simultaneously. But they also set explicit sunset dates. v2 runs until Q3 2026, then it dies. Full stop. No exceptions. This is actually easier for security than trying to maintain perfect feature parity across versions.

Secrets Management Is Non-Negotiable

I shouldn't need to say this in 2026, but apparently I do: stop putting secrets in environment variables in your containers. Yes, they're better than hardcoding. But they're far from best practice.

Use a proper secrets manager. Vault, AWS Secrets Manager, Google Secret Manager—doesn't matter which one. What matters is: - Secrets are encrypted at rest - Audit logs show who accessed what, when - Secrets rotate automatically - Services authenticate to the secrets manager, not the other way around

The fintech startup I mentioned? They were storing API keys in .env files. In their Git repository. In a private repository, but still. That's how the junior dev found the user API endpoint—by accident, while browsing the codebase.

Zero Trust, But Keep It Practical

"Zero Trust" gets thrown around a lot. It means verifying every request, every time, assuming nothing is trustworthy. Which sounds great until you realize that strict zero trust can absolutely wreck your latency.

The pragmatic approach is layered zero trust. You verify service identity once, then you verify what that service is allowed to do through authorization checks. You cache non-sensitive verification results for a few seconds. You use cryptographic signing for inter-service communication so you can verify integrity without hitting an auth service every millisecond.

At one Vietnamese logistics company, moving to strict zero trust actually *improved* their latency because it let them remove the load they had on their old monolithic authorization service. The key was implementing it thoughtfully, not dogmatically.

The Real Cost of Ignoring This

It's not just about data breaches. It's about compliance, SLAs, and your ability to sleep at night.

If you're in fintech, healthcare, or e-commerce, regulations like PCI-DSS, HIPAA, or Vietnamese e-commerce laws require you to demonstrate API security. "We didn't think about it" is not a defense. It's a liability.

And your customers notice. When a breach happens—not if, *when*—they leave. The reputational damage is often worse than the direct cost.

Making It Manageable

The key is starting somewhere and being consistent. You don't need everything perfect on day one. Pick one thing: maybe implement mTLS first. Then add JWT-based authorization. Then rate limiting. Then secrets management. Build it gradually, but build it intentionally.

This is exactly the kind of work that's easy to defer because the failures are invisible until they aren't. But the companies that get it right—that treat API security as a core architectural concern, not an afterthought—don't panic at 3 AM.

And they sleep better.

If you're building microservices at scale, especially in the Vietnamese market where API-first architecture is becoming the norm, getting the security foundation right from the start pays dividends. We work with teams at Idflow Technology to help them architect secure, scalable APIs, and the projects that invest in security early consistently outperform those that bolt it on later.