NestJS Risk Assessment & Management 5 — Questions and Answers
Question 1: In NestJS, what is the risk of storing JWT refresh tokens only in memory on the server side?
- They are lost on process restart and cannot be revoked across instances (Correct answer)
- They are automatically shared between microservice nodes
- Memory storage is slower than database storage for token lookups
- NestJS Passport strategies do not support in-memory token stores
Correct answer: They are lost on process restart and cannot be revoked across instances
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?
- Browsers may allow downgrade attacks where connections fall back to unencrypted HTTP (Correct answer)
- NestJS Helmet middleware throws a runtime error
- JWT tokens are transmitted in URL query strings
- TypeORM SSL connections are disabled automatically
Correct answer: Browsers may allow downgrade attacks where connections fall back to unencrypted HTTP
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?
- Remote code execution, allowing an attacker to run arbitrary JavaScript on the server (Correct answer)
- TypeScript compilation fails because eval is not typed
- NestJS interceptors are bypassed for that request
- The event loop is blocked, causing timeouts for other requests
Correct answer: Remote code execution, allowing an attacker to run arbitrary JavaScript on the server
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?
- Failed or hung instances continue to receive traffic because the orchestrator cannot detect the degraded state (Correct answer)
- NestJS module initialization order becomes non-deterministic
- Database connection pools are not released on pod eviction
- Swagger documentation stops auto-generating on restart
Correct answer: Failed or hung instances continue to receive traffic because the orchestrator cannot detect the degraded state
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?
- Cross-Site Request Forgery on the OAuth flow, allowing attackers to link their account to a victim's session (Correct answer)
- JWT tokens issued by the provider are not cached correctly
- NestJS Passport cannot deserialize the user from the session
- The provider's access token expires before the callback is processed
Correct answer: Cross-Site Request Forgery on the OAuth flow, allowing attackers to link their account to a victim's session
Omitting state validation removes the CSRF protection built into the OAuth 2.0 authorization code flow, enabling session fixation attacks.
Question 6: In a NestJS microservices architecture, what risk does not implementing idempotency on message consumers introduce?
- Duplicate messages from the broker can cause double-processing of financial transactions or duplicate records (Correct answer)
- Message serialization defaults to BSON instead of JSON
- NestJS cannot subscribe to multiple message patterns simultaneously
- Dead-letter queues stop routing unprocessed messages
Correct answer: Duplicate messages from the broker can cause double-processing of financial transactions or duplicate records
Message brokers may redeliver messages at least once; without idempotency checks, consumers process the same event multiple times, corrupting data.
Question 7: Which practice best reduces the risk of outdated or vulnerable NestJS dependencies reaching a production build?
- Automated dependency scanning with npm audit or Snyk in a CI gate that blocks merges on critical CVEs (Correct answer)
- Pinning all package versions to exact semver strings and never updating
- Using npm install --legacy-peer-deps to skip peer-dependency checks
- Manually reviewing changelogs once per quarter before deployment
Correct answer: Automated dependency scanning with npm audit or Snyk in a CI gate that blocks merges on critical CVEs
Integrating automated vulnerability scanning into CI ensures that critical CVEs are caught before code merges, not after deployment.
NestJS Risk Assessment & Management 5
In NestJS, what is the risk of storing JWT refresh tokens only in memory on the server side?