No. A maximum message size limits each message, but a stream can carry many valid messages, so total data and processing work stay unbounded. Pair the size cap with limits on messages per stream, session duration, request rate and timeouts. OWASP's gRPC cheat sheet makes this point directly.
What the size limit does
OWASP's gRPC guidance says to set application appropriate limits on individual messages in both directions. It notes that in the Go implementation the server's receive limit already defaults to 4 MiB, and shows how to set it explicitly. Setting it deliberately is better than inheriting a default you have not looked at, especially if your messages are normally small.
The protobuf documentation gives a related design hint: protobuf is not designed for large messages, and as a rule of thumb, if messages are larger than a megabyte each it may be time to consider another strategy. A small limit therefore also forces a good design.
What the size limit does not do
The cheat sheet states that a stream can still carry many individually valid messages, so a per message limit does not bound the total data or the processing work for that stream. An attacker can open a stream and send millions of legal small messages.
Likewise, limiting stream creation alone does not limit messages on a stream that is already open. Rate limit interceptors written for unary calls do not cover streams unless you add a stream interceptor.
The set of limits to configure
| Limit | What it controls | Where |
|---|---|---|
| Max receive message size | Size of one incoming message | Server option |
| Max send message size | Size of one outgoing message | Server option |
| Messages per stream | Total messages in one stream | Stream interceptor or handler |
| Session duration | How long a stream may stay open | Stream interceptor |
| Request rate per client | Calls per second per caller | Interceptor |
| Deadline or timeout | How long processing may take | Client and server |
| Concurrent streams | Open streams per client | Server and proxy settings |
OWASP also recommends monitoring maximum messages per stream and maximum session duration. For a broader checklist of limits, the OWASP API Security Top 10 entry on unrestricted resource consumption lists execution timeouts, memory, file descriptors, processes, upload size, operations per request, page size and third party spending limits.
Steps
- Set explicit receive and send size limits close to your largest legitimate message.
- Count messages inside each streaming handler and end the stream when it passes a threshold.
- Track stream age and close long lived idle streams.
- Add a stream interceptor for admission limits per caller.
- Derive rate limit keys from an authenticated identity or trusted connection, not from headers a client can forge. OWASP makes this point about forwarded headers.
- Set deadlines on both sides. See gRPC deadlines as a security control.
- Load test with many small messages, not only big ones.
Quick sanity test
Write a client that opens one stream and sends a million tiny messages in a loop against a staging server. Watch CPU, memory and connection state. If nothing stops it, you have found the gap before an attacker does.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how scan results separate resource consumption from authentication findings.
Quick check
What is the default receive size in grpc-go?
OWASP's cheat sheet says the server's receive limit already defaults to 4 MiB in grpc-go. Other languages differ, so check yours.
Does limiting stream creation limit messages?
No. It limits how many streams open. Messages inside an open stream need their own count and rate limits.
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
- OWASP gRPC Security Cheat Sheet
- Protocol Buffers Techniques
- OWASP API4:2023 Unrestricted Resource Consumption
Last reviewed: 19 October 2026.
