ASVS 5.0 V12.3.5: Strong Authentication Between Internal Services

ASVS 5.0 V12.3.5 says services talking to each other inside your system must prove who they are with strong authentication, such as TLS client authentication backed by public key infrastructure, using mechanisms that resist replay. For microservices it suggests a service mesh to make certificate management manageable. It is a Level 3 requirement.

Network location is not identity. "It came from inside the cluster" is not a credential.

Why it matters

If any internal endpoint accepts calls from any caller on the network, one compromised workload can impersonate the payment service or read the user service. Bearer secrets copied between services can be replayed by whoever steals them. A certificate bound handshake proves possession of a private key that never travels.

How to implement it

1. Give each workload its own identity and certificate, for example a SPIFFE style ID such as spiffe://prod/ns/payments/sa/api.
2. Issue short lived certificates automatically and rotate them without restarts.
3. Require client certificates on the server side and authorize by identity, not only by successful handshake.

With a mesh, an AuthorizationPolicy pairs authentication with who may call what:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: orders-allow-checkout
  namespace: prod
spec:
  selector:
    matchLabels:
      app: orders
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/prod/sa/checkout"]

TLS handshakes bind each session to fresh key material, which is what gives replay resistance. Avoid replacing it with a static header token.

How to test it

1. Call an internal service from a pod with no valid identity. It must be rejected.
2. Call it from a pod with a valid identity that is not on the allowlist. It must return a denial.
3. Capture a request and replay it from another host. It must fail.
4. Expire a certificate in a test namespace and confirm automatic renewal.

Common mistakes

• Strict mTLS but an authorization policy of allow all.
• Long lived certificates with a manual renewal script.
• Sharing one certificate among all replicas and all services.

Quick check

Sources

• OWASP ASVS