gRPC Security: Breaking the High-Performance RPC Protocol

Table of contents

👋 Introduction

Hey everyone, and happy new year!

Hope you all had a good start to 2026. A few months back, I had an assessment that involved testing a distributed system built with gRPC. I’d seen gRPC mentioned in microservice architectures before, but had never really worked with it hands-on.

Here’s what I learned. The client had multiple services communicating via gRPC. Traditional web app testing techniques didn’t apply. Burp couldn’t properly intercept the traffic out of the box. Directory fuzzing was useless. The service didn’t return HTML or JSON, just binary data I couldn’t make sense of at first.

I knew gRPC used Protocol Buffers (protobuf) for serialization and HTTP/2 for transport. But understanding the theory and actually working with it are two different things. I spent time figuring out basic enumeration. How do you discover available methods? How do you call them? What does authentication look like in gRPC?

After going through the learning curve and working with the tools, I got a much better understanding of how gRPC works from a security perspective. That’s why I wanted to share what I learned with you. gRPC is everywhere in modern backend infrastructure. Kubernetes uses it. Microservices love it. Cloud-native apps depend on it. And security testing for gRPC requires a different approach than REST APIs.

In this issue, I’ll cover the basics of what gRPC is and why it matters for security testing. We’ll go through service discovery and enumeration techniques. You’ll learn how to intercept and work with gRPC traffic, common security issues to look for, and the tools that make testing gRPC more approachable. We’ll wrap up with hands-on labs you can use to practice.

If you’ve been curious about gRPC but found it intimidating, this is your starting point.

Let’s dive into gRPC 👇

🔍 What is gRPC and Why It Matters

gRPC is a Remote Procedure Call (RPC) framework developed by Google. Think of it as a way for services to call functions on other services as if they were local, except those services might be running on different machines, in different data centers, across the internet.

Why companies use gRPC:

It’s fast. Protocol Buffers (protobuf) serialize data more efficiently than JSON. Binary encoding means smaller payloads and faster parsing. HTTP/2 multiplexing allows multiple requests over a single connection without blocking.

It’s strongly typed. You define your API using .proto files (protobuf schemas). These schemas specify exactly what data types each method accepts and returns. No guessing, no surprises. Client and server code gets generated automatically from these schemas.

It supports bidirectional streaming. Not just request-response like REST. You can have server streaming (one request, multiple responses), client streaming (multiple requests, one response), or full bidirectional streaming. Perfect for real-time data, chat systems, or monitoring dashboards.

Why this matters for pentesters:

Traditional web app tools don’t work out of the box. Burp Suite sees gRPC traffic as binary HTTP/2 data. You can’t just click “Intercept” and read the request like you would with JSON. Directory brute-forcing doesn’t help because gRPC doesn’t use URL paths the way REST does.

Authentication and authorization work differently. Many gRPC services use metadata (HTTP/2 headers) for auth tokens instead of cookies or Authorization headers. Access controls are often method-level, not route-level. Misconfigurations are common.

The attack surface is different. You’re looking at reflection endpoints, metadata manipulation, protobuf deserialization issues, and method-level access controls. Error messages leak service structure. Streaming endpoints can be abused for DoS. And many developers assume gRPC is “internal only” so they skip security controls.

gRPC Architecture Basics:

Client                          Server
  |                               |
  | 1. Define API (.proto file)   |
  |------------------------------>|
  |                               |
  | 2. Generate code (protoc)     |
  |                               |
  | 3. Call remote method         |
  |------------------------------>|
  |   (binary protobuf over HTTP/2)
  |                               |
  | 4. Response (binary protobuf) |
  |<------------------------------|

Key components:

Protocol Buffers (.proto files): Define the API contract. Specify services, methods (RPCs), and message types.

HTTP/2: Transport layer. All gRPC uses HTTP/2, which means multiplexing, header compression, and binary framing.

Metadata: Key-value pairs sent with requests (like HTTP headers). Used for authentication, tracing, authorization.

Service Definition: Methods exposed by the server. Each method has input and output message types.

🕵️ Enumerating gRPC Services

First problem: how do you even know what methods are available?

With REST APIs, you might have OpenAPI/Swagger docs, or you can brute-force paths. With gRPC, there’s no standard documentation endpoint. But there’s something better: reflection.

gRPC Reflection

Many gRPC servers enable reflection for development and debugging. Reflection is an API that lets you query the server for available services and methods. It’s like asking the server “what can you do?” and getting a full list back.

Check if reflection is enabled:

# Using grpcurl (we'll install this in a moment)
grpcurl -plaintext target.com:50051 list

If reflection is enabled, you’ll see output like:

grpc.health.v1.Health
grpc.reflection.v1alpha.ServerReflection
myapp.UserService
myapp.PaymentService

List methods for a service:

grpcurl -plaintext target.com:50051 list myapp.UserService

Output:

myapp.UserService.GetUser
myapp.UserService.CreateUser
myapp.UserService.DeleteUser
myapp.UserService.UpdateUser

Describe a method:

grpcurl -plaintext target.com:50051 describe myapp.UserService.GetUser

Output shows the protobuf definition:

myapp.UserService.GetUser is a method:
rpc GetUser ( .myapp.GetUserRequest ) returns ( .myapp.User );

Describe message types:

grpcurl -plaintext target.com:50051 describe myapp.GetUserRequest

Output:

myapp.GetUserRequest is a message:
message GetUserRequest {
  int32 user_id = 1;
}

Now you know exactly what data to send.

When Reflection is Disabled

If reflection is off, you need the .proto files to know what methods exist.

Where to find .proto files:

GitHub/GitLab: Search the client’s public repos for .proto files. Many companies accidentally commit these.

Client-side code: Mobile apps, web clients, or SDK packages often bundle .proto files or generated code.

Documentation: Internal wikis, API docs, or developer portals sometimes leak protobuf definitions.

Decompiled clients: If you have a compiled client (Go binary, Java JAR), decompile it and extract embedded protobuf schemas.

Guessing/Fuzzing: If you know common method names (GetUser, ListItems, CreateOrder), you can try calling them. gRPC error messages will tell you if the method exists but you sent wrong data.

Example of extracting from a Go binary:

# Go embeds protobuf descriptors in binaries
strings client_binary | grep -i "\.proto"

# Use protoc --decode to reverse-engineer messages from captured traffic

Port and Service Discovery

gRPC commonly runs on:

• 50051 (default gRPC port)
• 443 (HTTPS, especially in production)
• 8080, 8443, 9090 (common custom ports)

Scan for gRPC services:

# Nmap with http2 detection
nmap -p 50051,443,8080,8443,9090 -sV --script http2-detect target.com

# Check TLS/non-TLS
grpcurl -plaintext target.com:50051 list  # Non-TLS
grpcurl target.com:443 list                # TLS

🔓 Common gRPC Vulnerabilities

1. Insecure Reflection in Production

Reflection should be disabled in production environments. It exposes your entire API surface. However, developers sometimes forget to turn it off.

Impact: Full service enumeration becomes possible. Anyone can discover every method, every parameter, every message type. Use the enumeration techniques covered earlier to map the attack surface.

2. Missing Authentication/Authorization

Some methods require authentication, others don’t. Developers sometimes assume gRPC is “internal only” and skip authentication entirely.

Testing strategy: Try calling methods without metadata (no auth token). If successful, test with common metadata patterns like Authorization: Bearer <token> or custom headers like x-api-key. Many services inconsistently apply authentication across different methods.

3. Insecure Direct Object Reference (IDOR)

Just like REST APIs, gRPC services can have IDOR vulnerabilities if authorization checks are missing at the method level. Test by accessing your own resources first, then try accessing other users’ data by modifying ID parameters.

4. Metadata Injection

Metadata is like HTTP headers. If the server trusts metadata values without validation, you can inject malicious data.

Common injection points: SQL injection in custom metadata fields (e.g., x-user-role: admin' OR '1'='1), command injection in tracing headers (e.g., x-trace-id: $(whoami)), and log injection in debugging metadata. Test any metadata field that gets processed server-side.

5. Protobuf Deserialization Issues

Protocol Buffers are generally safe, but misuse can lead to issues. Test with extreme values: maximum integers (9223372036854775807), negative numbers (-1), and out-of-range values. Schema type definitions don’t guarantee server-side validation.

6. Denial of Service (DoS)

gRPC’s bidirectional streaming can be abused by sending massive data streams. Also test with extremely large protobuf messages to trigger memory exhaustion. Use load testing tools like ghz (covered later) for systematic DoS testing.

7. Information Disclosure

gRPC error messages are verbose. Trigger errors with invalid input to check for stack traces (file paths, library versions), SQL errors (table names, columns), and internal service names.

🔨 Intercepting and Manipulating gRPC Traffic

Using Burp Suite

Burp Suite supports HTTP/2, but gRPC traffic is binary. You need to decode it.

Method 1: Burp Extensions

Install the gRPC Web Developer Tools extension from BApp Store. It decodes protobuf messages automatically if you provide the .proto files.

Method 2: Manual Decoding

Capture HTTP/2 traffic in Burp. Use protoc to decode the binary data manually.

# Save the binary request body to a file
cat request.bin | protoc --decode=myapp.GetUserRequest user.proto

Using mitmproxy

mitmproxy has better HTTP/2 support than Burp for gRPC.

Setup:

# Install mitmproxy
pip install mitmproxy

# Start proxy
mitmproxy -p 8080 --mode http2

Configure client to use proxy:

# Set environment variables
export GRPC_PROXY=http://localhost:8080
export HTTP_PROXY=http://localhost:8080
export HTTPS_PROXY=http://localhost:8080

# Or use grpcurl with proxy
grpcurl -insecure -proxy http://localhost:8080 target.com:443 list

Using grpcui

For a more visual approach, grpcui provides a browser-based interface for testing gRPC services. See the Essential Tools section below for installation and usage.

🛠️ Essential Tools

grpcurl: The curl of gRPC. Essential command-line tool for enumeration and testing. Install: go install github.com/fullstorydev/grpcurl/cmd/grpcurl@latest

grpcui: Web-based UI for interactive gRPC testing. Much easier than crafting JSON manually. Install: go install github.com/fullstorydev/grpcui/cmd/grpcui@latest

ghz: Load testing tool for gRPC. Perfect for DoS testing and benchmarking. Install: go install github.com/bojand/ghz/cmd/ghz@latest

Postman: Now supports gRPC natively. Import .proto files and test with a familiar GUI.

Burp Suite Extensions: gRPC Web Developer Tools and Protobuf Decoder for intercepting and decoding traffic.

protoc: Protocol Buffer compiler for encoding/decoding messages manually. Install via brew install protobuf (macOS) or apt-get install protobuf-compiler (Linux).

grpc_cli: Official Google tool, similar to grpcurl. Requires gRPC C++ installation.

🧪 Labs and Practice

Honestly, there aren’t many dedicated gRPC security labs out there yet. The technology is still relatively niche in the security training space. Here’s what I found useful:

gRPC Goat

Intentionally vulnerable gRPC application for learning security testing.

Repository: https://github.com/rootxjs/grpc-goat

Covers:

• Insecure reflection
• Missing authentication
• IDOR vulnerabilities
• Metadata injection
• Multiple CTF-style challenges

This is your best bet for hands-on gRPC security practice. The challenges are well-designed and cover real-world vulnerabilities.

Build Your Own

Since there aren’t many public labs, building your own vulnerable gRPC service is valuable practice. Start with a simple Python service that has intentional vulnerabilities: no authentication, reflection enabled, and IDOR flaws. Use the gRPC Python quickstart guide and introduce vulnerabilities like missing metadata validation, unrestricted method access, and exposed reflection endpoints. Test with grpcurl to verify the vulnerabilities are exploitable.

🎯 Key Takeaways

gRPC is fundamentally different from REST. Binary encoding, HTTP/2 transport, and protobuf schemas mean you need different approaches for testing. Your usual tools and techniques need adjustment.

Reflection makes enumeration straightforward. When enabled, you can discover the full API surface instantly: services, methods, message types, everything. This is why reflection should be disabled in production, though it’s sometimes left on accidentally.

Authentication and authorization patterns differ from traditional web apps. Many services assume gRPC is internal-only, which can lead to missing authentication controls. Always check method-level access controls, not just service-level ones.

Traditional security concepts still apply. IDOR, injection attacks via metadata, and DoS through streaming abuse are all possible. The transport layer is different, but the underlying security principles remain the same.

Tools make the difference. grpcurl and grpcui transform what would be tedious binary manipulation into manageable testing. Learning these tools is essential for working effectively with gRPC.

Error messages can reveal system information. gRPC error responses tend to be verbose, sometimes including stack traces, database errors, or internal service names. This information is valuable for understanding the system architecture.

.proto files are valuable resources. If you can find the protobuf schemas (from GitHub, client apps, or documentation), you have the complete API specification. This makes testing much more systematic and thorough.

📚 Further Reading

• gRPC Official Documentation: Complete reference for gRPC concepts and implementation
• grpcurl GitHub: Essential command-line tool for gRPC testing
• grpcui GitHub: Web-based gRPC testing interface
• OWASP API Security Top 10: Many principles apply to gRPC
• Protocol Buffers Documentation: Understanding protobuf is crucial for gRPC testing
• Awesome gRPC Security: Curated list of gRPC security resources
• gRPC Security Guide by Trail of Bits: Production security best practices
• HackTricks: General pentesting techniques and resources

---

That’s it for this week!

gRPC is becoming standard in microservice architectures. Kubernetes, Istio, Envoy, and countless backend services use it for inter-service communication. Understanding how to work with gRPC is increasingly important for security testing.

The learning curve is real. Binary protocols and protobuf schemas are different from JSON and REST. But once you understand the fundamentals and get comfortable with the tools, working with gRPC becomes much more approachable.

Start with grpcurl to understand the basics. Practice on lab environments. Learn how reflection works. Understand metadata patterns. Build your knowledge step by step.

Thanks for reading, and keep learning in 2026 🚀

— Ruben

Other Issues

LDAP Injection: Breaking Active Directory Authentication & Enumeration

Previous Issue

Server-Side Template Injection (SSTI): Breaking Out of Templates

Next Issue