Express.js Interview Questions — Hard

Answer: Express uses an external library called path-to-regexp to compile string route definitions into JavaScript Regular Expression objects.

The Compilation & Matching Mechanics:

• When you register a route (e.g., app.get('/users/:id')), Express compiles it and instantiates a new Layer object.
• This Layer object holds:
  • The path execution function (the handler or middleware).
  • A compiled regular expression (e.g., /^\/users\/([^\/]+?)\/?$/i).
  • An array of keys containing details about the dynamic route parameters (e.g., [{ name: 'id', optional: false, offset: 0 }]).
• Request Resolution: When a request comes in, Express iterates sequentially through its routing stack. For each layer:
  1. It executes the layer's regular expression against req.path.
  2. If it matches, it extracts parameter matches from the capture groups of the regex and populates the req.params object using the stored keys array.
  3. If it doesn't match, it skips the execution callback and proceeds to the next layer in the stack.

---

Answer: By default, Express reads connection metadata directly from the incoming socket (the immediate connection).

• The Problem: When hosted behind Nginx or an Application Load Balancer, the direct client connecting to your Node.js process is the proxy server itself, not the actual user. Consequently, req.ip will return the proxy's local IP (e.g., 127.0.0.1 or 10.0.x.x), and protocol features (like req.secure) will be false because the SSL termination happens at the load balancer.
• The Solution: Enabling trust proxy instructs Express to respect standard forwarding headers:
  • X-Forwarded-For: Contains the chain of client and intermediate proxy IPs. Express will parse this and correctly populate req.ip with the actual user's IP.
  • X-Forwarded-Proto: Indicates whether the user connected via http or https. This ensures req.secure works, which is critical for configuring secure cookies (secure: true).
• Security Risk: Never blindly trust proxies if you are exposed to the raw internet without a proxy frontend, as clients can easily spoof these headers to mask their identity or bypass IP-based rate limits.

---

Answer: To prepare an Express app for production, several security vectors must be locked down:

1. Helmet (helmet): A middleware collection that sets various security-focused HTTP response headers:
   • Content-Security-Policy (CSP): Mitigates Cross-Site Scripting (XSS) and code injection attacks.
   • X-Frame-Options: Prevents Clickjacking by disallowing the site from being rendered inside an <iframe>.
   • Strict-Transport-Security (HSTS): Forces secure (HTTPS) connections.
   • X-Content-Type-Options: Disables MIME type sniffing (prevents executable style/script injections).
2. CORS (Cross-Origin Resource Sharing): Restrict which external domains can read resources from your API. Never leave CORS set to * for authenticated APIs that use cookies or authorization headers.
3. HPP (HTTP Parameter Pollution): Prevents query parameter pollution attacks. If a malicious client passes ?id=123&id=456, Express parses req.query.id as an array ['123', '456']. If your application code expects a string, this can cause runtime crashes or SQL/NoSQL logic injections.
4. JSON Body Limits: Restrict request body size in parser configurations:

   app.use(express.json({ limit: '10kb' })); // Prevents heap exhaustion via massive payloads (DDoS)
   

---

Answer: Rate limiting restricts the number of requests a client can make in a specified window of time.

• The Memory Trap: Using a basic, local, in-memory store in Express is fine for single-instance, local developments. However, in production, applications are typically clustered across CPU cores or scaled horizontally across multiple servers (or Docker containers).
• The Problem: In-memory trackers are isolated to each individual server instance. If a client is hitting a load-balancer, their requests will be distributed across instances, making it easy for them to bypass their limit.
• The Distributed Solution: Use an external, atomic key-value cache like Redis as a centralized rate-limit store.
  • Every server instance queries Redis during incoming requests to increment and check the client's rate-limiting keys.
  • Using Redis scripts or transaction blocks (e.g., MULTI/EXEC or Lua scripts) guarantees that checking and incrementing limits is an atomic operation, preventing race conditions when requests hit multiple nodes simultaneously.

---

Answer: next(err) unwinds the CURRENT router's stack first; finding no 4-arity handler there, Express hops to the parent app's stack - eventually reaching the top-level error middleware. Implications:

• Router-scoped error handlers catch only errors raised within their own mount; mounting order defines reachability (app.use('/api', apiRouter) then later global handler).
• Synchronous throws in handlers ARE routed by Express to error chain; async rejections in Express 4 are NOT - they crash or hang unless wrapped (asyncHandler). Express 5 forwards rejected promises natively - still wrap for uniform enrichment.
• Errors thrown INSIDE error handlers fall back to Express's final default handler (HTML stack trace in dev!) - guard your handler.
• Streaming/response-started errors can't change status codes - destroy socket or log-only; attempting res.status after headers triggers ERR_HTTP_HEADERS_SENT noise.