gRPC uses HTTP/2 as its transport and Protocol Buffers for serialization. From a security perspective, the key differences from REST are: authentication is typically handled via interceptors (not middleware), metadata headers carry sensitive context, streaming RPCs have different lifecycle characteristics than unary calls, and error handling is more structured.
Authentication via Interceptors
gRPC authentication is implemented through interceptors — functions that wrap every RPC call. The standard pattern is to include a JWT or API key in gRPC metadata, extract it in an interceptor, validate it, and attach the authenticated identity to the call context. If the interceptor is misconfigured or bypassed, all RPCs behind it are unauthenticated.
The Metadata Attack Surface
gRPC metadata headers are analogous to HTTP headers but are defined per-call by the client. Clients can set arbitrary metadata keys unless the server explicitly filters them. If your service passes client-controlled metadata to downstream services as trusted context — a common pattern for service mesh deployments — metadata injection can escalate privileges.
Streaming RPC Considerations
Server-streaming and bidirectional streaming RPCs maintain a long-lived connection. Like WebSockets, authentication happens at stream establishment. If authentication state changes after the stream is opened, the server must detect this — it will not happen automatically. Implement periodic re-authentication checks in long-lived streams.
Reflection and Service Discovery
gRPC reflection is a service that exposes your proto definitions to any client. Like GraphQL introspection, it is a useful development tool and a reconnaissance gift to attackers in production. Disable gRPC reflection in production environments.
G8KEPR's Protocol Gateways module handles gRPC-to-REST transcoding and applies authentication and rate limiting at the gRPC layer. Reflection is disabled by default in all gateway-proxied gRPC services.