NoSQLMap: auditing MongoDB and CouchDB targets from a menu or a script

What NoSQLMap is for, and who actually needs it

NoSQLMap targets a gap that sqlmap does not cover. The README describes it as an open source Python tool built to audit for and automate injection attacks against NoSQL databases and web applications using NoSQL, with the goal of disclosing or cloning data from the database. The name is a deliberate tribute to sqlmap, and the concepts trace back to Ming Chow's Defcon 21 talk "Abusing NoSQL Databases", which the README credits as the origin.

The audience is narrow and specific. This is a tool for penetration testers and bug bounty hunters working against MongoDB or CouchDB, either through an exposed management port or through a web application that builds queries from user input. It is not a general database scanner, and it is not a library you would embed in a CI pipeline. The README states plainly that exploits are focused around MongoDB and CouchDB, with Redis and Cassandra support described as planned for future releases. Anyone pointing it at Redis today is using a tool that does not claim to handle it.

Two attack surfaces: management ports and web application parameters

The tool splits its work into two distinct modes, and the split is the most useful thing to understand before running it. The main menu offers NoSQL DB Access Attacks, NoSQL Web App attacks, and a separate Scan for Anonymous MongoDB Access option. DB access attacks assume you can reach the database's own management port. Web app attacks assume you cannot, and instead go after the application layer.

The web application path works by injecting into URI parameters. The options menu asks for a target host or IP, a web app port, a URI path that contains the page name and parameters but not the host (the README's example is /app/acct.php?acctid=102), and an HTTP request method. That last one carries a real limitation the README admits: only GET is implemented, with POST requests exported from Burp described as work in progress. There is a Burp integration point, but it works in the other direction. Option 8 loads options from a saved Burp request and parses it to populate the web app settings. So you can seed NoSQLMap from Burp, but you cannot yet replay a POST through it.

For direct database attacks, the options include a local Mongo or shell IP to clone victim databases to, and a shell listener port for Meterpreter sessions. Both imply a local, default MongoDB instance is available as the destination, which the requirements section lists separately.

Installing NoSQLMap and running a first web app injection

The README gives a setup.sh script for Debian and Red Hat systems, run as root, to automate dependency installation. The manual path is setup.py install, and there are two container paths. Building the image directly uses docker build -t nosqlmap ., and Docker Compose uses docker-compose build followed by docker-compose run nosqlmap. The Dockerfile is based on python:2.7-alpine and pins requests<2.28 and certifi<=2020.4.5.1 on top of what setup.py install brings in.

If you install from setup.py rather than the image, the dependency pins come from that file: CouchDB==1.0, httplib2==0.19.0, ipcalc==1.1.3, pbkdf2==1.3, pymongo==2.7.2, and requests<2.28. Note that the package also lists NoSQLMap==0.7 in its own install_requires, which is unusual and worth watching for during resolution.

Once installed, the interactive entry point is the script itself:

python NoSQLMap

That prints the main menu with options 1 through 4 and x to exit. Option 1 sets options and the README says to do this first. Option 4 scans for anonymous MongoDB access, which is the fastest way to find out whether a target is worth pursuing at all.

The repository also ships an intentionally vulnerable application under vuln_apps for testing against. From that directory, the README gives:

docker-compose build && docker-compose up

After that completes, the README says the application is reachable at https://127.0.0.1:8080/index.html. The port and the https scheme are as written in the README.

The CLI can be scripted instead of driven through the menu. The README's example runs a web app attack against the vulnerable app's account lookup page:

docker-compose run --remove-orphans nosqlmap \
    --attack 2 \
    --victim host.docker.internal \
    --webPort 8080 \
    --uri "/acct.php?acctid=test" \
    --httpMethod GET \
    --params 1 \
    --injectSize 4 \
    --injectFormat 2 \
    --doTimeAttack n

The same pattern is repeated in the README against /userdata.php?usersearch=test and /orderdata.php?ordersearch=test, both labelled as JavaScript injection cases. The flags are positional in effect: --attack selects the mode, --victim and --webPort locate the target, --uri carries the injectable parameter, and --injectSize, --injectFormat and --doTimeAttack control how the payload is shaped and whether timing is used. Expect the tool to report findings per parameter rather than a single pass or fail.

The Python 2.7 dependency is the constraint that shapes everything else

The README's badge line declares Python 2.6 and 2.7. The Dockerfile confirms it by starting from python:2.7-alpine. Python 2 reached end of life in 2020, so this is not a cosmetic detail. It means you cannot install NoSQLMap into a modern Python 3 virtualenv and expect it to work, and it means the pinned dependencies (pymongo 2.7.2, requests below 2.28) are frozen at versions that predate a lot of current library behaviour. The Dockerfile even appends Alpine 3.9 repositories to get a MongoDB package, which tells you the image is built against an older package set.

There is a second-order consequence. Because the tool pins requests<2.28 and certifi<=2020.4.5.1, running it against a target with a modern TLS configuration can fail at the transport layer before any injection is attempted. That failure looks like a clean scan. This is the most likely way to get a false negative out of NoSQLMap, and the README does not document it.

The release history reinforces the picture. The most recent release listed is 0.5 from 2016-01-11, while setup.py declares version 0.7. The repository has been pushed to more recently than the last tagged release, so development has continued without cutting a release, but there is no changelog describing what changed between 0.5 and 0.7.

Where NoSQLMap is the wrong tool

Three cases stand out. First, non-MongoDB and non-CouchDB targets. Redis and Cassandra are named as future work, so pointing NoSQLMap at either is outside what the tool claims. Second, POST-based web application testing. The README states only GET is implemented, which rules out a large share of modern APIs where the injectable parameter arrives in a JSON body. Burp request import gets your options populated, but the request method still has to be GET for the attack to run.

Third, and less obviously, any engagement where you need to run from a standard modern workstation. The Python 2.7 requirement and the pinned transport libraries make the Docker route the only reliable one, and that route pulls an Alpine 3.9 based image with its own MongoDB package. If your environment forbids old base images, NoSQLMap is not a tool you can adapt around; you would be rewriting it.

There is also a coverage question the README does not answer. It does not document rollback, it does not document how the database cloning destination is validated, and it does not describe what happens when the local Mongo instance the requirements section calls for is absent. Those are gaps you should probe in a lab before running against anything you care about.

How it compares to sqlmap, and why the comparison is not close

The natural alternative is sqlmap, and the README itself makes the link: NoSQLMap is named as a tribute to Bernardo Damele and Miroslav Stampar's tool. The difference in approach is the injection grammar. sqlmap builds SQL fragments and reasons about SQL syntax, error signatures and boolean responses. NoSQLMap works against document stores where the injectable surface is JavaScript evaluation and query operator injection rather than SQL. The README's own vulnerable app examples are labelled JavaScript injection, which is the tell.

That means the two tools are not substitutes. If your target builds a SQL string, sqlmap is the right instrument and NoSQLMap has nothing to offer. If your target passes user input into a Mongo query or an eval-style handler, sqlmap's payloads are the wrong shape. The practical answer for a full engagement is both, run against different parts of the same application, which is also why the Burp import option exists: it lets you hand a request from one workflow into NoSQLMap's option set without retyping the URI and port.

The other comparison worth making is against doing it by hand. NoSQLMap's value is the wizard-driven payload generation and the anonymous MongoDB access scan, which turns a port sweep into a quick answer. If you only need to check whether an exposed Mongo instance accepts unauthenticated connections, the scan option alone justifies keeping the container around.

Licence and the cost of keeping it running

NoSQLMap is GPL-3.0, and the repository carries the COPYING file. For internal penetration testing that is unproblematic. If you were to modify NoSQLMap and distribute the result, or bundle it into a product you ship, the GPL's copyleft terms apply to the derived work. This is a description of the licence, not legal advice; if you plan to redistribute anything built on it, get a lawyer to read the terms rather than a tool review.

The upgrade cost is the more immediate concern. setup.py declares version 0.7 while the newest release listed is 0.5 from January 2016, so there is no release artifact to track. Updating means pulling the master branch and rebuilding the image, and because the Alpine repositories and the dependency pins are hardcoded in the Dockerfile and setup.py, a rebuild can break when those upstream URLs move. Budget for the image build failing and needing the repository lines in the Dockerfile adjusted. The last push to the repository was on 2026-07-28, so the code is not abandoned, but the release and packaging story has not kept pace with the commits.

Editorial conclusion

Adopt NoSQLMap if you are auditing an internal MongoDB or CouchDB deployment and can keep a Python 2.7 container around for it. Do not adopt it for Redis or Cassandra targets, for POST-based web application testing, or for anything you intend to run on a modern Python interpreter without a container. Verify first that setup.py resolves its pinned dependencies (CouchDB==1.0, pymongo==2.7.2, requests<2.28) inside the base image you plan to use, and confirm the target's management port is actually reachable from your position before assuming a null result means the instance is closed.

Frequently asked questions

Official sources

1. codingo/NoSQLMap on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases