Rule Information
Tags
gosecuritygrpctlsinsecurecleartextmicroservicesCWE-300CWE-319OWASP-A02
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset golang/GO-NET-002 --project .1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Cross-file analysis: 3 files
About This Rule
Understanding the vulnerability and how it is detected
gRPC (google.golang.org/grpc) is the dominant RPC framework for Go microservices. By default, gRPC requires transport security. Developers explicitly opt out using `grpc.WithInsecure()` (deprecated in gRPC-Go v1.35+, March 2021) or the replacement `grpc.WithNoTLS()` (insecure.NewCredentials()) — both disable TLS entirely.
Without TLS, all gRPC communication travels unencrypted: - Authentication tokens in gRPC metadata headers (Bearer tokens, API keys) - Method names and service identifiers - Request and response protobuf payloads - Streaming data (client/server/bidirectional)
**History of WithInsecure() deprecation**: grpc-go v1.35 (released March 2021) deprecated `grpc.WithInsecure()` and replaced it with `insecure.NewCredentials()` from `google.golang.org/grpc/credentials/insecure`. The rename was intentional — the `insecure` package name makes the security choice explicit. However, both the old and new forms are equally insecure for production traffic.
**Microservice context**: gRPC is primarily used for service-to-service communication. Many teams assume internal network communication doesn't need TLS because it's "inside the cluster." However: - Kubernetes cluster-internal traffic is not encrypted by default - Container-to-container traffic on the same node bypasses network policies - Service mesh (Istio, Linkerd) can provide mTLS but is not universally deployed - Compromised pods can intercept unencrypted gRPC traffic
**Mutual TLS (mTLS)** is the recommended pattern for microservices: both client and server present certificates, enabling bidirectional authentication. This prevents a compromised service from accepting connections from unauthorized clients.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Auth Token Interception
gRPC metadata headers carrying Bearer tokens, API keys, or service account credentials are transmitted in cleartext. Any network observer on the path can capture these credentials and replay them against the target service.
2
Microservice Impersonation
Without TLS certificate verification, a compromised service can MITM gRPC calls between services, reading all payloads and injecting crafted responses.
3
Data Exfiltration
gRPC streaming calls (often used for bulk data transfer) send their entire payload in plaintext. An observer can capture complete request/response payloads without any decryption.
4
Pod-to-Pod Traffic Exposure
In Kubernetes, all pods on the same node share the same network namespace. A compromised pod can use tcpdump to capture unencrypted gRPC traffic between other pods on the same node, bypassing Kubernetes NetworkPolicy.
How to Fix
Recommended remediation steps
- 1Use grpc.WithTransportCredentials(credentials.NewTLS(tlsConfig)) for all production connections.
- 2For microservice mesh environments, prefer mutual TLS (mTLS) for bidirectional authentication.
- 3Set tls.Config.MinVersion to tls.VersionTLS12 or tls.VersionTLS13.
- 4grpc.WithInsecure()/WithNoTLS() is only acceptable for localhost-only connections.
- 5Consider Istio or Linkerd for cluster-wide mTLS without per-service configuration.
- 6Use grpc.DialContext with context-based connection management for production.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
Detects calls to grpc.WithInsecure() and usage of insecure.NewCredentials() from google.golang.org/grpc/credentials/insecure. Both forms disable TLS.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
OWASP Top 10
A02:2021 — Cryptographic Failures; A07:2021 — Authentication Failures
PCI DSS v4.0
Requirement 4.2.1 — Strong cryptography for transmission of cardholder data.
Applies to all service-to-service communication handling cardholder data.
NIST SP 800-53 Rev 5
SC-8 — Transmission Confidentiality and Integrity
CWE Top 25 (2024)
CWE-319 — Cleartext Transmission of Sensitive Information
References
External resources and documentation
Similar Rules
Explore related security rules for Go
Frequently Asked Questions
Common questions about gRPC Client Without TLS
gRPC (google.golang.org/grpc) is the dominant RPC framework for Go microservices.
By default, gRPC requires transport security. Developers explicitly opt out using
`grpc.WithInsecure()` (deprecated in gRPC-Go v1.35+, March 2021) or the replacement
`grpc.WithNoTLS()` (insecure.NewCredentials()) — both disable TLS entirely.
Without TLS, all gRPC communication travels unencrypted:
- Authentication tokens in gRPC metadata headers (Bearer tokens, API keys)
- Method names and service identifiers
- Request and response protobuf payloads
- Streaming data (client/server/bidirectional)
**History of WithInsecure() deprecation**: grpc-go v1.35 (released March 2021)
deprecated `grpc.WithInsecure()` and replaced it with `insecure.NewCredentials()`
from `google.golang.org/grpc/credentials/insecure`. The rename was intentional —
the `insecure` package name makes the security choice explicit. However, both the old
and new forms are equally insecure for production traffic.
**Microservice context**: gRPC is primarily used for service-to-service communication.
Many teams assume internal network communication doesn't need TLS because it's "inside
the cluster." However:
- Kubernetes cluster-internal traffic is not encrypted by default
- Container-to-container traffic on the same node bypasses network policies
- Service mesh (Istio, Linkerd) can provide mTLS but is not universally deployed
- Compromised pods can intercept unencrypted gRPC traffic
**Mutual TLS (mTLS)** is the recommended pattern for microservices: both client and
server present certificates, enabling bidirectional authentication. This prevents
a compromised service from accepting connections from unauthorized clients.
Use Code Pathfinder to scan your codebase: pathfinder scan --ruleset golang/GO-NET-002 --project .
This vulnerability is rated as HIGH severity.
Yes! Code Pathfinder allows you to customize rules. Modify detection patterns, adjust severity levels, add custom sanitizers, and configure the rule to fit your organization's security policies.
New feature
Get these findings posted directly on your GitHub pull requests
The gRPC Client Without TLS rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.