NestJS Risk Assessment & Management 4

Question 1

What risk does not sanitizing user-supplied values before passing them to a TypeORM QueryBuilder introduce?

Accepted Answer

SQL injection, allowing attackers to manipulate or exfiltrate database data

Answer

Concatenating unsanitized user input into raw SQL expressions enables injection attacks that can read, modify, or delete arbitrary data.

Question 2

Which NestJS approach reduces the risk of privilege escalation by ensuring a user can only access their own resources?

Accepted Answer

Implementing resource-level authorization in guards using the requesting user's ID from the JWT payload

Answer

Comparing the JWT subject claim to the resource owner ID inside a guard prevents users from accessing other users' data even with valid tokens.

Question 3

In a NestJS GraphQL API, what security risk do deeply nested queries pose?

Accepted Answer

They can cause denial-of-service by triggering exponentially expensive resolver chains

Answer

Deeply nested GraphQL queries can cause N+1 resolver explosions and overwhelm the server, a risk mitigated by query depth and complexity limits.

Question 4

When deploying a NestJS application in a Docker container, which practice reduces the attack surface at the infrastructure level?

Accepted Answer

Running the Node.js process as a non-root user inside the container

Answer

Running as a non-root user limits the damage an attacker can do if they gain code execution inside the container.

Question 5

A NestJS service caches sensitive user data in Redis without an expiry. What risk does this create?

Accepted Answer

Stale sensitive data persists indefinitely, increasing exposure if the cache is breached

Answer

Without a TTL, sensitive records remain in the cache long after they are no longer needed, enlarging the window for unauthorized access.

NestJS Practice Test