NoSQL Injection in Bug Bounty: How to Find and Prove Impact

NoSQL Injection in Bug Bounty: How to Find and Prove Impact

NoSQL injection happens when an application treats attacker-controlled JSON or query parameters as database operators instead of plain values. In 2026 this still shows up in login handlers, search APIs, filters, and SSO callback code that expects a string but accepts an object.

This guide is for authorized testing only. Use test accounts and prove impact with your own data — never dump other users' records.

Why hunters still miss it

Many teams sanitize SQL quotes and stop there. MongoDB-style APIs accept operators such as $gt, $ne, $regex, and $where. If the server does findOne({ token: req.body.token }) and token is an object, the database may match the first document that satisfies the operator.

TypeScript type annotations do not protect you at runtime. The bug is in the trust boundary between HTTP input and the query layer.

Map injectable sinks

Look for:

• Login, MFA, password-reset, and SSO ticket endpoints
• Search and filter APIs that accept nested JSON
• GraphQL arguments that become Mongo filters
• Mobile or SPA clients that send JSON bodies the server trusts
• “Options” objects forwarded into find, findOne, update, or aggregation pipelines

Capture a normal request, then change one field from a string to an object while keeping everything else identical.

Safe proof workflow

1. Create two test users and a unique canary string owned by account A.
2. On a candidate parameter, replace the string with a minimal operator such as {"$gt": ""} or {"$ne": null}.
3. Confirm the response differs in a controlled way — for example, returning account A's canary when you authenticated as B, or skipping a ticket check for your own session.
4. Stop as soon as identity confusion or authorization bypass is proven. Do not walk the whole collection.

A strong report shows: original typed value, injected operator, exact request, and the security boundary that failed.

High-value targets

• Pre-auth login using opaque tickets or credential tokens
• Account linking / SSO where the ticket is looked up without a type check
• Multi-tenant filters where tenantId can be replaced by an operator
• Password reset tokens stored in NoSQL and redeemed by query

Auth bypass and cross-tenant reads pay more than a noisy regex DoS. Prefer identity impact over resource exhaustion.

Common false positives

• Client-side validation only (server still coerces to string)
• ORM helpers that reject non-scalars
• Errors that reveal operator names but never change authorization
• Timing differences without a concrete data or session impact

How to write the report

Include the query-shaped input, the expected type, the matched document class (your canary), and the resulting privilege. Mention CWE-943 style logic if it helps triage. Suggest fixing with strict schema validation (for example Zod/Joi), rejecting objects on scalar fields, and casting IDs to strings before querying.

Defensive checklist

• Validate request bodies with a schema that forbids unexpected objects.
• Never pass raw req.body into database filters.
• Cast and allowlist field types at the repository boundary.
• Use parameterized builders that do not interpret $ operators from clients.
• Add regression tests that send operator objects to auth and search endpoints.

NoSQL injection is still a high-intent search topic because modern apps speak JSON end to end. If the database understands operators, your API must refuse them from clients.

Original Bugflare guide informed by OWASP NoSQL injection testing guidance.