In most production systems, yes. gRPC reflection lets a client ask a server which services, methods and message types it offers. That is useful for debugging and gives an attacker a ready made map. OWASP's gRPC guidance says to disable it in production, so keep it for development and test environments.
What reflection is
gRPC messages use Protocol Buffers, a compact binary format. The gRPC project explains that to call a server by hand you would need to know the services it exposes and the definitions of every request and response message. The reflection protocol lets tools automate that discovery so it becomes invisible. Tools such as grpcurl use it to list services and call methods without a local copy of the definitions.
Reflection is not automatically enabled. The gRPC documentation says the server author must add a reflection service, and the call differs by language, sometimes through a separate package.
Why it matters for security
Without reflection, an attacker needs the .proto files or has to reverse engineer traffic. With it, they can list every service and read every message layout in seconds. OWASP's gRPC security cheat sheet puts it directly: reflection is valuable for development and debugging, but the same capability gives attackers detailed information about your API surface, making it easier to craft targeted attacks.
Hiding the map does not make unauthenticated methods safe. Treat it as a way to remove free reconnaissance, not as authentication.
Check a live server
You can test your own endpoints with grpcurl, the tool OWASP itself uses in its testing examples:
grpcurl -plaintext localhost:50051 list
For a TLS endpoint, omit the plaintext flag. If the command lists your services, reflection is on. If it returns an error that the server does not support the reflection API, it is off.
Steps
- Find where your server registers reflection. Search the code for the reflection registration call in your language.
- Make it conditional on environment, for example register it only when the environment is not production, as OWASP's example does.
- Deploy, then run the list command against production from a network position an outside caller would have.
- Run the same check against staging if staging is internet reachable.
- If an internal tool needs reflection in production, restrict it: expose it on an internal listener or behind authentication, and do not publish that port.
- Add a check to CI or to a scheduled job so a future change does not turn it on again.
When you might keep it
| Situation | Suggested approach |
|---|---|
| Public API for outside developers | Publish .proto files instead of reflection |
| Internal service, private network, mTLS | Keep for developers only with access control |
| Production serving consumers | Disable |
| Local and test environments | Enable freely |
Publishing definition files is a deliberate choice you control, versioned and reviewed. Reflection exposes whatever is compiled into the running binary, including methods you never meant to advertise.
What it does not replace
Disabling reflection does not replace authentication, authorization, input validation or limits on message size. Test every method for access control. A method an attacker has to guess is still a method that must refuse unauthorized calls.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how API discovery and findings are presented, and think about what a reflection listing would add.
Quick check
Is gRPC reflection on by default?
No. The gRPC documentation says the server author has to add a reflection service. Check whether a framework or template added it for you.
Does turning reflection off secure the API?
No. It removes easy discovery only. Every method still needs authentication and authorization.
Safeguard scans your dependencies and SBOMs for known vulnerabilities, including gRPC and protobuf libraries, and shows which are reachable. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
