What NoSQL injection means
NoSQL injection occurs when untrusted input changes the structure or meaning of a database query. Review the path from the request parser to the executed filter, then verify that the application still enforces the caller’s permitted data scope. A database error, unusual response or suspicious key alone does not prove unauthorized access.
This guide focuses on MongoDB-style query objects in JavaScript applications. Other NoSQL databases use different languages and APIs. Examples below are deliberately narrow teaching examples, not a tested production patch or a personal customer incident.
PortSwigger’s NoSQL injection training distinguishes syntax injection from operator injection. That distinction helps frame the review: untrusted data can interfere with a query expression, or arrive as an object whose operators change matching behavior. The examples here address the second case without claiming to cover every injection class.
1. Trace the request through the actual parser
Write down the endpoint, supported content type, parser configuration and database/driver versions before interpreting a test. A string in a URL, a JSON object and repeated parameters do not necessarily become the same application value.
The Express request documentation treats request-body properties as untrusted and explains that middleware populates the body. Its query-parameter section also ties the resulting shape to the configured parser. Inspect the configuration you have rather than assuming bracket notation always produces a nested object.
For your record, keep four fields: submitted representation, parsed type, validated value and constructed filter. If those differ, explain the transformation. Avoid logging actual passwords, session tokens or complete sensitive requests merely to collect evidence.
2. Inventory every place that constructs a query
Include search, exports, administrative views and background jobs that consume saved user preferences. A login form is only one possible entry point. Choose review order from the sensitivity and reachability of the operation, not a fixed record-count threshold.
In an authorized code review, identify where input selects a field, operator, sort order or aggregation stage. Record whether an application-controlled mapping exists. A direct merge of an arbitrary client object deserves investigation; the code pattern alone does not establish the impact of an exploitable path.
3. Validate keys and values before constructing a filter
The OWASP NoSQL security guidance warns that a query object can still be unsafe when an untrusted field value is itself an operator object. It recommends field-specific validation rather than accepting raw client queries. Rejecting dollar-sign patterns alone does not establish allowed keys, types or authorization.
Define the interface first. For this example, an exact-title lookup accepts one nonempty string of at most 120 JavaScript code units. The length is an illustrative product limit, not a security standard. Objects, arrays, extra keys and empty titles are rejected. Literal operator-like text remains a string.
Illustrative filter builder: the trusted tenant identifier must already come from verified server-side authentication and membership authorization. It must never be copied from this request’s body, query or unverified header.
function buildNoteFilter(input, trustedTenantId) {
if(typeof trustedTenantId!=="string"||!trustedTenantId.trim())throw new Error("Missing trusted tenant");
if(input===null||typeof input!=="object"||Array.isArray(input))throw new Error("Expected object");
if(Object.keys(input).length!==1||!Object.prototype.hasOwnProperty.call(input,"title"))throw new Error("Expected title only");
if(typeof input.title!=="string"||!input.title.trim()||input.title.length>120)throw new Error("Invalid title");
return {tenantId:trustedTenantId,title:{$eq:input.title}};
}The function intentionally supports exact equality only. It does not implement login, authentication, database calls, pagination, error responses, Unicode normalization or a complete authorization policy. Adapt and test those requirements in the actual application; do not paste the function into production as a complete fix.
4. Treat casting and dropped filters as behavior to test
Mongoose’s query-casting documentation shows casting during query execution, optional removal of non-schema properties with strictQuery, and an alternative that throws on unknown properties. Removing every submitted filter can leave an empty object. The documentation also describes implicit array-to-$in behavior for certain non-array schema paths.
Check the installed version and configured options. Do not infer request validation from a database schema or assume every unexpected value fails in the same place. Include unknown fields, arrays, null, empty input and malformed values in the regression plan. Record whether rejection happens before any database call.
5. Enforce authorization independently of optional search
Ask two separate questions: is the requested filter supported, and may this identity access the matching records? A perfectly valid title filter can still expose another tenant’s data if the access boundary is missing.
OWASP’s authorization guidance recommends denying access by default and checking permissions on every request. In your own lab, verify the boundary with separate synthetic identities, including a user with no membership and a permitted user in another tenant.
In the example, the tenant condition is always added by application code. It cannot be replaced through a client field because extra fields are rejected. That design illustrates one boundary; it is not proof that the surrounding application authenticates identities correctly.
6. Build an observable practice exercise
Use a disposable environment you control or a training platform that authorizes the exercise. Use synthetic records, no production credentials and no shared customer data. A localhost URL alone does not describe the exposure of every container port, VM adapter or proxy.
Prepare two fictional tenants with a note titled Budget in each. Before testing, state the permitted result for each identity. Compare a valid request, rejected input types and an attempt to submit a tenant field. Confirm both the returned synthetic IDs and the constructed scope; an HTTP status alone is insufficient.
The isolated filter-builder checks for this article covered a valid title, operator object, array, null, extra tenant field, missing trusted tenant, whitespace-only title, overlong title and literal operator text. They checked returned filter objects and rejection behavior only. No Express route, MongoDB instance, driver, network service or end-to-end tenant boundary was exercised.
Use the practice catalogue template to record the exact version, authorization, question and verification status of a chosen training project. A catalogue entry is not a guarantee that an arbitrary downloaded image is appropriate for this exercise.
7. Report demonstrated impact and verify the repair
Use an evidence record containing the endpoint, identity context, synthetic baseline, changed input, observed scope, root-cause location, proposed repair and regression result. State what remains unverified. A hypothetical report can say: “The normal query returns tenant A’s synthetic note; the reproduced defect also returns tenant B’s synthetic note.” Use that wording only after observing it in the permitted environment.
Do not invent affected-record counts, incident costs or remediation hours. An internal endpoint can still have a serious access-control defect; internal reachability is one factor in triage, not permission to leave the defect uncorrected. WAF and rate controls may be additional layers, but their presence does not establish a safe application query.
Retest permitted functionality as well as rejection. Check for a missing authorization condition, empty-filter fallback or regression in another route. Agree on owner, priority and verification evidence from the actual findings rather than a universal “monitor versus fix” card.
Review checklist
This local checklist has no submission action or scanning capability. It is a documentation aid and does not certify a system as secure.
Common questions
Does using a driver prevent every NoSQL injection?
No. MongoDB’s fundamentals FAQ explains BSON query construction and separately warns about server-side JavaScript expressions. Avoid treating the absence of SQL string concatenation as proof that untrusted query structures are safe.
Does a changed response prove a vulnerability?
No. It may reflect parsing, validation, caching or an ordinary application error. Preserve a baseline and demonstrate the specific unintended behavior within scope.
How long should a review take?
Estimate from the actual endpoints, authorization model, environment and required evidence. This guide provides no reliable minutes-per-endpoint formula and no promised completion time.
What should I do next?
Choose one authorized endpoint and document the allowed inputs and permitted data scope before proposing tests. If either is unclear, resolve that uncertainty first.
Documentation checked October 16, 2026. This is a defensive review guide with illustrative code. It contains no personal client experience, independent production assessment or measured business outcome.