Potential fix for code scanning alert no. 188: Database query built from user-controlled sources #3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.

Potential fix for https://github.com/mirkashi/LMS/security/code-scanning/188
In general, to fix this kind of issue for MongoDB/Mongoose, ensure that user-provided values used in query filters are treated as literals, not as query sub-objects. Two standard approaches are: (1) validate that the inputs are primitive values (e.g., strings) before using them in a query; or (2) wrap them in
$eq, so MongoDB interprets them as literal values even if they are objects.The best fix here, without changing existing functionality, is to enforce that
statusandcourseIdare safe primitive values before putting them intofilter. Sincestatusis likely an enum-like string andcourseIdis a Mongoose ObjectId string, we can:status: ensure it is a string and (optionally) restrict it to allowed status values.courseId: ensure it is a string, and optionally check it matches the ObjectId format (24 hex chars).To stay minimal and not assume additional models/helpers, we will:
typeof status === 'string'before settingfilter.status.typeof courseId === 'string'before settingfilter.course.This guarantees that
filterwill never contain attacker-supplied query objects; only strings will be used. If the checks fail, we simply skip applying that filter, preserving current behavior as much as possible while avoiding NoSQL injection via operator objects.Concretely, in
backend/controllers/adminController.js, inexports.getAllEnrollments, we will replace:with:
and adjust the subsequent line numbers accordingly. No new imports or external libraries are required.
Suggested fixes powered by Copilot Autofix. Review carefully before merging.