NestJS Risk Assessment & Management 5

Question 1

In NestJS, what is the risk of storing JWT refresh tokens only in memory on the server side?

Accepted Answer

They are lost on process restart and cannot be revoked across instances

Answer

In-memory storage is ephemeral and node-local, making token revocation impossible in multi-instance deployments and causing session loss on restart.

Question 2

Which risk does not enabling HTTP Strict Transport Security (HSTS) in a NestJS app served over HTTPS introduce?

Accepted Answer

Browsers may allow downgrade attacks where connections fall back to unencrypted HTTP

Answer

Without HSTS, an attacker performing a man-in-the-middle attack can strip TLS and intercept traffic over plain HTTP.

Question 3

A NestJS app uses eval() to process a user-submitted expression. What is the primary risk?

Accepted Answer

Remote code execution, allowing an attacker to run arbitrary JavaScript on the server

Answer

eval() executes arbitrary JavaScript, and any unsanitized user input becomes a vector for remote code execution on the server.

Question 4

What operational risk does a NestJS application face when it lacks health-check endpoints monitored by an orchestrator like Kubernetes?

Accepted Answer

Failed or hung instances continue to receive traffic because the orchestrator cannot detect the degraded state

Answer

Without liveness and readiness probes, Kubernetes routes traffic to unhealthy pods, degrading the user experience and masking failures.

Question 5

When a NestJS application integrates with a third-party OAuth provider, what risk arises from not validating the state parameter during the callback?

Accepted Answer

Cross-Site Request Forgery on the OAuth flow, allowing attackers to link their account to a victim's session

Answer

Omitting state validation removes the CSRF protection built into the OAuth 2.0 authorization code flow, enabling session fixation attacks.

NestJS Practice Test