GraphQL, gRPC, WebSockets and Real-Time API Security — DedSec Project

Modern applications expose more than REST. GraphQL, gRPC, WebSockets, server-sent events, and asynchronous APIs move authorization and resource-control decisions into different protocol shapes. Security testing must follow the application’s state model, not assume every request is a simple HTTP endpoint.

Learning objectives

By the end of this module you should be able to:

• Explain GraphQL schema surface and connect it to a concrete trust boundary or security invariant.
• Explain Query complexity and connect it to a concrete trust boundary or security invariant.
• Explain Object and field authorization and connect it to a concrete trust boundary or security invariant.
• Explain gRPC semantics and connect it to a concrete trust boundary or security invariant.
• Explain WebSocket lifecycle and connect it to a concrete trust boundary or security invariant.
• Explain Realtime multi-tenancy and connect it to a concrete trust boundary or security invariant.

Deep concepts

1. GraphQL schema surface

A GraphQL schema exposes types, fields, arguments, mutations, and relationships. Authorization must be enforced on resolvers and business objects, not inferred from whether a field is hidden from introspection.

2. Query complexity

Nested queries, aliases, batching, pagination, and expensive resolvers can amplify backend work. Define query-depth/complexity budgets, data-loader behavior, timeouts, and per-principal resource limits.

3. Object and field authorization

A user allowed to read an object may not be allowed to read every field or invoke every mutation. Model object-level, property-level, and function-level authorization separately.

4. gRPC semantics

gRPC uses HTTP/2 framing and strongly typed protobuf messages, but serialization does not provide authorization. Interceptors, metadata, service/method policy, message limits, deadline propagation, and reflection exposure need explicit review.

5. WebSocket lifecycle

Authorization can change after a WebSocket upgrade. Validate the initial handshake, authenticate subscriptions/actions, handle token expiry/revocation, enforce message-size/rate limits, and close stale sessions deliberately.

6. Realtime multi-tenancy

Subscriptions and event channels can leak cross-tenant data if routing keys, topics, or filters are built from attacker-controlled identifiers without server-side ownership checks.

7. Protocol translation

Gateways often translate JSON/HTTP into gRPC or events. Security assumptions can be lost when one layer normalizes headers, paths, identities, or error codes differently from the next.

8. Observability

Log principal, operation/method, object or tenant scope, complexity/cost, result class, and correlation IDs. Avoid logging raw secrets or entire message bodies by default.

Authorized exercises

Exercise 1 — Implement a tiny localhost GraphQL-like toy resolver in Python and write authorization tests for object and field access without exposing it beyond loopback

Implement a tiny localhost GraphQL-like toy resolver in Python and write authorization tests for object and field access without exposing it beyond loopback.

Exercise 2 — Model a WebSocket session as states: unauthenticated, authenticated, reauthenticated, revoked, closed; define allowed messages in each state

Model a WebSocket session as states: unauthenticated, authenticated, reauthenticated, revoked, closed; define allowed messages in each state.

Exercise 3 — Create a gRPC security review checklist covering identity propagation, method authorization, deadlines, message limits, and logging

Create a gRPC security review checklist covering identity propagation, method authorization, deadlines, message limits, and logging.

Knowledge checks

1. Explain the most important trust boundary in GraphQL, gRPC, WebSockets and Real-Time API Security without naming a security tool.
2. Give one example where cryptographic or authentication success still does not imply authorization success.
3. Describe one stale-state or replay condition relevant to this module.
4. Identify one telemetry source that can support a strong conclusion and one blind spot it still leaves.
5. Explain how you would turn a discovered weakness into a regression test rather than a one-time finding.

Guided study workflow