Common Node.js & Express Pitfalls

Many production incidents in Node.js and Express applications trace back to a small set of recurring mistakes: blocking the event loop, ignoring rejected promises, trusting user input, forgetting error-handling middleware, leaking memory, and mismanaging secrets or process lifecycle. Recognizing these pitfalls — and knowing the standard fix for each — is a strong signal of production experience and comes up constantly in interviews and code review.

Because Node.js runs JavaScript on a single thread, any long synchronous operation — a heavy computation, a large JSON.parse, or a *Sync file system call — blocks the event loop entirely, preventing it from processing any other incoming requests or scheduled callbacks until that operation finishes. In a busy server this can stall every concurrent user. The fix is to use asynchronous APIs (fs.readFile instead of fs.readFileSync), offload CPU-heavy work to worker_threads or a separate service, or break large synchronous tasks into chunks using setImmediate to yield control back to the event loop.

An unhandled promise rejection triggers Node's 'unhandledRejection' event; historically this only printed a warning, but in modern Node versions the default behavior is to terminate the process, similar to an uncaught exception. This is dangerous because a single unawaited or uncaught async error in, say, a background job or an Express route can crash the entire server unexpectedly. The fix is to always await async calls inside try/catch, attach .catch() handlers to promises you don't await, wrap async Express route handlers so their rejections call next(err), and add a global 'unhandledRejection' listener as a safety net for logging (not as a substitute for proper handling).

Trusting req.body, req.query, or req.params without validation opens the door to injection attacks (NoSQL/SQL injection), type-confusion bugs, crashes from unexpected shapes (e.g., calling .toLowerCase() on a number), and business-logic errors from malformed data. The fix is to validate and sanitize all incoming data at the boundary using a schema validation library (like Joi, Zod, or express-validator) before it reaches business logic, and to reject requests early with a clear 400 response when validation fails.

Without a centralized error-handling middleware (err, req, res, next), unhandled errors either crash the process, leak raw stack traces to clients (a security risk), or leave requests hanging without any response. The fix is to always register a final error-handling middleware after all routes that logs the error server-side, returns a sanitized, consistent error response to the client, and sets an appropriate HTTP status code — combined with async-safe route wrappers that forward errors to it via next(err).

A common mistake is using a plain object or Map as an in-memory cache that grows forever (e.g., caching per-user or per-request data with no eviction), or repeatedly calling .on() to register event listeners inside a function that runs many times (like per-request) without ever removing them — each call adds a new listener that's never garbage collected because the EventEmitter still references it. Over time, memory usage climbs until the process crashes or performance degrades. The fix is to use a bounded cache with an eviction policy (LRU, TTL) such as an lru-cache library, and to register listeners once at startup (or explicitly call .removeListener()/.off() when they're no longer needed), watching for Node's default MaxListenersExceededWarning as an early signal.

Hardcoded secrets end up committed to version control, visible to anyone with repository access, and often get baked into Docker images or client bundles — making rotation difficult and creating a serious security exposure if the repo is ever leaked or made public. The fix is to load secrets from environment variables (via a library like dotenv locally, and real secret managers or platform env config in production), never commit .env files, and add them to .gitignore from the very start of a project.

Running Node directly means that if the process crashes (from an uncaught exception, OOM, or unhandled rejection), nothing restarts it, causing downtime until someone notices and manually intervenes; it also provides no built-in log management, clustering, or zero-downtime restarts. The fix is to use a process manager such as PM2, or rely on your orchestration platform's restart policies (e.g., Docker's restart: always, or Kubernetes' pod restart behavior), which automatically restart the process on crash and can provide clustering, log rotation, and monitoring.

Without limits, express.json({ limit: ... }) and express.urlencoded({ limit: ... }) default to a modest size, but if increased carelessly or left unbounded, an attacker can send extremely large payloads to exhaust server memory or CPU parsing time, resulting in a denial-of-service condition. The fix is to explicitly set a reasonable body size limit appropriate to your API's real needs and reject oversized requests with a 413 status.

Mixing styles within the same function often leads to forgotten 'return' statements before promise chains, swallowed errors when a .then() chain isn't itself awaited or returned, and code that's harder to reason about and debug. The fix is to pick async/await consistently within a given function or module, always return promises you don't await so calling code can catch their rejections, and use try/catch around every await that can fail.