03 / 06

How do you write a single guard that works across both HTTP and WebSocket transports in NestJS?

Difficulty: 6/10
NestJS guards, transport‑agnostic implementation, WebSocket vs HTTP context

Use ctx.getType() to detect the current transport and branch accordingly. For HTTP, extract the token from the Authorization header. For WebSocket, extract it from client.handshake.auth or handshake headers. Return true if verification succeeds, throw the transport-appropriate exception if not.

Universal auth guard for HTTP and WebSocket
Multi-transport guard design notes:
  1. 1

    ctx.getType() returns 'http', 'ws', or 'rpc' — always check before switching context.

  2. 2

    WebSocket tokens come from handshake.auth (Socket.IO) or handshake.headers.

  3. 3

    Store user on client.data.user for WebSocket — equivalent to req.user for HTTP.

  4. 4

    Throw WsException for WebSocket errors, not HttpException — they serialize differently.

  5. 5

    For microservice RPC use ctx.switchToRpc().getData() to access the message payload.

Scenario Questions

0-2 years experience

  1. 1We have a NestJS controller and a WebSocket gateway that both need JWT authentication. How would you write a single guard that can be applied to both?
  2. 2When you read the token from an HTTP request versus a WebSocket connection, what parts of the context do you need to look at?
  3. 3If you placed a regular @UseGuards guard on a WebSocket gateway without any changes, what would happen and why?

2-5 years experience

  1. 1After deploying a shared auth guard, HTTP calls succeed but WebSocket connections are rejected even with a valid token. Walk me through how you'd debug the problem.
  2. 2Why might you need to call ExecutionContext.switchToHttp() in some cases and switchToWs() in others inside the same guard?
  3. 3You now need role‑based access in addition to authentication. How would you extend the transport‑agnostic guard to check roles without duplicating code?

5-8 years experience

  1. 1Design a guard that works for HTTP, WebSocket, and also for microservice message patterns like Redis. What architectural choices keep it maintainable?
  2. 2Discuss the performance trade‑offs of extracting the JWT on every WebSocket message versus caching the user in the socket context. How would your guard handle this?
  3. 3If the system must accept both JWT and API‑key authentication across transports, how would you structure the validation flow to avoid duplicated logic and stay secure?

8+ years experience

  1. 1Our monolith is being split into microservices, some using HTTP and others using GraphQL subscriptions over WebSocket. How would you evolve the existing transport‑agnostic guard strategy to support this migration with minimal impact?
  2. 2Multiple teams need to enforce different policies (rate limiting, IP allow‑list) on both HTTP and WebSocket endpoints. How would you design a pluggable guard framework in NestJS that lets each team inject their own checks without code duplication?
  3. 3What long‑term maintenance risks arise from embedding transport‑specific logic inside a single guard, and how would you mitigate those risks at an organization level?

Follow-up Questions

  • How would you test this guard for both transports?
  • What changes would you make if you needed to support a second authentication scheme?
  • Can you discuss any pitfalls when re‑using the same guard across multiple modules?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.