api-grpclisted

# gRPC / Protobuf API attacks ## When it applies The target exposes gRPC (or grpc-web). Binary framing over HTTP/2 makes it feel opaque, but the same authz/injection bugs apply — and server reflection often hands you the whole API. ## Why it works gRPC methods are RPCs with typed messages; security still lives per-method. Reflection (if on) exposes every service/method, and teams frequently skip auth on internal-looking RPCs or trust the client-generated stubs to enforce access. ## Method 1. **Enumerate via reflection**: `grpcurl -plaintext host:50051 list` then `list <service>` and `describe <method>`; `grpcui` for an interactive UI. No reflection? Recover `.proto` from the client/mobile app or JS (grpc-web). 2. **Call methods directly**: `grpcurl -d '{"id":123}' host:port pkg.Service/Method` — test BOLA/BFLA by calling privileged methods or swapping object ids with a low-priv token. 3. **Auth testing**: replay with/without metadata (the gRPC equivalent of headers/tokens); many servers authenticate the connection but not each method. 4. **Injection**: message fields feed backends — test SQLi/NoSQLi/command injection in string fields. 5. **grpc-web**: it rides HTTP/1.1+base64 — proxy through Burp, decode frames, tamper. ## Gotchas - Reflection off ≠ safe — extract the schema from clients; then `grpcurl` with a local `.proto`. - Binary framing hides bugs from scanners; manual method-by-method testing is the win. - HTTP/2 + TLS: use `-plaintext` only when the se