Home / Knowledge hub / gRPC
Knowledge hub
gRPC
A fast API style between services that sends compact binary messages over HTTP/2.
What it means
gRPC is a framework for services to call each other's functions over a network. Messages are defined in a schema file, usually in Protocol Buffers, and sent in a compact binary format over HTTP/2. It supports streaming in either direction as well as simple request and response.
Developers like it for speed and for the code it generates in many languages. Because the messages are binary and the calls look like function names, it does not read like a typical web request.
Why it matters
Its security tools and habits are less familiar than those for REST. Many proxies, scanners and review checklists expect JSON, so a gRPC service can sit outside the normal checks. It is common between internal services, where trust is often assumed.
That assumption is the risk. A service that trusts anything reaching it lets a single compromised workload, or an exposed port, call functions it should not. The usual API flaws, such as missing checks on who may call a method, apply in full.
How it shows up
You meet it between microservices, in mobile back ends and in streaming features. The schema file lists every method and field. Some servers also switch on a reflection service that lists them on request, which is handy in development and generous to outsiders in production.
The mistakes repeat. Traffic is unencrypted inside the network. Authentication is checked on some methods and forgotten on others. Method-level permissions are missing. Message sizes and stream counts are unlimited. Check TLS, per-method authorisation, reflection and input limits.
Questions people ask
gRPC, answered
Is gRPC more secure than REST?
Not by itself. It supports TLS and token-based authentication, and the typed schema helps validate input. But it has the same classes of flaws: missing authorisation, trust in the caller and unlimited requests.
The format changes the tools, not the risks.
How is gRPC authenticated?
Commonly with TLS for the channel, mutual TLS between services, and a token sent with each call. The gRPC documentation describes these options.
Each method still has to check what the caller may do.
Should gRPC reflection be on in production?
Usually not on services that outsiders can reach. Reflection lets a client ask the server to list its services and methods, which gives an attacker a map for free.
Keep it for development or restricted networks.
Can we test a gRPC service with normal web tools?
Not directly. You need the schema file or reflection, and a client that can speak the protocol. Some proxies and scanners now handle it, but coverage varies.
Make sure your testing covers it.
Does gRPC work in browsers?
Not directly, because browsers do not expose the controls it needs. A variant called gRPC-Web, usually with a proxy, is used for that.
The proxy then becomes part of your attack surface.
Sources
Where this comes from
Related
Terms that sit next to this one
API
The part of your application other software talks to, not a person.
REST API
A common web API style where URLs name things and HTTP verbs act on them.
API authentication
How an API decides which caller is making a request before it does anything.
Object-level authorisation
Checking access to each individual record, not only to the type of record.
API inventory
A maintained list of every API you expose, who owns it and what it returns.
Who can call each method?
We find vulnerabilities in web apps and their APIs, including cross-account access between users, and prove each by exploiting it. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.