The SQL injection lessons attacked a relational database by concatenating text into a SQL string. This lesson attacks a document database - the kind that stores records as JSON-like objects and queries them with structured filters rather than text. For example, to find a document where _id equals "42", MongoDB uses the filter { _id: "42" } — the same idea as WHERE id = 42 in SQL, but expressed as a JavaScript object rather than a text clause. NovaCart uses the in-memory marsdb engine (a MongoDB work-alike) for its orders and product reviews.
A widespread myth holds that NoSQL databases are immune to injection because the query is an object, not a string. They are not. The query is still assembled from untrusted input, and an attacker who controls the shape of that input - not merely its characters - can change what the query means.
The OWASP Top 10 lists this finding, alongside SQL injection, at A03:2021 - Injection.
In this lesson you will:
- See how the product-review endpoint expects a single review identifier and how supplying a query operator object instead (
{ "$ne": -1 }) makes one request rewrite every review. - Understand the second sub-class, **
$whereinjection**: MongoDB's$whereclause accepts a JavaScript expression that the database engine evaluates to filter documents — meaning the database itself acts as a JavaScript runtime. An attacker who can control that expression can run arbitrary code inside the database. Caution: certain$wherepayloads are denial-of-service capable and will stall the server — practice$whereonly on a target you alone control, not the shared NovaCart instance. - Craft an operator-injection payload yourself.
- Learn why quote-escaping - the reflex defense against SQL injection - does nothing here, and why type and schema enforcement is the durable fix.
Estimated time: twelve to eighteen minutes.
Prerequisite: the embedded NovaCart application is running, and you have completed (or are comfortable with) authentication-login, sql-injection-data-extraction, and api-security. The api-security prerequisite is listed because the operator-injection payload is delivered inside a JSON request body (not a URL parameter) — you need to know how to read and edit a REST API request body. If you completed intercepting-proxies and can modify request bodies in the Network tab or Burp Suite, you are ready. An intercepting proxy or the browser DevTools Network tab is required to see and modify request bodies.
Course position: this is still an injection lesson, but the new skill is recognizing when a JSON field changed type or shape. The sink is the query-assembly step where user input determines the filter MongoDB evaluates. Later input-validation-output-encoding will generalize the boundary-validation pattern.
Authorization reminder: the $where denial-of-service payload genuinely stalls the worker that serves it. On the shared lab instance, practice only the operator-injection payload below, and reserve any denial-of-service experiment for a target you alone control. Running these payloads against a third-party application would constitute unauthorized access and is illegal in most jurisdictions.
When you are ready, send the Continue signal.