Express

Split HTTP request processing into routing and composable middleware

Express centers on routing by HTTP method and path plus middleware that processes requests and responses in sequence. The README highlights robust routing, HTTP helpers, content negotiation, and view-system support. Authentication, logging, validation, sessions, static files, and API endpoints can be separated into middleware, keeping transport concerns distinct from application business logic.

Express does not force a specific ORM or template engine. Teams add capabilities through middleware and packages, which makes it a practical fit when the application needs a thin HTTP layer rather than a framework that dictates the entire stack.

Sources: [2]

Let Express 5 route rejected Promises from async handlers into error handling

Express 5 can route rejected Promises returned by route handlers and middleware into its error flow. Errors thrown from async functions therefore require less manual try/catch and next(error) boilerplate than in Express 4.

Custom error handlers still use the dedicated (err, req, res, next) middleware signature and are normally placed after other middleware. Response policy, logging, and prevention of sensitive-data leakage remain application responsibilities.

Sources: [6][5]

Use the same core for APIs, server-rendered sites, and hybrid Node.js backends

The README positions Express for single-page applications, websites, hybrids, and public HTTP APIs. Response helpers, redirects, caching, static-file handling, content negotiation, and integration with many template engines mean it is not limited to JSON APIs.

Because database access, validation, authentication, and observability are selected from the Node.js ecosystem rather than prescribed by Express, teams can tailor the stack and can also introduce Express only as the routing layer in an existing Node application.

Sources: [2]

A fit for Node.js APIs and web backends that want explicit routing and incremental middleware composition

Express fits REST/JSON APIs, BFFs, server-rendered applications, and smaller services where teams want to assemble the HTTP layer explicitly. It is especially attractive when a team prefers a thin abstraction close to Node.js HTTP semantics and wants freedom to choose database, validation, authentication, and other packages independently.

Express 5 requires Node.js 18+ and is not a drop-in major upgrade from Express 4

Express 5 requires Node.js 18 or newer. The migration guide says the basic API remains familiar but includes compatibility-breaking changes. APIs such as app.del() and req.param() and older res.send()/res.json() signatures were removed, while route path matching syntax also changed. Use the official codemods and automated tests rather than treating the upgrade as a dependency-only change.

Static-file behavior changed as well: dotfiles and hidden directories are handled more strictly by express.static() and res.sendFile(). Applications serving paths such as .well-known should explicitly verify their file-serving policy during migration.

Sources: [5][2]

Minimalism leaves security, validation, authentication, and rate limiting largely to the application stack

Express core focuses on routing and HTTP helpers; it does not automatically provide complete input validation, authentication and authorization, CSRF defenses, rate limiting, secure-cookie policy, or TLS termination. The official production security guidance separately calls out TLS, input validation, secure cookies, and dependency security.

Production security also depends on settings such as trust proxy, redirect targets, file paths, request-body limits, and session storage. Middleware selection alone is not a complete security model; reverse-proxy and application boundaries need to be designed together.

Sources: [7][2]

Read release notes and advisories separately: 5.2.1 reverted a 5.2.0 query-parser breaking change

Express 5.2.1 is a patch release that reverted an erroneous breaking change in the extended query parser introduced in 5.2.0. Its release notes explicitly state that the behavior was not an actual security vulnerability and that CVE-2024-51999 was rejected. Security-looking changes should therefore be evaluated from the official release note and advisory context rather than from a CVE identifier alone.

Express assembles HTTP behavior from multiple dependencies. Production maintenance should track the lockfile and transitive dependencies in addition to the top-level Express version.

Sources: [4][3]