PortSwigger Writeup: Detecting NoSQL Injection

1. Detecting NoSQL Injection

Hey everyone! Today I want to share a walkthrough on how to solve one of PortSwigger's apprentice-level challenges: Detecting NoSQL injection. In this lab, our goal is to find a vulnerability in the product category filter that runs on a MongoDB database and manipulate it so it forces the system to display all the hidden, unreleased products.

Let's dive straight into it.

Step 1 : The very first thing we need to do is open up the lab page on PortSwigger. The description explicitly tells us that the product category filter is powered by a MongoDB NoSQL database which happens to be vulnerable to NoSQL injection.

From there, just click the "Access the lab" button to head over to the simulated online shop. On the main page, you will notice a few category menus at the bottom of the shop's header.

Step 2 : To play around with the data, we need some help from Burp Suite. Turn on your browser's proxy and click on any available category on the page — for this example, I went with the "Corporate gifts" category.

Now open Burp Suite, head over to the Proxy tab, and select HTTP history. Look for the most recent request pointing to that specific category filter endpoint. Once you spot it, right-click and choose "Send to Repeater" so we can start tweaking the code manually.

Switch over to the Repeater tab. Before changing anything, it's a good habit to hit the Send button just to make sure the request we captured responds normally and returns a clean baseline.

Step 3 : To test if this category parameter is actually vulnerable to a NoSQL injection, we can try injecting a single quote character (') right at the end of the category name in the first line of our request. I tried changing the parameters to look like this, then hit Submit:

GET /filter?category=Corporate+gifts' HTTP/2

As you can see on the right column, the system immediately drops an Internal Server Error showing a detailed SyntaxError message from the backend MongoDB script. This blatant error message is solid proof that user input is being executed directly without any safe filtering.

Step 4 : Because we know the application is vulnerable, we can leverage the OR operator logic to ensure that the query condition in the database always evaluates to TRUE, forcing all hidden product data to be released. However, if we directly type the raw payload, as in the example below, the system sometimes only interprets it as plain text, leading to the lab not being completed.

To ensure the payload is correctly read as a code instruction by the database, we need to URL encode these special characters. To do this, simply type the full payload, highlight the text, and press Ctrl+U to convert it to a secure URL. Then, click the Send button.

As soon as the Send button is pressed, the status on the Render tab immediately changes to LAB Solved, accompanied by an orange banner displaying congratulations on the successful completion of the lab. If we check back on the main page of the online store browser, the same success banner will appear at the top of the screen.

That's it! We've successfully completed the Detecting NoSQL Injection lab by exploiting a syntax error leak in a MongoDB database. We hope this post was helpful, and see you in the next challenge write-up!