Aigent.ly
express-security-patterns-v1Certifiedv1.0.0

Express / Node.js security patterns

Always-on secure coding patterns for Express / Node.js (safe; no dependency edits).

Authorization & Access ControlSecrets & CredentialsInput Validation & SanitizationAuthentication & Session

Protects against

CVE-2020-28500CVE-2021-23337CVE-2022-23539CVE-2022-23540CVE-2022-23541CVE-2022-24304CVE-2022-2564CVE-2023-22578CVE-2023-22579CVE-2023-22580CVE-2023-25813CVE-2023-3696CVE-2024-10491CVE-2024-29041CVE-2024-45590CVE-2024-53900CVE-2025-13465CVE-2025-13466CVE-2025-23061CVE-2025-47935CVE-2025-47944CVE-2025-48997CVE-2025-7338CVE-2026-2359CVE-2026-2950CVE-2026-30951CVE-2026-3304CVE-2026-3520CVE-2026-42334CVE-2026-4800

Rule body

# Express / Node.js security patterns

Safe, always-on code patterns that reduce security risk without changing your dependency graph.

These rules use ONLY pattern-level verbs (ALWAYS/NEVER). They MUST NOT prescribe dependency upgrades.

### CVE-2023-25813 — safe patterns

- NEVER mix literal() SQL fragments with replacements in the same query.
- ALWAYS use parameterized query methods exclusively or literal SQL exclusively, never both.
- NEVER use user input directly within literal() SQL strings, even with replacements defined.

### CVE-2023-22578 — safe patterns

- NEVER pass user input or dynamic values inside parenthesized attribute arrays to Sequelize.
- ALWAYS use Sequelize's safe methods like sequelize.fn() and sequelize.col() for computed columns.
- NEVER rely on string concatenation in parenthesized attributes even with concatenated static values.
- ALWAYS validate that attribute definitions only reference static column names without function calls.

### CVE-2023-3696 — safe patterns

- NEVER directly merge or deep-assign untrusted user input to query objects or schema definitions.
- ALWAYS validate and sanitize object keys before using them in property assignments.
- NEVER use recursive object operations on user-supplied nested structures without whitelisting allowed properties.

### CVE-2022-24304 — safe patterns

- NEVER pass unsanitized user input directly to schema path methods.
- ALWAYS validate schema path names against a whitelist of expected property names.
- NEVER allow nested property paths in schema definitions without strict validation.

### CVE-2025-23061 — safe patterns

- NEVER use the $where operator in query construction, even with parameterized values.
- ALWAYS use standard MongoDB query operators (find, match, filter) instead of $where for conditional logic.
- NEVER pass user input to $where or eval-like query methods without complete rejection.

### CVE-2023-22579 — safe patterns

- NEVER pass non-object values to the where option in query builders.
- ALWAYS validate that where clause arguments are plain objects before passing to finder methods.
- ALWAYS treat silently ignored filters as potential security gaps and add runtime assertions.

### CVE-2022-23539 — safe patterns

- ALWAYS verify that the key type matches the intended signing algorithm (e.g., EC keys with ES256, RSA keys with RS256).
- NEVER accept arbitrary key types during JWT verification without explicit validation of key-algorithm compatibility.
- ALWAYS reject or warn on DSA, HMAC, or other legacy key types when using asymmetric algorithms like RS256 or ES256.

### CVE-2021-23337 — safe patterns

- NEVER pass user-controlled input directly to template functions.
- ALWAYS compile templates from static, trusted code only.
- NEVER use template delimiters that process JavaScript expressions from external sources.

### CVE-2026-4800 — safe patterns

- NEVER construct _.template options.imports keys from untrusted input.
- ALWAYS validate and allowlist key names before adding to template imports.
- NEVER use user-controlled data as import names without sanitization.

### CVE-2022-2564 — safe patterns

- NEVER pass unsanitized user input directly to Schema.path() method calls.
- ALWAYS validate and restrict schema path keys to expected property names only.
- NEVER allow user-controlled data to define nested paths using dot notation like '__proto__' or 'constructor.prototype'.

### CVE-2025-47944 — safe patterns

- ALWAYS wrap multipart form parsing in explicit error handlers to catch and gracefully handle malformed requests.
- NEVER assume multipart parsing will always succeed without exception handling.
- ALWAYS validate that request Content-Type and boundaries are well-formed before processing uploads.

### CVE-2025-48997 — safe patterns

- ALWAYS validate that form field names are non-empty strings before processing uploads.
- NEVER rely on multer alone to handle all upload field name edge cases without application-level validation.
- ALWAYS implement try-catch or error handlers around multipart form parsing to prevent unhandled exceptions.

### CVE-2025-47935 — safe patterns

- ALWAYS explicitly close or destroy parsing streams when handling request errors.
- NEVER rely on garbage collection alone to clean up multipart upload streams.
- ALWAYS attach error handlers to parsing streams before forwarding data streams.

### CVE-2025-7338 — safe patterns

- ALWAYS wrap Multer middleware with explicit error handling to catch and log exceptions.
- NEVER assume Multer will gracefully ignore malformed multipart request bodies.
- ALWAYS implement middleware-level error handlers that catch unhandled exceptions from file upload processing.
- NEVER rely on default error handling for parsing failures in multipart form data.

### CVE-2024-53900 — safe patterns

- NEVER construct $where clauses with unsanitized user input or string concatenation.
- ALWAYS validate and sanitize all query parameters before use in database operations.
- NEVER use $where when query operators like $eq or $in can express the same logic safely.

### CVE-2026-3304 — safe patterns

- ALWAYS validate multipart request headers before processing file uploads.
- NEVER assume file cleanup completes successfully without explicit error handling.
- ALWAYS implement timeouts and resource limits on file upload handlers.
- NEVER process unbounded multipart streams without field size and file count restrictions.

### CVE-2026-2359 — safe patterns

- ALWAYS implement connection drop handlers in file upload middleware to release temporary resources.
- NEVER rely solely on request completion to clean up partial uploads or temporary files.
- ALWAYS set appropriate timeouts for upload operations to prevent indefinite resource holding.
- NEVER allow concurrent uploads without limits that could compound resource exhaustion.

### CVE-2026-3520 — safe patterns

- NEVER pass untrusted or user-supplied boundary delimiters without validation to multipart parsers.
- ALWAYS implement request size and depth limits before parsing multipart form data.
- ALWAYS use timeouts on file upload handlers to prevent indefinite processing of malformed payloads.

### CVE-2026-30951 — safe patterns

- NEVER use JSON/JSONB column accessors with user-supplied or dynamic keys in where clause filters.
- ALWAYS validate and allowlist any cast type names derived from object keys before using them in SQL expressions.
- NEVER concatenate or interpolate cast type identifiers directly into CAST() SQL expressions.

### CVE-2026-42334 — safe patterns

- NEVER assume logical operators like $nor are automatically sanitized by sanitizeFilter.
- ALWAYS explicitly sanitize nested array contents within logical operators.
- NEVER pass unsanitized user input directly to query operators that accept array arguments.