Generally no. A metrics endpoint is meant for your monitoring system, and it can reveal route names, versions, error rates, queue depths and internal labels. Keep it on an internal port, require authentication or network restriction, and review the labels you publish.
What the endpoint contains
The Kubernetes documentation notes that in most cases component metrics are served on a /metrics endpoint of the component's HTTP server, and that with RBAC enabled, reading them requires an identity with a ClusterRole that allows get on the /metrics path. In other words, Kubernetes itself treats metrics as something to authorize, not publish.
Your own application's metrics deserve the same view. Common client libraries add labels per route, status code, method and sometimes user or tenant. That detail is helpful for operators and just as helpful to someone mapping your system.
What an attacker learns
| Metric content | Why it helps an attacker |
|---|---|
| Route and handler labels | Lists endpoints that may not be documented |
| Version and build info metrics | Matches your stack to known flaws |
| Error and status counters | Shows which paths are fragile or protected |
| Queue and pool sizes | Hints at capacity limits and timing |
| High cardinality labels | Can contain identifiers, emails or tenant names by mistake |
| Process and runtime stats | Reveals language, runtime and memory behavior |
There is also a cost angle. A scrape of a large registry takes CPU and memory, and an open endpoint can be hit repeatedly.
How to lock it down
- Separate port. Serve metrics on a port that your public ingress does not route.
- Network policy. Allow only the monitoring namespace or service to reach it.
- Authentication. Where the platform supports it, require a token or client certificate, as the Kubernetes metrics endpoints do through RBAC.
- Label hygiene. Never use user input as a label value. It is a security risk and a cardinality problem. Do not label by email, account or token.
- Scrub before publishing. Remove or hash identifiers. The OWASP logging guidance on removing or masking sensitive data applies to metrics as well.
- Rate limit external scrapers. If a hosted monitoring service must reach you, give it its own path and allowlist its addresses.
Metrics are part of the observability chain
The Kubernetes security overview asks you to review the whole chain that feeds a dashboard, and to make it resilient and tamper resistant enough to rely on during an incident. A dashboard you cannot trust, or a metrics store anyone can write to, is worse than none, because it gives false confidence. Restrict who can push metrics as well as who can read them.
A one minute test
From an external network, request /metrics on each public hostname. If you receive anything other than a refusal, fix the routing first and review the labels second. Also check that your framework's default metrics route is not enabled by a dependency upgrade.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the API scan and see how an unexpectedly reachable endpoint shows up as a finding.
Quick check
Is /metrics sensitive if it only has numbers?
Often yes. Route names, versions and error counts help map and time attacks, and labels sometimes carry identifiers.
How does Kubernetes protect its own metrics?
The docs say that with RBAC, reading metrics needs an identity allowed to get the /metrics path through a ClusterRole.
Can I put user IDs in metric labels?
Do not. It leaks personal data and creates very high cardinality that can overload your monitoring system.
Where Safeguard fits
Safeguard's asset discovery and dependency scanning help you list the services and libraries that expose default metrics routes and flag known vulnerable versions. Try a free scan.
Sources
- Kubernetes, Metrics For Kubernetes System Components
- Kubernetes, Cloud Native Security and Kubernetes
- OWASP Logging Cheat Sheet
Last reviewed: 19 October 2026.
