How do I secure internal APIs?

Here's how to approach securing internal APIs:

Authentication between services

• Use mTLS (mutual TLS) for service-to-service calls — both sides present certificates, so services only talk to verified identities, not just verified endpoints. This is the standard for internal traffic in a service mesh (Istio, Linkerd). For workload identity, frameworks like SPIFFE/SPIRE issue short-lived, automatically rotated identities to each service, removing the need for long-lived shared secrets.

• Use OAuth 2.0 client-credentials flow with short-lived JWTs where mTLS alone isn't practical — common when services span different trust boundaries (e.g., different clusters, clouds, or vendors).

• Avoid static, long-lived API keys for internal service-to-service auth — they're a common source of breaches when leaked in logs, repos, or config files.

Network segmentation

• Keep internal APIs off the public internet entirely where possible — private subnets, VPC peering, or a service mesh's internal network rather than exposing internal endpoints externally "just in case."
• Use network policies (Kubernetes NetworkPolicy, security groups) to enforce which services can even reach which other services at the network layer, independent of application-level auth — defense in depth.
• Segment by trust zone — e.g., payment/billing services in a more restricted zone than general internal tooling.

Authorization (least privilege)

• Scope tokens/certificates tightly — a service should only be authorized to call the specific endpoints it needs, not everything on the network. Use RBAC or ABAC at the service level so "authenticated" doesn't automatically mean "authorized for everything."

• Regularly audit which services actually call which others, and revoke access that's unused — permission sprawl accumulates quietly.

Gateway/mesh enforcement

• Even for internal-only APIs, put policy enforcement (rate limiting, auth checks) at a gateway or mesh sidecar rather than trusting that "it's internal, so it's safe" — internal networks get compromised too, and this is core to a zero-trust posture. Centralize policy definitions (e.g., via Open Policy Agent/OPA) so authorization rules are consistent and auditable across all services rather than hand-rolled per team.

Secrets management

• Store credentials, certificates, and keys in a dedicated secrets manager (Vault, AWS Secrets Manager, cloud KMS) — never in code, config files, or environment variables checked into version control. Automate secret rotation rather than relying on manual rotation, which tends to slip.

Observability and detection

• Log and trace all internal API calls (with correlation IDs) so unusual access patterns — a service suddenly calling something it never has — are detectable, not invisible because "it's internal." Set up alerting on auth failures and anomalous traffic patterns between services, the same way you would for external-facing APIs.

Zero-trust mindset

• The overarching principle for 2026-era internal API security: don't treat the internal network as inherently trusted. Assume any service or network segment could be compromised, and require every call to be authenticated, authorized, and encrypted — regardless of whether it's "just internal." This is the core shift from older perimeter-based security models (trust everything inside the firewall) to zero-trust architectures (verify every request, everywhere).

Practical baseline stack

mTLS for transport-level service identity (via service mesh).

Short-lived tokens/certs (SPIFFE/SPIRE or OAuth client-credentials) for workload identity.

Network policies restricting which services can reach which.

Centralized authorization policy (OPA or similar) instead of per-service hand-rolled checks.

Secrets in a vault, rotated automatically.

• Full observability — logging, tracing, and alerting — treating internal traffic with the same scrutiny as external.