Cybersecurity glossary

What is gRPC?

Learn what gRPC is, how Protocol Buffers and HTTP/2 enable efficient service APIs, when to choose gRPC over REST, and which security controls matter in production.

Web platform securityUpdated July 22, 2026
Also known asgRPC RPCGoogle Remote Procedure CallProtobuf RPC over HTTP/2

Definition

gRPC is a high-performance remote procedure call (RPC) framework that typically uses Protocol Buffers for interface contracts and HTTP/2 for transport, enabling efficient unary and streaming calls between services and clients.

Why gRPC matters

JSON-over-HTTP APIs are flexible, but chatty microservices pay for that flexibility with larger payloads, weaker contracts, and awkward streaming. Teams that need low latency and strong typing between services often adopt gRPC.

With Interface Definition Language (IDL) files, code generation, and HTTP/2 multiplexing, gRPC makes cross-language service calls feel closer to local methods—while still requiring the same security discipline as any remote API.

Core building blocks

Service contracts (.proto)

Define methods, message fields, and compatibility rules that generate client and server stubs.

Protocol Buffers encoding

Compact binary serialization reduces payload size versus typical JSON for the same schema.

HTTP/2 transport

Streams and multiplexing carry many concurrent RPCs efficiently on fewer connections.

Deadlines and status codes

First-class timeouts and rich status details help callers fail fast and handle errors consistently.

How a gRPC call works

1

Define the API in Protobuf

Authors declare services and messages; CI generates stubs for each language.

2

Client creates a channel

It connects to a target address, often with TLS and optionally load-balancing policies.

3

Stub invokes a method

The call looks like a function invocation but is serialized and sent as HTTP/2 streams.

4

Server deserializes and authorizes

Interceptors validate identity, quotas, and message size before business logic runs.

5

Unary or streaming responses return

One message or a sequence flows back with status metadata.

6

Observability records RPC metrics

Method latency, error codes, and message sizes feed SLOs and abuse detection.

gRPC vs REST/JSON

TopicgRPCTypical REST/JSON
ContractProtobuf IDL + codegenOpenAPI or informal JSON shapes
PayloadBinary, schema-orientedText JSON, human-debuggable
StreamingFirst-class bidirectional streamsUsually request/response; SSE/WebSocket as extras
Browser supportOften needs gRPC-Web or a gatewayNative and universal
Tooling familiarityStrong in service meshes and polyglot backendsStrong across public API ecosystems

Security considerations

Binary protocols are not “more secure” by default—they are just different to inspect.

Encrypt every untrusted hop

Use TLS externally and mTLS for service identity inside clusters when possible.

Authorize per RPC method

Treat each procedure like an API route with explicit permission checks.

Bound message and stream sizes

Prevent memory exhaustion from oversized protobufs or endless streams.

Validate fields beyond schema types

Protobuf types are not business rules—check ranges, enums, and tenancy IDs.

Mind intermediary visibility

WAFs and older proxies may not understand gRPC framing; plan inspection points deliberately.

Avoid trusting network location

Internal gRPC without auth becomes a lateral-movement highway after one foothold.

Adoption checklist

  • Own `.proto` compatibility rules (field numbers, deprecation) as carefully as database migrations.
  • Set deadlines on clients and enforce server-side timeouts for every method.
  • Enable TLS/mTLS and identity-aware authorization before exposing services broadly.
  • Configure max inbound message sizes and concurrent stream limits.
  • Expose health checks and metrics that operators can scrape without leaking sensitive data.
  • Decide how browser and partner clients will access the API (gRPC-Web, gateway, or separate REST).
  • Load-test streaming methods under backpressure—not only unary happy paths.
  • Document reflection/admin endpoints and disable them in production if unused.

The practical takeaway

gRPC is an RPC framework built around typed contracts and efficient HTTP/2 transport. It shines for service-to-service communication and streaming, especially in polyglot microservice environments.

Choose it when contract strength and performance outweigh broad HTTP debugging simplicity—and secure it like any sensitive API: encrypt, authenticate, authorize, limit, and observe every method.

Related security terms

Frequently asked questions

What is gRPC in simple terms?

It is a way for programs to call functions on other programs over the network using compact binary messages and a strict API contract, usually faster and more typed than ad-hoc JSON HTTP APIs.

Does gRPC only work with Protocol Buffers?

Protobuf is the default and most common choice, but gRPC’s concept is pluggable; in practice most teams standardize on `.proto` contracts.

Can browsers call gRPC directly?

Not with full native gRPC in the same way servers do. Web clients often use gRPC-Web or a REST/JSON gateway in front of gRPC services.

Is gRPC better than REST?

It depends. gRPC excels at efficient service-to-service calls and streaming. REST/JSON remains simpler for public HTTP APIs and broad client ecosystems.

What are unary and streaming RPCs?

Unary is one request and one response. Streaming allows the client, server, or both to send a sequence of messages on a single RPC.

How do you secure gRPC?

Use TLS or mTLS, authenticate callers, authorize per method, validate protobuf fields, and apply timeouts, size limits, and rate controls.

Does gRPC need HTTP/2?

Classic gRPC over the internet commonly requires HTTP/2. Newer variants and proxies may bridge protocols, but HTTP/2 semantics are central to mainstream deployments.

References

Explore authoritative guidance and frameworks related to grpc.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary