Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add `express-mongo-sanitize` / operator stripping to the global middleware chain

Open
  • Is something wrong?
#277 1 comment 0 reactions 0 assignees View on GitHub

@shobhamerabacha-star is already working on this.

Since Oct 9, 2026.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
elasticsearch, express, mongodb, nodejs, typescript
Domain
api, backend, security

Research direction

Start with the audit: check each query call in src/core/auth/auth.service.ts, traditional.strategy.ts, src/core/user/user.service.ts and src/search/search.service.ts to see whether its where value can come from unvalidated input. Then add app.use(mongoSanitize()) in src/main.ts before SanitizePipe and the validation pipe. Done means the audit is recorded in the issue, any unvalidated path is fixed or linked to its own bug, and a test shows a { "email": { "$ne": null } } payload is rejected while nested query parameters still work.

Written by the indexing model from the issue text.

Description

help wanted intermediate security

Problem

src/main.ts builds a global hardening chain — helmet (line 60), SanitizePipe (75), createGlobalValidationPipe() (76), CORS (80) — but nothing strips MongoDB/NoSQL query operators from incoming parameters.

express-mongo-sanitize@^2.2.0 is already in dependencies for exactly this, and is not imported anywhere in src/.

The relevant attack: an endpoint passing request parameters into a query builder can be given {"email": {"$ne": null}} instead of {"email": "..."}, turning an equality check into a match-anything. SanitizePipe (src/common/pipes/sanitize.pipe.ts) uses class-sanitizer, which strips HTML for XSS — it does not address operator injection.

The global ValidationPipe helps, because whitelist: true and forbidNonWhitelisted: true reject properties not on the DTO. But that protection only applies where a DTO class is used. Any handler taking a raw @Query() x: any or a plain object bypasses it entirely — and this codebase has such handlers (see the pagination-bounds and file-upload issues).

Why it matters

Whether this is exploitable today depends on whether any query path passes unvalidated input into a TypeORM or Elasticsearch query. That is exactly what needs verifying, because the answer determines severity:

  • If all query paths use DTOs, this is defence in depth.
  • If any pass raw objects through, it is a live authentication-bypass-class vulnerability — notably for login, where {"email": {...}} could match any user.

Suggested Direction

  1. Audit first. For each repository .find()/.findOne()/query-builder call, determine whether the where value can come from an unvalidated request parameter. Prioritise auth (src/core/auth/auth.service.ts, traditional.strategy.ts), user lookup (src/core/user/user.service.ts), and search (src/search/search.service.ts, which passes a raw string into an Elasticsearch multi_match).
  2. If a vulnerable path exists, that is the real fix — it warrants its own high-priority bug issue, and this issue should link to it. Do not let the hardening issue substitute for the underlying bug.
  3. Add the middleware as defence in depth: 
    app.use(mongoSanitize());
    placed before SanitizePipe and the validation pipe, in src/main.ts.
  4. Also check the search path specifically. Elasticsearch is not MongoDB, so express-mongo-sanitize will not cover it. search.service.ts builds a multi_match query from a raw string — verify the query DSL cannot be influenced by request structure, not just the string value.

Constraints

  • express-mongo-sanitize had periods of unmaintained status — confirm 2.2.x is current and Express 5 compatible before relying on it.
  • Mutating req.query in place can surprise code that reads it later; test that legitimate nested query parameters still work.
  • Do not treat this as sufficient on its own. DTO validation with whitelist is the primary control; this is a backstop.

Acceptance Criteria

  • Every query-building path is audited, with the result recorded in the issue.
  • Any path passing unvalidated input into a query is either fixed or linked to its own bug issue.
  • Operator-stripping middleware is applied globally ahead of validation.
  • A test asserts a payload like { "email": { "$ne": null } } is rejected.
  • Legitimate nested query parameters still work — assert this too.
Dominant language
TypeScript
Stars
7
Forks
55
Avg merge
1d 17h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SourceXXL/alian_structure-api

All issues in SourceXXL/alian_structure-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.