Enumerate and Escalate: Pentest Juice Shop

Exploit IDOR and privilege escalation vulnerabilities in OWASP Juice Shop.

Introduction

30 Second Summary

Every web application has hidden doors, and a penetration tester's job is to find them before an attacker does.

In this project, you will conduct a structured penetration test against OWASP Juice Shop, a deliberately vulnerable web application. You will enumerate hidden endpoints, exploit Insecure Direct Object References (IDORs) to access other users' data, and escalate your privileges from a regular customer all the way to administrator.

What You'll Build

You will execute a full reconnaissance-to-exploitation pentest workflow against a locally hosted Juice Shop instance, using Burp Suite as your intercepting proxy to capture and manipulate HTTP traffic.

By the end of this project, you'll have:

Discovered hidden endpoints including the Score Board and admin panel by analyzing JavaScript source code.
Exploited IDOR vulnerabilities and mass assignment attacks to escalate from a regular customer to a full administrator.
Forged feedback and tampered with product data using HTTP method manipulation to demonstrate post-exploitation impact.
Chained multiple attack techniques together into a realistic pentest attack narrative using HTTP parameter pollution and method switching.

Are there any prerequisites?

You should have basic familiarity with Burp Suite (intercepting and modifying requests), an understanding of HTTP requests and responses, and experience using browser DevTools. You will also need Docker installed on your machine to run Juice Shop locally.

Launch Juice Shop and Configure Burp Suite

Before you can attack anything, you need a target and a way to see the traffic flowing between your browser and that target.

OWASP Juice Shop is a deliberately vulnerable web application built with Node.js, Express, and Angular. It covers all OWASP Top 10 categories with over 100 challenges.

In this step, you will spin up Juice Shop using Docker and configure Burp Suite as an intercepting proxy so you can inspect and modify every HTTP request your browser sends.

In This Step, Get Ready To:

Pull and run the Juice Shop Docker container on localhost:3000.
Configure Burp Suite's proxy to intercept all Juice Shop traffic.
Verify that requests are being captured in Burp's HTTP History.

Pull and Run the Juice Shop Container

Docker lets you run Juice Shop in a single command with no Node.js version management needed. The container is self-contained and resets its database every time it restarts, so you always get a clean environment.

Open a terminal (Command Prompt or PowerShell).
Pull the Juice Shop image from Docker Hub.

docker pull bkimminich/juice-shop

Run the container in detached mode, mapping port 3000 on your machine to port 3000 inside the container.

docker run -d -p 3000:3000 bkimminich/juice-shop

What does this command do?

The -d flag runs the container in the background so your terminal stays free. The -p 3000:3000 flag maps your machine's port 3000 to the container's port 3000, making Juice Shop accessible at http://localhost:3000.

Open your browser and navigate to http://localhost:3000.

You should see a modern e-commerce storefront selling juices. This is your target application.

Pro tip: self-healing database

Juice Shop wipes its database and any user-modified files every time the container restarts. If you ever need a fresh start, just stop and re-run the container.

Page not loading?

Give the container about 10-15 seconds to start up before refreshing. If it still does not load, run docker ps to check if the container is running. If port 3000 is already in use, stop the conflicting process or map to a different port (e.g., -p 3001:3000). Help me troubleshoot my Docker container.

Configure Burp Suite to Intercept Juice Shop Traffic

Burp Suite acts as a man-in-the-middle between your browser and Juice Shop. Every request your browser sends passes through Burp first, letting you inspect, modify, or replay it. Without this setup, you would be testing blind.

Open Burp Suite Community Edition and create a temporary project.
Go to Proxy, then Options.
Confirm the proxy listener is running on 127.0.0.1:8080.

Now you need to point your browser's traffic through Burp's proxy. You have two options:

Burp's Built-in Browser (Recommended)

Burp Suite comes with a built-in Chromium browser that is already configured to route all traffic through Burp's proxy. This is the fastest way to get started and avoids any localhost proxy issues.

In Burp Suite, go to Proxy, then Intercept.
Click Open Browser.
In the Burp browser, navigate to http://localhost:3000.

Firefox (Manual Setup)

If you prefer using Firefox, you need to configure its proxy settings manually. By default, Firefox bypasses the proxy for localhost traffic, so you also need to change a hidden setting.

Open Firefox and go to Settings, then General.
Scroll down to Network Settings and click Settings.
Select Manual proxy configuration.
Set the HTTP Proxy to 127.0.0.1 and the Port to 8080.
Check Also use this proxy for HTTPS and click OK.
Navigate to about:config in the Firefox address bar.
Search for network.proxy.allow_hijacking_localhost and set it to true.

Why this extra Firefox setting?

Firefox skips the proxy for localhost traffic by default. Setting network.proxy.allow_hijacking_localhost to true forces Firefox to send localhost requests through Burp's proxy so you can intercept them.

Verify Interception Is Working

You need to confirm that Burp is actually capturing traffic before moving on. If this is not working, every subsequent step will fail.

In Burp Suite, go to Proxy, then Intercept.
Make sure Intercept is on is toggled on.
Go to your browser and refresh the Juice Shop page at http://localhost:3000.

The page should hang and not load. That is because Burp is holding the request.

Switch back to Burp Suite. You should see the intercepted GET request in the Intercept tab.
Click Forward to let the request through to Juice Shop.
Continue clicking Forward until the page finishes loading in your browser.
Go to Proxy, then HTTP History.
Confirm you see requests to localhost:3000 listed there.

What should I see?

The HTTP History tab should show multiple requests to localhost:3000, including GET requests for the main page, JavaScript bundles, API calls for products, and static assets. Each row shows the method, URL, status code, and response length.

Toggle Intercept is on to turn it off. You will turn it back on later when you need to modify specific requests.

Not seeing any requests in HTTP History?

Double-check that your browser's proxy is set to 127.0.0.1:8080. If you are using Firefox, make sure network.proxy.allow_hijacking_localhost is set to true. The easiest fix is to use Burp's built-in browser instead. Help me get Burp Suite to intercept localhost traffic.

Your target is live and your proxy is capturing every request. Next up, you will dig into Juice Shop's JavaScript source code and Burp's sitemap to discover hidden endpoints and map out the full attack surface.

Enumerate Hidden Endpoints and Map the Attack Surface

With Burp Suite capturing traffic, you are ready to start the first phase of any penetration test: reconnaissance. Before you can exploit anything, you need to know what exists. Hidden pages, undocumented API endpoints, and admin panels are all common targets that developers forget to lock down. In this step, you will dig through Juice Shop's client-side code and traffic to build a map of everything available to attack.

In This Step, Get Ready To:

Discover hidden application routes by analyzing JavaScript source code.
Build a sitemap of API endpoints by interacting with the application through Burp Suite.
Locate the hidden admin panel that you will exploit in a later step.

Discover the Hidden Score Board

Juice Shop is built with Angular, which means all of its client-side routes are defined in JavaScript files that your browser downloads. Developers sometimes assume that if a page is not linked in the navigation menu, users will not find it. A pentester's job is to prove that assumption wrong.

Open Juice Shop in your browser at http://localhost:3000.
Press F12 to open DevTools.
Navigate to the Sources tab (Chrome) or Debugger tab (Firefox).
Locate the main JavaScript bundle file. It is typically named something like main.js or main-es2018.js.
Press Ctrl+F to search within the file and type score-board.

You should find a reference to a route path containing score-board. This route is not linked anywhere in the Juice Shop UI, but it absolutely exists.

Navigate to http://localhost:3000/#/score-board in your browser.

The hidden Score Board loads, revealing every challenge available in Juice Shop organized by difficulty and category. This is your first successful enumeration find.

What is endpoint enumeration?

Endpoint enumeration is the process of discovering all accessible URLs, API routes, and pages in an application. Developers often hide sensitive pages by simply not linking to them in the UI. A pentester treats every route defined in the code as a potential target, whether it is linked or not.

Enumerate API Endpoints Using Burp's Sitemap

JavaScript analysis reveals client-side routes, but the real attack surface lives in the API. Every action you take in Juice Shop sends HTTP requests to backend endpoints. Burp Suite captures all of these requests automatically, building a map of the application's backend.

Make sure Burp Suite is running and your browser is routing through the proxy.
In the Juice Shop browser, click Account, then Login.
Click Not yet a customer? and register a new account with any email and password.
Log in with your new account.
Browse through the product catalog and click on a few products.
Add at least one item to your shopping basket.
Visit the Customer Feedback page by navigating to http://localhost:3000/#/contact.

Each of these interactions generated API requests that Burp captured in the background.

Switch to Burp Suite and go to Target, then Site map.
Expand the http://localhost:3000 tree.

You should see a tree of API endpoints that the application uses. Take note of the key ones you will target in later steps:

/api/Users handles user registration and user data.
/api/Products serves product catalog data.
/api/Feedbacks stores customer feedback submissions.
/api/BasketItems manages shopping basket contents.
/rest/ routes handle additional REST operations.

This is your attack surface. Every one of these endpoints is a potential target for IDOR, broken access control, or data tampering.

Pro tip: passive reconnaissance

In a real pentest, you would also use Burp's Spider or crawler to automatically discover endpoints. In the Community Edition, manually clicking through the app and watching the sitemap build is the primary approach. The more you interact with the application, the more complete your sitemap becomes.

Discover the Hidden Admin Panel

The Score Board was hidden from the navigation menu but accessible to anyone with the URL. The same technique that revealed it can uncover even more sensitive pages.

Go back to the JavaScript bundle file in DevTools.
Search for administration using Ctrl+F.

You should find a reference to an administration route path. This is the admin panel.

Navigate to http://localhost:3000/#/administration in your browser.

You will get an error or be redirected back to the home page. Your current account does not have admin privileges, so the application blocks access. This is expected.

Why does knowing this endpoint matter?

You now know the admin panel exists at a specific path. The application only checks your role after you navigate there. If you can find a way to register an account with admin privileges, this panel will open right up. You will do exactly that in Step 4 using a mass assignment attack.

You have now completed the enumeration phase. You discovered two hidden pages and mapped out the full API surface of the application. In a real pentest, this is the foundation that every exploit builds on. Next up, you will use these endpoints to access data that does not belong to you.

Exploit IDOR to Access Another User's Data

You have mapped the attack surface and know where the interesting endpoints live. Now it is time to see if the application actually enforces ownership over its data. Insecure Direct Object References (IDORs) happen when the server lets you access a resource just because you know its ID, without checking whether you are the rightful owner. This is horizontal privilege escalation. You stay at the same privilege level but reach sideways into another user's data.

In This Step, Get Ready To:

Access another user's shopping basket by manipulating a client-side identifier.
Enumerate other users' feedback data through the API by incrementing resource IDs.

View Another User's Shopping Basket

Juice Shop stores your basket ID on the client side in Session Storage. The server trusts whatever basket ID the browser sends without verifying that it belongs to the logged-in user. If you change that ID to someone else's, you see their basket instead of yours.

Log in to the account you registered in the previous step.
Click the shopping basket icon in the top-right corner to navigate to your basket page.
Open DevTools by pressing F12.
Go to the Application tab (Chrome) or the Storage tab (Firefox).
Expand Session Storage and select the localhost:3000 entry.
Find the bid key. This is your basket ID.
Change the bid value to 1 (this belongs to the admin user).
Refresh the basket page.

You should now see the admin user's basket contents instead of your own. The Juice Shop Score Board registers the "View Basket" challenge as solved.

What Is an IDOR?

An Insecure Direct Object Reference occurs when an application exposes an internal identifier (like a database row ID) and uses it to look up data without checking whether the requesting user is authorized to see it. The fix is straightforward: the server should verify that the authenticated user actually owns the resource before returning it.

Why Is This Called Horizontal Privilege Escalation?

You did not gain any extra permissions. You are still a regular customer. But you moved sideways to access a different user's data at the same privilege level. That is horizontal escalation. In the next step, you will go vertical by promoting yourself to admin.

Access Other Users' Feedback via the API

The basket IDOR relied on client-side storage manipulation. Now you will exploit the same class of vulnerability directly through the API. The /api/Feedbacks endpoint accepts a numeric ID and returns whichever feedback record matches, regardless of who submitted it.

Open Burp Suite and go to Proxy > HTTP History.
Find any authenticated request to localhost:3000 and copy the full Authorization: Bearer header value from it.
Right-click that request and select Send to Repeater.
In the Repeater tab, modify the request line to target the Feedbacks endpoint.

Set the request to:

GET /api/Feedbacks/1 HTTP/1.1
Host: localhost:3000
Authorization: Bearer your-token-here

What does this request do?

This sends a GET request to the Feedbacks API asking for the feedback record with ID 1. The Authorization header proves you are logged in, but the server never checks whether feedback ID 1 actually belongs to you.

Click Send in Repeater.

You should receive a JSON response containing feedback data that belongs to another user, including their comment and user ID.

Change the URL path to /api/Feedbacks/2 and click Send again.
Try /api/Feedbacks/3, /api/Feedbacks/4, and so on.

Each response leaks a different user's feedback. By simply incrementing the ID, you can enumerate every piece of feedback in the entire application. This is IDOR at the API level.

Pro tip: real-world IDOR hunting

In a real pentest, you would script this enumeration to pull every record automatically. Burp Suite's Intruder tool can automate ID incrementing for you. Select the ID number in Repeater, right-click, and choose Send to Intruder to set up a sequential payload.

Getting a 401 Unauthorized Response?

Your authentication token may have expired. Go back to Proxy > HTTP History, find a recent authenticated request, and copy the fresh Authorization: Bearer header into your Repeater request. If you still see errors, help me troubleshoot my Burp Suite Repeater request to the Juice Shop Feedbacks API.

You have now proven that Juice Shop's access controls are broken in two places: the basket page and the feedback API. Both trust user-supplied identifiers without verifying ownership. Next up, you will go beyond reading other users' data and promote yourself to a full administrator.

Escalate to Admin via Mass Assignment

So far you have been exploiting horizontal privilege escalation. You accessed other users' data, but you were still just a regular customer. Now it is time to go vertical. In this step, you will escalate from a normal user account to a full administrator by exploiting a mass assignment vulnerability in the registration API.

In This Step, Get Ready To:

Intercept and analyze the registration API request to understand its JSON structure.
Inject an admin role field into the registration payload to create an admin account.
Confirm admin access by reaching the administration panel and managing user data.

Analyze the Registration API Request

Before you can exploit the registration endpoint, you need to understand what a normal registration request looks like. The server at POST /api/Users accepts a JSON body with user details. Your goal is to intercept this request and study its structure for fields you can manipulate.

Open the Juice Shop registration page in your browser.
Fill in the registration form with any email (e.g., hacker@juice-sh.op) and a password.
Before clicking submit, switch to Burp Suite and turn on Intercept in the Proxy tab.
Go back to the browser and submit the registration form.

In Burp's Intercept view, you should see a POST request to /api/Users with a JSON body containing fields like email, password, and passwordRepeat. Do not forward this request yet. This is the payload you are about to modify.

What Is Mass Assignment?

Mass assignment happens when a server blindly accepts all fields in a request body without checking which ones the client is allowed to set. If the server uses the incoming JSON to directly create or update a database record, an attacker can inject extra fields that were never intended to be user-controlled.

In this case, the registration endpoint does not whitelist which fields are allowed. So you can add a role field and the server will happily store it.

Inject the Admin Role Into the Registration Payload

The intercepted request is still sitting in Burp, waiting for you to modify it. You are going to add a single field to the JSON body that tells the server to create your account with admin privileges.

In Burp's Intercept view, locate the JSON body of the POST request.
Add "role":"admin" to the JSON object.

Your modified JSON body should look like this:

{
  "email": "hacker@juice-sh.op",
  "password": "hacker123",
  "passwordRepeat": "hacker123",
  "role": "admin"
}

What Does This Modification Do?

The original registration form only sends email, password, and passwordRepeat. The role field is never exposed in the UI. But because the server does not validate or reject unexpected fields, it processes the role value and assigns admin privileges to the new account.

Click Forward in Burp to send the modified request to the server.
Continue forwarding any remaining intercepted requests until the registration completes.
Turn off Intercept once the registration is done.

The server accepts the request without complaint. Your new account now has admin privileges, even though the registration form never offered that option.

Why Mass Assignment Instead of SQL Injection?

You might expect privilege escalation to require something dramatic like SQL injection or password cracking. Mass assignment is far more subtle. It exploits a design flaw in how the server handles input, not a flaw in the database layer. Many modern frameworks that auto-bind request data to models are vulnerable to this if developers do not explicitly define which fields are allowed.

This makes mass assignment particularly dangerous because it is easy to overlook during development and leaves no obvious trace in logs.

Confirm Admin Access

You have injected the admin role, but you need to verify it actually worked. The admin panel you discovered during enumeration in Step 2 is the proof.

Log out of any existing session in Juice Shop.
Log in with your newly created admin account (e.g., hacker@juice-sh.op / hacker123).
Navigate to http://localhost:3000/#/administration.

This time, instead of being blocked, you should see the full administration panel. It displays a list of all registered users with their email addresses, plus all customer feedback with delete buttons next to each entry.

What Should I See?

The admin panel has two main sections. The Registered Users section shows every account in the system, including the original admin (admin@juice-sh.op) and your newly created account. The Customer Feedback section shows all submitted feedback with a trash can icon to delete entries. If you see both sections, your privilege escalation was successful.

Find and delete the 5-star feedback entries from the Customer Feedback section to complete the "Five-Star Feedback" challenge.

Check the Score Board at http://localhost:3000/#/score-board to confirm the "Admin Registration" and "Five-Star Feedback" challenges are now marked as solved.

Still Getting Blocked From the Admin Panel?

If you are redirected away from the admin panel, the role field may not have been included correctly in the JSON body. Go to Burp's HTTP History and find the POST request to /api/Users. Check the request body to verify the role field was present and properly formatted. Make sure the JSON is valid with correct commas and quotes. Try registering again with a different email. Help me debug my mass assignment attempt.

You now have full admin control over the Juice Shop. Next up, you will use this access to forge feedback under other users' names and tamper with product data.

Forge Feedback and Tamper with Data

You now have full admin access to Juice Shop. In a real pentest, this is where the engagement gets serious. An attacker with elevated privileges does not just look around. They use that access to manipulate data, impersonate users, and demonstrate the full impact of the vulnerability chain. In this step, you will forge feedback under another user's identity and tamper with product data by exploiting missing HTTP method restrictions.

In This Step, Get Ready To:

Post feedback under another user's name by manipulating the UserId field in the API request.
Tamper with product data by switching HTTP methods from GET to PUT on a product endpoint.

Forge Feedback Under Another User's Name

The Customer Feedback form lets users submit comments and ratings. The application sends a UserId field in the API request to identify who posted the feedback. If the server never validates that this UserId matches the authenticated session, an attacker can post feedback as anyone.

Navigate to the Customer Feedback page at http://localhost:3000/#/contact.
Fill in a comment and select a star rating.
Turn on Intercept in Burp Suite's Proxy tab.
Click Submit on the feedback form.

Burp intercepts the POST request to /api/Feedbacks. The JSON body contains a UserId field set to your own user ID.

In the intercepted request body, change the UserId value to 1 (the admin user) or 2 (another user).
Click Forward to send the modified request.

The feedback is now posted under that other user's name. The server never validates that the UserId in the request body matches the authenticated session. This completes the Forged Feedback challenge.

Why Is This Dangerous?

Forging feedback might seem minor, but the underlying vulnerability is critical. Any API that trusts client-supplied identity fields without server-side validation is vulnerable to impersonation. In production applications, this same flaw could let an attacker submit orders, file support tickets, or post reviews as any user.

Tamper with Product Data Using HTTP Method Manipulation

Most web applications expose product data through GET requests. But what happens if the server also accepts PUT requests on the same endpoint without proper authorization checks? You are about to find out by modifying a product's description directly through the API.

Open Burp Suite's Repeater tab.
Send a GET request to http://localhost:3000/api/Products/9 to retrieve the O-Saft product data.

The response contains the product's current data, including a description field with an href link inside it. This is the field you will tamper with.

Change the HTTP method from GET to PUT in the Repeater request.
Set the Content-Type header to application/json.
Remove the If-None-Match header if it is present in the request.
Add a JSON body that modifies the description field, changing the href link to point to https://owasp.slack.com.

Your PUT request body should look similar to this:

{
  "description": "O-Saft is an easy to use tool... <a href=\"https://owasp.slack.com\" target=\"_blank\">More...</a>"
}

What Does This Request Do?

You are sending a PUT request to the same product endpoint that normally only serves GET requests. The description field contains an HTML anchor tag. By changing the href value inside it, you are redirecting anyone who clicks the product link to a different URL. Copy the full original description from the GET response and only modify the href value.

Click Send in Repeater.

The server accepts the PUT request and updates the product data. It does not check whether the requesting user has permission to modify products, and it does not restrict which HTTP methods are allowed on this endpoint.

Verify the tampering by sending a fresh GET request to /api/Products/9 and confirming the href now points to https://owasp.slack.com.

This completes the Product Tampering challenge. You have demonstrated how broken access control combined with missing HTTP method restrictions allows an attacker to modify server-side data.

What Is Broken Access Control?

Broken access control is the #1 vulnerability in the OWASP Top 10. It covers any situation where the application fails to enforce proper restrictions on what authenticated users can do. In this case, the server allows any user to send a PUT request to modify product data. A properly secured API would restrict PUT and DELETE methods to authorized admin accounts only.

Getting a 401 or 403 Error on the PUT Request?

Make sure you are logged in with the admin account you created in the previous step. Copy a fresh Authorization: Bearer header from a recent request in your HTTP History and paste it into your Repeater request. Also confirm that you removed the If-None-Match header. Help me troubleshoot my PUT request to the Products API.

You have now demonstrated the full impact of the vulnerabilities you discovered. You went from enumerating hidden endpoints, to accessing other users' data, to gaining admin privileges, to actively manipulating application data. Next up, you will chain these techniques together in the Secret Mission to simulate a real attack narrative.

Secret mission

Chain Multiple Attack Techniques Into a Full Attack Narrative

You have performed enumeration, IDOR, privilege escalation, and data tampering as isolated techniques. Now it is time to chain them together into a realistic attack scenario, just like you would on a real red team engagement. Can you manipulate another user's basket, combine your admin access with IDOR, and write up your findings like a professional pentester?

Before you go

Clean Up Your Resources

This project runs entirely locally using Docker, so there are no ongoing cloud costs. Decide whether to keep your Juice Shop container running, pause it to come back later, or delete it entirely.

Resources you used:

OWASP Juice Shop Docker container (bkimminich/juice-shop) running on localhost:3000.
OWASP Juice Shop Docker image stored locally.
Burp Suite Community Edition (installed application).
Browser proxy settings configured to route through 127.0.0.1:8080.
Firefox about:config setting (network.proxy.allow_hijacking_localhost), if modified.

Keep everything running

No action needed. Choose this if you are still actively exploring Juice Shop challenges or want to continue practicing.

Your Juice Shop container will keep running on localhost:3000.
Keep in mind that Juice Shop wipes its database and any user-modified files every time the container restarts. Your challenge progress on the Score Board persists only as long as the container keeps running.
Your browser proxy settings will remain configured to route through Burp Suite. Remember to revert them when you want to browse normally.

Pause - I'll come back to this later

Stop the Docker container to free up memory and CPU, but keep the image so you can restart quickly later.

Open a terminal and run docker ps to find your Juice Shop container ID.
Run docker stop <container-id> to stop the container.
Revert your browser proxy settings back to "No proxy" or "Use system proxy settings" so your normal browsing is not affected.
If you modified Firefox's network.proxy.allow_hijacking_localhost setting, set it back to false in about:config.
To resume later, run docker start <container-id> or re-run docker run -d -p 3000:3000 bkimminich/juice-shop. Note that Juice Shop resets its database on every restart, so your challenge progress will be cleared.

Delete - I don't want to use this again

Remove all project resources and start fresh. This frees up disk space used by the Docker image.

Open a terminal and run docker ps to find your Juice Shop container ID.
Run docker stop <container-id> to stop the container.
Run docker rm <container-id> to remove the container.
Run docker rmi bkimminich/juice-shop to delete the Docker image from your machine.
Revert your browser proxy settings back to "No proxy" or "Use system proxy settings".
If you modified Firefox's network.proxy.allow_hijacking_localhost setting, set it back to false in about:config.
Burp Suite itself is a standalone application. Uninstall it through Settings > Apps > Apps & features if you no longer need it.

Mission accomplished

That's a Wrap!

Nice work! You just completed a structured penetration test against OWASP Juice Shop, exploiting real vulnerabilities across enumeration, IDOR, privilege escalation, and data tampering.

You've learned how to:

Enumerate hidden endpoints by analyzing JavaScript source code and Burp Suite's sitemap, then exploit IDOR vulnerabilities to access other users' baskets and feedback data.
Escalate from a regular customer to a full administrator by injecting a role field into the registration API via a mass assignment attack.
Forge feedback under another user's identity and tamper with product data by switching HTTP methods from GET to PUT against unprotected API endpoints.
Chain multiple attack techniques together using HTTP parameter pollution to manipulate another user's basket, then document findings in a pentest-style report.

Ready to quiz yourself?