Prerequisites
- Target system, dependencies and environment configured.
Usage
Purpose
gRPC is HTTP/2 plus protobuf, used heavily for service-to-service and increasingly for client-facing APIs. The security fundamentals are the same as any API — authenticate, authorize, validate — but the binary framing and the "internal by default" assumption change how issues show up and get missed. This skill covers the gRPC-specific angles.
When to use it
Any gRPC service, especially one exposed beyond a trusted network. gRPC's reputation as an "internal" protocol means auth and validation are often weaker than on a public REST API — which is exactly why it's worth testing.
Procedure
- Discover the interface. If server reflection is enabled, you can enumerate services and methods without the
.proto files — useful for testing, a disclosure to consider disabling in production:grpcurl -plaintext api.tld:443 list
grpcurl -plaintext api.tld:443 describe some.Service
- Check transport security. gRPC should run over TLS. A
-plaintext connection succeeding on an exposed endpoint means traffic is unencrypted — a finding.
- Test authentication. gRPC auth is usually a token in call metadata (like an HTTP header). Test the same failures as REST: does a method accept a missing/invalid/expired token? Are all methods protected, or only some?
grpcurl -H "authorization: Bearer <token>" api.tld:443 some.Service/Method
- Test authorization per method and per object. BOLA applies: can you call a method with another user's object ID? Enumerate the methods (reflection helps) and check each enforces access, not just authentication.
- Test input validation. protobuf gives you typed fields, which stops some malformed input — but it does not validate business constraints or stop injection in the values. The resolvers behind gRPC hit databases; the usual injection tests apply to string fields.
- Check resource limits. Large messages, streaming abuse, and unbounded requests are DoS vectors — confirm max message sizes and streaming limits are set.
Cheatsheet
grpcurl -plaintext host:port list
grpcurl -plaintext host:port describe pkg.Service
grpcurl -H "authorization: Bearer $T" -d '{"id":"123"}' host:port pkg.Service/Get
grpcurl -d '{"id":"123"}' host:port pkg.Service/Get # no token -> should fail
grpcurl -H "authorization: Bearer $T" -d '{"id":"<other>"}' host:port pkg.Service/Get
grpcurl -plaintext host:port list # succeeds? traffic may be unencrypted
Reading the output
-plaintext working on an exposed endpoint = no/negotiable TLS; traffic is interceptable. Finding.- A method answering with no or invalid token = broken authentication, same as REST — often worse on gRPC because it was assumed internal.
- Reaching another user's object via a method call = BOLA over gRPC; the binary framing doesn't make it any less exploitable.
- Reflection exposing the full service map in production = information disclosure; convenient for you as a tester, worth disabling for the defender.
- Injection landing in a string field = the protobuf type system validated the shape, not the content — the resolver is still vulnerable.
The fix
- Require TLS (mTLS for service-to-service) — disable plaintext on anything exposed. mTLS also gives you strong service identity.
- Authenticate every method via call credentials/metadata, validated server-side; don't assume "internal" means safe.
- Authorize per method and per object, using the authenticated identity — a gateway/interceptor is a good place to enforce authentication uniformly, but object-level checks stay in the service.
- Validate field content, not just protobuf types — apply the injection and business-rule checks the type system doesn't. Use a validation layer (e.g. protovalidate/buf) for constraints.
- Set message size and streaming limits to bound resource use.
- Disable server reflection in production unless you specifically need it.
Pitfalls
- Assuming "internal" equals secure. gRPC's service-mesh heritage leads teams to skip auth; exposed gRPC needs the same rigor as public REST.
- Trusting protobuf as input validation. It checks types, not values or business rules — injection and invalid-state bugs pass straight through.
- Plaintext in production. Easy to leave on from local dev; it exposes all traffic.
- Authenticating but not authorizing per object. BOLA is as common on gRPC as REST; typed IDs are still guessable/enumerable.
References
- gRPC authentication and TLS documentation
- OWASP API Security Top 10 (applies to gRPC)
- buf / protovalidate for input constraints
- CWE-287, CWE-639
Inputs
- Relevant source code, logs, network traces, or system specifications.
Outputs
- Analysis findings, security audit report, or generated code artifacts.
1---2name: grpc-security3description: Use when securing or testing a gRPC API — authentication, input validation, and the differences from REST that change how you attack and defend it.4---5678## Prerequisites9- Target system, dependencies and environment configured.1011## Usage12### Purpose1314gRPC is HTTP/2 plus protobuf, used heavily for service-to-service and increasingly for client-facing APIs. The security fundamentals are the same as any API — authenticate, authorize, validate — but the binary framing and the "internal by default" assumption change how issues show up and get missed. This skill covers the gRPC-specific angles.1516### When to use it1718Any gRPC service, especially one exposed beyond a trusted network. gRPC's reputation as an "internal" protocol means auth and validation are often weaker than on a public REST API — which is exactly why it's worth testing.1920### Procedure21221. **Discover the interface.** If server reflection is enabled, you can enumerate services and methods without the `.proto` files — useful for testing, a disclosure to consider disabling in production:23 ```24 grpcurl -plaintext api.tld:443 list25 grpcurl -plaintext api.tld:443 describe some.Service26 ```272. **Check transport security.** gRPC should run over TLS. A `-plaintext` connection succeeding on an exposed endpoint means traffic is unencrypted — a finding.283. **Test authentication.** gRPC auth is usually a token in call metadata (like an HTTP header). Test the same failures as REST: does a method accept a missing/invalid/expired token? Are all methods protected, or only some?29 ```30 grpcurl -H "authorization: Bearer <token>" api.tld:443 some.Service/Method31 ```324. **Test authorization per method and per object.** BOLA applies: can you call a method with another user's object ID? Enumerate the methods (reflection helps) and check each enforces access, not just authentication.335. **Test input validation.** protobuf gives you typed fields, which stops some malformed input — but it does **not** validate business constraints or stop injection in the values. The resolvers behind gRPC hit databases; the usual injection tests apply to string fields.346. **Check resource limits.** Large messages, streaming abuse, and unbounded requests are DoS vectors — confirm max message sizes and streaming limits are set.3536### Cheatsheet3738```bash39grpcurl -plaintext host:port list40grpcurl -plaintext host:port describe pkg.Service4142grpcurl -H "authorization: Bearer $T" -d '{"id":"123"}' host:port pkg.Service/Get43grpcurl -d '{"id":"123"}' host:port pkg.Service/Get # no token -> should fail4445grpcurl -H "authorization: Bearer $T" -d '{"id":"<other>"}' host:port pkg.Service/Get4647grpcurl -plaintext host:port list # succeeds? traffic may be unencrypted48```4950### Reading the output5152- **`-plaintext` working on an exposed endpoint** = no/negotiable TLS; traffic is interceptable. Finding.53- **A method answering with no or invalid token** = broken authentication, same as REST — often worse on gRPC because it was assumed internal.54- **Reaching another user's object via a method call** = BOLA over gRPC; the binary framing doesn't make it any less exploitable.55- **Reflection exposing the full service map** in production = information disclosure; convenient for you as a tester, worth disabling for the defender.56- **Injection landing in a string field** = the protobuf type system validated the *shape*, not the *content* — the resolver is still vulnerable.5758### The fix5960- **Require TLS** (mTLS for service-to-service) — disable plaintext on anything exposed. mTLS also gives you strong service identity.61- **Authenticate every method** via call credentials/metadata, validated server-side; don't assume "internal" means safe.62- **Authorize per method and per object**, using the authenticated identity — a gateway/interceptor is a good place to enforce authentication uniformly, but object-level checks stay in the service.63- **Validate field content**, not just protobuf types — apply the injection and business-rule checks the type system doesn't. Use a validation layer (e.g. protovalidate/buf) for constraints.64- **Set message size and streaming limits** to bound resource use.65- **Disable server reflection in production** unless you specifically need it.6667### Pitfalls6869- **Assuming "internal" equals secure.** gRPC's service-mesh heritage leads teams to skip auth; exposed gRPC needs the same rigor as public REST.70- **Trusting protobuf as input validation.** It checks types, not values or business rules — injection and invalid-state bugs pass straight through.71- **Plaintext in production.** Easy to leave on from local dev; it exposes all traffic.72- **Authenticating but not authorizing per object.** BOLA is as common on gRPC as REST; typed IDs are still guessable/enumerable.7374### References7576- gRPC authentication and TLS documentation77- OWASP API Security Top 10 (applies to gRPC)78- buf / protovalidate for input constraints79- CWE-287, CWE-6398081## Inputs82- Relevant source code, logs, network traces, or system specifications.8384## Outputs85- Analysis findings, security audit report, or generated code artifacts.
jihedbfr-art