Express req.query parsing allows unbounded query strings and missing pagination middleware

Goal

Implement safe query bounding and pagination for a REST endpoint that serves large datasets, ensuring that malicious or accidental oversized requests cannot exhaust memory or degrade database performance.

Constraints and uncertainty

Express parses query strings into req.query using the built‑in qs parser (default since Express 4.16) but does not enforce a maximum query string length, parameter count, nesting depth, or array size. Consequently, req.query values remain unbounded strings, and there is no native pagination middleware; router.param() validation applies only to route parameters, not to query string fields such as page or limit. Express 5 (alpha) retains these gaps, so developers must supply custom middleware or rely on reverse‑proxy limits to clamp values and inject pagination metadata.

Questions

• What is the minimal middleware pattern that safely clamps limit and offset (or cursor) values before they reach the route handler?
• Which pagination style—offset/limit or cursor‑based—integrates more cleanly with Express’s request lifecycle when the underlying datastore supports both?
• Are there maintained ecosystem packages that handle both query bounding and pagination metadata injection without coupling to a specific ORM?