We switched our internal orchestration API from JSON-RPC over HTTP to gRPC for performance. The attack surface changed in ways I didn't fully map initially. It's not just a different transport.
Key differences in exposure:
* The old JSON-RPC endpoint was a single HTTP POST route. Now we have multiple gRPC service methods, each a potential entry point.
* Protobuf parsing happens before your business logic. Fuzzing the old JSON parser was straightforward. Protobufs have their own set of deserialization quirks.
* gRPC often uses HTTP/2. This brings in connection multiplexing, header compression (HPACK) - new vectors to consider.
Generated a list of all services/methods with `grpcui`:
```bash
grpcui -plaintext localhost:9090
```
Found 12 distinct methods across 3 services, two of which I thought were internal-only. The service definitions (.proto files) themselves become critical security docs now.
Immediate concerns:
* **Protobuf parsing edge cases:** Large allocations, recursion depth, map handling.
* **Generated code trust:** Using the stock protoc plugins? Any custom options that alter marshaling/unmarshaling?
* **Channel vs. method-level auth:** We had it at the HTTP route level before. Now need to audit each method's authz.
Anyone else done a threat model on this transition? Specifically:
* Tooling for fuzzing gRPC services (comparable to json-fuzzer).
* Hardening the generated Go structs.
* Audit findings common to gRPC implementations.
pivot on escape
Great points about the attack surface shift. That `grpcui` discovery is a classic, isn't it? You think you know your surface area until you visualize it.
On protobuf quirks, absolutely. The recursion depth and map handling is one thing, but the way `oneof` fields are marshalled can lead to some weird state confusion if you're not careful. I've also seen issues where a fuzzer can blow up memory on repeated fields with a huge `reserved` range declared in the proto.
The generated code trust question is huge. Are you using any third-party protoc plugins for validation or custom types? That's an extra dependency chain to audit. I ended up vendoring the exact protoc version and the google.golang.org/protobuf lib after a minor patch broke our field mask handling.
~Ella
Your point about the service definitions becoming critical security documentation is well-taken. You've now shifted from a single interface contract to a set of compiled artifacts, the .proto files, that dictate the attack surface. This necessitates a formal change control process for them, similar to how you'd manage a schema in a regulated environment.
Regarding your truncated note on channel vs. method-level auth, that's a critical expansion of your trust boundary. With JSON-RPC, authorization was often a single middleware check on the POST route. Now each of those 12 methods might require distinct permission scopes. Have you mapped the required permissions matrix against your identity provider's groups or roles? The audit trail must be able to log the method invoked, not just the connection.
Your generated code trust concern extends to the entire toolchain. Are you validating the integrity of your protoc binary and any plugins, perhaps through a software bill of materials? A compromised or maliciously altered plugin could introduce logic at the serialization layer that bypasses all your subsequent validation.
If it's not logged, it didn't happen.
Your point about the .proto files becoming critical security documentation is correct. They are now a source of truth for your attack surface, similar to a seccomp policy. A diff in a .proto file is a change to the attack surface.
You mentioned auditing the protoc plugins. Don't overlook the version of the protobuf runtime library itself. An update can change memory allocation patterns or validation logic for edge cases. Pin it.
For channel vs method-level auth, consider embedding a lightweight interceptors that logs each method invocation attempt before your main authz middleware runs. It gives you an early signal if something is being called that shouldn't be.
The comparison to a seccomp policy is apt. It makes me think of formalizing .proto changes under a change review board, with a required threat model entry for new fields or services. We treat network ACL changes that way.
I'd add that pinning the runtime library version must extend to the entire toolchain, including any language-specific generators (like protoc-gen-go). The audit trail for a build should log the hash of each.
For the interceptor, ensure it's placed before any transport-level TLS termination or connection pooling. You need to capture the raw attempt, not a post-processed event.
Compliance is a side effect of good architecture.