Hack OWASP Juice Shop Like a Pentester

Chain 5 real vulnerabilities to achieve full admin compromise on a local app.

Introduction

30 Second Summary

Every day, attackers find ways into web applications not through a single dramatic flaw, but by chaining together small overlooked weaknesses. Understanding how these attacks work is the first step to stopping them.

In this project, you will hack a realistic e-commerce application by exploiting 5 different vulnerabilities and chaining them into a full account takeover. You'll work like a real penetration tester, progressing from reconnaissance through exploitation to complete admin access.

What You'll Build

You'll conduct a complete offensive security engagement against OWASP Juice Shop, a deliberately vulnerable web application built for security training.

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

  • A running hacking lab with Docker and Burp Suite proxy configured on your local machine.
  • Successful exploitation of 5 intermediate-level vulnerabilities across different OWASP Top 10 categories including SQL injection, broken access control, and JWT manipulation.
  • A documented attack chain demonstrating how small bugs combine into full privilege escalation from zero access to admin compromise.
  • Secret Mission: Exploit broken anti-automation to brute-force a coupon code and apply it to an order.

Are there any prerequisites?

You should have a basic understanding of HTTP requests and responses, familiarity with web applications (login forms, navigation), and comfort using a command line. No prior security experience is needed.

Set Up Your Hacking Lab

Every penetration test starts with a controlled lab environment. You need a vulnerable application to attack and a tool to intercept the traffic between your browser and that application.

In this step, you'll set up three things: Docker to run a vulnerable web app locally, OWASP Juice Shop as your target application, and Burp Suite Community Edition to intercept and manipulate HTTP traffic.

In this step, get ready to:
  • Install Docker Desktop and verify it's running.
  • Launch OWASP Juice Shop in a Docker container.
  • Install and configure Burp Suite Community Edition with browser proxy and CA certificate.
Install Docker Desktop

Docker lets you run applications inside isolated containers. You'll use it to spin up Juice Shop without installing Node.js or dealing with dependencies.

  • Open your browser and navigate to the Docker Desktop download page:

https://docs.docker.com/get-started/get-docker/

  • Download the installer for your operating system (Windows, macOS, or Linux).
  • Run the installer and follow the prompts to complete the installation.
  • Once installed, launch Docker Desktop.

What is Docker?

Docker is a platform that runs applications inside lightweight, isolated environments called containers. Instead of installing Juice Shop's Node.js dependencies directly on your machine, Docker packages everything into a single image that runs identically on any system.

  • Open a terminal to check that Docker is working. Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.
  • Check that Docker is installed by running this command:
docker --version

✔️ I see a version number

Docker is installed and ready. You can move on to launching Juice Shop.

ⓧ Command not found

Docker Desktop is not installed yet or has not finished setting up. Try these steps:

  • Make sure Docker Desktop has fully finished installing (it may prompt you to restart your computer).
  • On Windows, make sure WSL 2 is enabled (Docker Desktop prompts you during installation).
  • Close and reopen your terminal after installing, then try the command again.
  • If it still fails, visit the Docker Desktop installation docs for your platform and follow the steps from the beginning.
Launch OWASP Juice Shop

OWASP Juice Shop is a deliberately vulnerable e-commerce application built for security training. It contains over 100 hacking challenges across the OWASP Top 10 categories.

  • Pull the Juice Shop Docker image by running this command:
docker pull bkimminich/juice-shop

What does this command do?

This downloads the latest Juice Shop image from Docker Hub to your machine. The image contains the full application pre-built and ready to run.

  • Start the Juice Shop container by running this command:
docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop

What does this command do?

The --rm flag automatically removes the container when you stop it. The -p 127.0.0.1:3000:3000 flag maps port 3000 inside the container to port 3000 on your local machine, accessible only from localhost.

The terminal will display startup logs and stay open while Juice Shop runs. Do not close this terminal window.

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

You should see the Juice Shop storefront with a product catalog and a navigation bar.

Don't see the storefront?

  • Make sure Docker Desktop is running (check for the Docker whale icon in your system tray or menu bar).
  • Check that the terminal shows startup logs without errors. If you see a port conflict message, another application is using port 3000. Stop that application and try again.
  • Wait 10-15 seconds after the container starts before refreshing the browser. Juice Shop takes a moment to initialize.

Why can't I reach Juice Shop at localhost:3000?

Install and configure Burp Suite Community Edition

Burp Suite is the industry-standard tool for web application security testing. It works as an intercepting proxy, sitting between your browser and the target application so you can inspect and modify every request.

  • Open your browser and navigate to the Burp Suite download page:

https://portswigger.net/burp/downloads

  • Download the installer for your operating system. The page auto-detects your OS.
  • Run the installer. When prompted to choose an edition, select Community Edition.
  • Complete the installation wizard and launch Burp Suite.

Why Burp Suite Community Edition?

Burp Suite uses a single installer for both Professional and Community editions. Community Edition is free and includes the core tools you need for this project: an HTTP proxy, Repeater, Decoder, and Intruder (throttled). Professional costs $499/year and is not needed here.

  • When Burp Suite opens, select Temporary Project and click Next.
  • On the configuration screen, leave Use Burp defaults selected and click Start Burp.

Burp Suite opens to the Dashboard. The proxy listener is already active on 127.0.0.1:8080 by default.

What is a proxy listener?

A proxy listener is a local server that accepts connections from your browser. When your browser routes traffic through Burp's listener on port 8080, Burp can see, log, and modify every HTTP request before it reaches the target application.

Now you need to configure your browser to send traffic through Burp. You have two options: use Burp's built-in browser (easiest) or configure your own browser.

✔️ I'll use Burp's built-in browser

Burp includes a Chromium-based browser that is pre-configured to route all traffic through the proxy. No manual proxy or certificate setup is needed.

  • In Burp Suite, click the Proxy tab.
  • Click the Intercept sub-tab.
  • Click Open Browser.
  • In the browser that opens, navigate to http://localhost:3000 to confirm you can reach Juice Shop through Burp.

If Intercept is set to On, you'll need to click Forward to let requests through. Toggle it to Intercept is off for now so pages load normally.

ⓧ I'll configure my own browser (Chrome or Firefox)

You'll need to do three things: configure your browser's proxy settings, download Burp's CA certificate, and install it in your browser.

Configure browser proxy settings

For Chrome on Windows:

  • In Chrome, click the three-dot menu and select Settings.
  • Open the System section and click Open your computer's proxy settings.
  • Set Use a proxy server to On.
  • Enter 127.0.0.1 in the Address field.
  • Enter 8080 in the Port field.
  • Make sure Automatically detect settings and Use setup script are Off.
  • Click Save.

For Firefox (any platform):

  • In Firefox, open the menu and select Settings.
  • Scroll to Network Settings and click Settings.
  • Select Manual proxy configuration.
  • Enter 127.0.0.1 in the HTTP Proxy field.
  • Enter 8080 in the Port field.
  • Check Also use this proxy for HTTPS.
  • Clear anything in the No proxy for field.
  • Click OK.
Download and install Burp's CA certificate
  • With Burp Suite running, open your browser and navigate to http://burpsuite.
  • Click CA Certificate in the top-right corner to download the certificate file.
  • Note where the file is saved (it will be in .der format).

For Chrome on Windows:

  • In Chrome, go to Settings > Privacy and security > Security > Manage certificates.
  • Select the Trusted Root Certification Authorities tab and click Import.
  • Browse to the certificate you downloaded. Set the file filter to All Files to see the .der file.
  • Click Next, ensure Trusted Root Certification Authorities is selected, then click Finish.
  • Restart Chrome.

For Firefox (any platform):

  • In Firefox, go to Settings > Privacy & Security.
  • Scroll to Certificates and click View Certificates.
  • Go to the Authorities tab and click Import.
  • Select the Burp CA certificate file you downloaded.
  • Check Trust this CA to identify websites and click OK.
  • Restart Firefox.
Verify the proxy is working
  • Navigate to http://localhost:3000 in your configured browser.
  • In Burp Suite, click the Proxy tab, then the HTTP history sub-tab.
  • You should see requests to localhost:3000 appearing in the history list.

Not seeing requests in Burp's HTTP history?

  • Double-check that your proxy address is 127.0.0.1 and port is 8080.
  • In Burp, go to Proxy > Intercept and set it to Intercept is off so requests flow through without being held.
  • Make sure another application is not already using port 8080. If so, you'll need to change Burp's listener port.

Why isn't my browser traffic showing up in Burp Suite?

Your hacking lab is ready. You have a vulnerable application running locally and a proxy capturing every request your browser makes to it. Next up, you'll use this setup to map the Juice Shop's attack surface.

Reconnaissance - Map the Attack Surface

Your hacking lab is live. Before exploiting anything, a real penetration tester maps the target first.

Reconnaissance is the phase where you passively observe the application's traffic to understand its structure. You'll discover hidden pages, identify API endpoints, and learn how the application handles authentication.

In this step, get ready to:
  • Discover the hidden Score Board by examining JavaScript source files in Burp.
  • Enumerate the REST API endpoints using Burp's Site Map.
  • Identify the application's authentication pattern by decoding a JWT token.
Discover the hidden Score Board

Every web application ships JavaScript to the browser. That JavaScript often contains route definitions that reveal pages the developers never linked in the UI.

  • Switch to your browser (with proxy configured from Step 1) and browse around the Juice Shop at http://localhost:3000.
  • Click on a few products, open the side menu, and visit the login page. This generates traffic for Burp to capture.
  • Switch back to Burp Suite and click the Proxy > HTTP history tab.
  • Sort the list by clicking the # column header until the most recent requests appear at the top.

What is HTTP history?

Burp's HTTP history records every request and response that flows through the proxy. Even with Intercept turned off, Burp silently logs all traffic. This lets you browse normally and analyze the captured data afterwards.

  • Look through the HTTP history for a request to a file called main.js. It will have a URL path containing main.js and a large response size.
  • Click on that entry to select it. The lower pane shows the full response body.
  • Press Ctrl+F (Windows) or Cmd+F (macOS) to open the search bar within the response.
  • Type score and press Enter to search through the results. Look for a route definition that contains the path score-board.

What are route definitions?

Juice Shop is built with Angular, a JavaScript framework that defines all its page routes in the bundled main.js file. These routes map URL paths to components. Even hidden pages that have no visible links are listed here.

  • In your browser, navigate to http://localhost:3000/#/score-board to access the hidden Score Board.

You should see a page tracking all available challenges with green checkmarks for solved ones. A challenge notification banner confirms you solved the Score Board challenge.

Score Board stays visible now

After discovering the Score Board, a new Score Board menu item appears in the navigation bar. You can return to it anytime to track your progress.

Don't see main.js in HTTP history?

Make sure you browsed the Juice Shop homepage with your proxy active. The main.js file loads on the first page visit. If your history is cluttered, use the filter bar at the top of HTTP history and filter by the host localhost.

Help me find main.js in Burp Suite's HTTP history for Juice Shop

Enumerate the API

Now that you've generated traffic by browsing, Burp has built a map of every endpoint the application exposes. The Site Map organizes this into a browsable tree structure.

  • In Burp Suite, click the Target > Site map tab.
  • In the left panel, expand the http://localhost:3000 node.
  • Look for directories named /api/ and /rest/. Expand them to see the available endpoints.

You should see endpoints for resources like users, products, baskets, and feedback. These are the application's REST API.

Why does API enumeration matter?

REST API endpoints are the backbone of modern web applications. They handle data access, authentication, and business logic. Finding all available endpoints gives you a complete picture of what you can interact with.

Endpoints under /api/ and /rest/ in Juice Shop handle everything from user profiles to shopping carts. Many of these lack proper authorization checks.

  • Click on individual endpoints in the Site Map to inspect their request and response details in the lower pane.
  • Pay attention to any requests that include an Authorization header. This tells you which endpoints require authentication and what token format the application uses.

Site map looks empty?

The Site Map only populates from traffic that passes through the proxy. Go back to your browser and click through more pages on Juice Shop. Try visiting the login page, registration page, and product pages. Each page load generates API calls that appear in the Site Map.

Help me populate Burp Suite's Site Map with Juice Shop endpoints

Identify authentication patterns

To attack an application's authentication, you first need to understand how it works. Juice Shop uses JWT (JSON Web Tokens) to track logged-in sessions. Registering an account lets you observe this mechanism in action.

  • In your browser, click Account in the top navigation, then click Login.
  • Click Not yet a customer? to open the registration form.
  • Fill in an email address (any fake one works, like test@test.com), a password, and the password repeat field.
  • Select a security question and provide an answer.
  • Click Register.
  • After registration, log in with the credentials you just created.
  • Switch back to Burp Suite and go to Proxy > HTTP history.
  • Find the POST request to /rest/user/login. Click on it to view the request and response.
  • In the response body, look for the token field. This long string is the JWT that the server returned after successful authentication.

What is a JWT?

A JSON Web Token is a compact, URL-safe string made of three Base64-encoded parts separated by dots: header, payload, and signature. The header declares the signing algorithm. The payload carries user data like email and role. The signature verifies the token hasn't been tampered with.

Applications send JWTs in the Authorization header with each request. The server trusts whatever claims are inside the token as long as the signature is valid.

  • Highlight the entire token value in the response body.
  • Right-click the highlighted text and select Send to Decoder.
  • Go to the Decoder tab in Burp Suite.

A JWT has three parts separated by dots. You need to decode each part individually.

  • Copy just the first section (everything before the first dot). Paste it into the Decoder input field.
  • From the Decode as dropdown, select Base64.
  • You should see JSON output showing the alg field (the signing algorithm) in the header.
  • Now copy the second section (between the first and second dots) and decode it as Base64.
  • The payload reveals the user's email address, role, and other claims embedded in the token.

What did you learn from the token?

The header tells you which algorithm signs the token. The payload shows what user data the application trusts from the token. This is critical intelligence for later steps where you'll manipulate these values to escalate privileges.

Note the alg value and the user fields (email, role) in the payload. You'll exploit weaknesses in this structure in Step 5.

Token looks like garbled text after decoding?

Make sure you're copying only one section at a time (split on the dots). The full token won't decode correctly as a single string. Copy everything before the first . character for the header, and everything between the first and second . characters for the payload.

Help me decode a JWT token in Burp Suite's Decoder

You've completed the reconnaissance phase. You now have a map of the application's hidden pages, API endpoints, and authentication mechanism. Next up, you'll use what you've learned to exploit the login system with SQL injection.

Exploit Broken Authentication via SQL Injection

You have mapped the application's attack surface and identified how Juice Shop handles authentication. Now it's time to exploit the first real vulnerability.

The login endpoint at /rest/user/login accepts user-supplied input and passes it directly into a database query. If the application doesn't sanitize that input, you can inject your own SQL commands to bypass the password check entirely.

In this step, get ready to:
  • Intercept a login request using Burp Proxy.
  • Inject a SQL payload to bypass authentication and log in as the administrator.
  • Confirm admin access and decode the elevated JWT token.
Intercept the login request

Before you can tamper with a request, you need to catch it in transit. Burp's Intercept feature holds outgoing requests so you can inspect and modify them before the server ever sees them.

  • Switch back to Burp Suite.
  • Go to the Proxy > Intercept tab.
  • Click the intercept toggle so it reads Intercept on.
  • Switch to your browser and navigate to the Juice Shop login page at http://localhost:3000/#/login.
  • If you're currently logged in with your regular account, click the Account menu in the top-right corner and select Logout first.
  • In the Email field, type any test value like test@test.com.
  • In the Password field, type any value like password123.
  • Click Log in.

The page should freeze because Burp has intercepted the outgoing request. Switch back to Burp Suite.

  • In the Proxy > Intercept tab, look at the intercepted request in the main panel.
  • Identify the JSON body being sent to /rest/user/login. It contains an email field and a password field with the test values you entered.

What does this request look like?

The intercepted request is a POST to /rest/user/login. The body looks something like:

{"email":"test@test.com","password":"password123"}

This is the exact data the server uses to query the database. Because you can edit this before it reaches the server, you control what goes into the database query.

Inject SQL into the email field

The Juice Shop login query builds a SQL statement by directly inserting the email you provide. By appending a single quote and a SQL comment sequence, you can terminate the query early and skip the password check completely.

  • In the intercepted request body, find the email field value.
  • Replace the test email with the following SQL Injection payload:
admin@juice-sh.op'--
  • Leave the password field as-is. It can be anything because the payload comments it out of the query.
  • The full JSON body should now look like this:
{"email":"admin@juice-sh.op'--","password":"password123"}
  • Click Forward to send the modified request to the server.
  • Continue clicking Forward for any additional intercepted requests until the page loads in your browser.
  • Toggle the intercept button back to Intercept off so normal traffic flows again.

How does this payload work?

The server builds a query like: SELECT * FROM Users WHERE email = '<your input>' AND password = '<hashed password>'.

When you enter admin@juice-sh.op'--, the single quote closes the email string early. The -- is a SQL comment that tells the database to ignore everything after it. The password check is completely skipped.

The database finds the administrator's row by email and returns it without verifying the password. You are now authenticated as admin.

Still seeing the login page?

Make sure you replaced only the value inside the email field, not the entire JSON body. The single quote and double-dash must appear after the email address with no extra spaces.

If you accidentally forwarded the original request without modifying it, log out and try again. Make sure Intercept on is active before clicking Log in.

help me troubleshoot my SQL injection payload in Juice Shop

Confirm admin access

If the injection worked, you should now be logged into the Juice Shop as the administrator. Time to verify and explore what admin access gives you.

  • Switch to your browser. You should see the Juice Shop storefront with the admin account logged in.
  • Click the Account menu in the top-right corner. Confirm the email displayed is admin@juice-sh.op.
  • Navigate to the admin section by entering http://localhost:3000/#/administration in your browser's address bar.
  • You should see the administration panel with a list of all registered users, their emails, and feedback submissions.

Why does the admin panel matter?

In a real penetration test, accessing an admin panel after exploiting a single vulnerability is a critical finding. It proves that one SQL injection in a login form gave you full control over the application's user management, feedback, and configuration.

Now decode the admin's JWT token to confirm the elevated privileges.

  • Switch back to Burp Suite.
  • Go to Proxy > HTTP history.
  • Find the response to your modified login request (the POST to /rest/user/login). Click it to view the server's response.
  • In the response body, locate the token field. This is the admin's JWT.
  • Select and copy the token value.
  • Go to the Decoder tab in Burp Suite.
  • Paste the token into the input panel.
  • The JWT has three parts separated by dots. Select just the middle section (the payload) and decode it as Base64.
  • Examine the decoded payload. You should see the admin's email (admin@juice-sh.op) and a role field confirming admin-level access.

What is inside the JWT payload?

A JWT (JSON Web Token) contains three Base64-encoded sections: header, payload, and signature. The payload holds the user's identity claims, which the server trusts on every subsequent request.

By decoding it, you confirm that the server issued a token with admin privileges. In later steps, you'll exploit how these tokens are validated.

  • Return to the Juice Shop Score Board in your browser.
  • Confirm that the admin login via SQL injection challenge is now marked as solved (shown with a green checkmark).

Challenge not showing as solved?

The Score Board only registers the challenge if the SQL injection was the method used to authenticate. If you logged in using actual credentials instead of the injection payload, log out and repeat the intercept steps with the admin@juice-sh.op'-- payload.

Also check that you navigated to the Score Board while still logged in as admin. Some challenges require the session to be active.

why isn't my Juice Shop SQL injection challenge marked as solved on the Score Board

You just broke into the admin account without knowing the password. Next up, you'll use Broken Access Control techniques to access other users' data and discover confidential documents the application failed to protect.

Exploit Broken Access Control - IDOR and Data Exposure

You have admin access to Juice Shop through SQL injection. Now it is time to explore a different class of vulnerability: Broken Access Control.

Access control enforces rules about who can view or modify resources. When those rules are missing or poorly implemented, an attacker can reach data belonging to other users. In this step, you will exploit two broken access control patterns: an IDOR (Insecure Direct Object Reference) that leaks other users' shopping baskets, and sensitive data exposed through a misconfigured file directory.

In this step, get ready to:
  • Access another user's shopping basket by manipulating a request parameter.
  • Discover and download confidential documents from an exposed directory.
  • Document how these individual findings chain together for greater impact.
Access another user's basket (IDOR)

An IDOR vulnerability occurs when an application uses a user-controllable identifier (like a number in a URL) to fetch a resource, but never checks whether the requesting user actually owns that resource.

  • In the Juice Shop browser tab, click the shopping basket icon in the top navigation bar.
  • Switch to Burp Suite and open the HTTP history tab under Proxy.
  • Look for a GET request to an endpoint that looks like /rest/basket/1. The number at the end is the basket ID for the currently logged-in user.
  • Right-click that request and select Send to Repeater.

What is Burp Repeater?

Repeater lets you manually edit and re-send individual HTTP requests. You can tweak parameters, headers, or the path and immediately see the server's response. It is the primary tool for testing access control flaws.

  • In the Repeater tab, find the basket ID number in the request path.
  • Change the basket ID to a different number. For example, if your request shows /rest/basket/1, change it to /rest/basket/2.
  • Click Send.

The server responds with 200 OK and returns the full contents of another user's shopping basket. The application never checks whether your session owns that basket.

Why does this work?

The JWT token in your Authorization header proves you are authenticated. But authentication and authorization are separate controls. The server confirms WHO you are, but never checks WHETHER you are allowed to access that specific basket.

Because basket IDs are sequential integers, an attacker can enumerate every basket in the system just by incrementing the number. This is a textbook IDOR vulnerability.

  • Try a few more basket IDs (/rest/basket/3, /rest/basket/4) to confirm you can access multiple users' data.
  • Check the Juice Shop Score Board. The "View Basket" challenge should now be marked as solved.

Not seeing the challenge solved?

Make sure your Repeater request includes the Authorization: Bearer header with a valid JWT token. Without authentication, the server may reject the request entirely.

Also confirm you changed the basket ID to one that actually exists. Try low numbers like 1, 2, or 3. If the server returns an empty basket, try the next number.

Help me troubleshoot the IDOR basket challenge in Juice Shop. I can see the /rest/basket endpoint in Burp but the challenge isn't being marked as solved.

Discover confidential documents (Sensitive Data Exposure)

Sensitive Data Exposure happens when an application fails to protect confidential information. Sometimes the exposure is as simple as leaving an entire directory publicly accessible.

  • In your browser's address bar, navigate to:
http://localhost:3000/ftp

You should see a directory listing of files stored on the server. Several of these files contain information that should not be publicly accessible.

  • Click on acquisitions.md to open it. This is a confidential document about planned company acquisitions.

Opening this file solves the "Confidential Document" challenge on the Score Board.

What else is in this directory?

You will notice files with extensions like .bak and .md.bak. These are backup files that developers accidentally left exposed. The server restricts downloads to only .md and .pdf file types. Attempting to download a .bak file directly returns a 403 error.

  • Try clicking on package.json.bak in the FTP directory listing. You will see an error page indicating that only .md and .pdf files are allowed.
  • To bypass this restriction, you will use a Poison Null Byte technique. Navigate to this URL in your browser:
http://localhost:3000/ftp/package.json.bak%2500.md

How does the Poison Null Byte bypass work?

A null byte (%00) acts as a string terminator in many programming languages. The server's file extension check sees .md at the end of the URL and allows the download. But when the file system processes the path, it terminates the string at the null byte and serves package.json.bak instead.

The %25 in the URL is a URL-encoded percent sign. The browser first decodes %25 to %, which combines with 00 to form the actual null byte %00 when the server processes it.

  • Confirm the file downloads successfully. It contains the application's configuration data that a developer forgot to remove.
  • Return to the Score Board and verify that your sensitive data exposure challenges are now marked as solved.

Still getting a 403 error?

Double-check that you typed %2500 (percent-two-five-zero-zero), not %00. The percent sign itself must be URL-encoded for the null byte injection to work.

Make sure the URL ends with a valid extension like .md or .pdf after the %2500 portion.

Help me bypass the file type restriction in Juice Shop's /ftp/ directory using the Poison Null Byte technique.

Chain the findings

Individual vulnerabilities are concerning on their own. But when chained together, they tell a much more dangerous story.

  • Review what you have gathered across the last two steps:

Why does chaining matter in real pentests?

A bug bounty report showing "I can read another user's basket" might be rated as medium severity. But when you demonstrate that the same attacker also has admin access and can download internal configuration files, the combined impact is a complete data breach.

Professional penetration testers always document attack chains. Each finding builds on the last to demonstrate the maximum real-world impact.

  • Open the Score Board and confirm these challenges are solved: the admin login via SQL injection from the previous step, the basket IDOR (View Basket), and the confidential document access.
  • Take note of how each exploit fed into the next. The SQL injection gave you admin context. The admin panel exposed user data. The IDOR confirmed you could access individual user records. The FTP directory leaked operational secrets.

You have now demonstrated two critical categories from the OWASP Top 10: Broken Access Control and Sensitive Data Exposure. Next up, you will forge authentication tokens to achieve persistent admin access without needing the SQL injection at all.

Forge an Admin Token via JWT Manipulation

You have already proven you can break into the admin account using SQL injection. But that attack depends on the login form being vulnerable.

A stronger attacker achieves persistent access. In this step, you will exploit a weakness in how Juice Shop validates JSON Web Tokens to forge your own admin authentication token from scratch. No password needed, no SQL injection needed.

In this step, get ready to:
  • Decode and analyze the JWT structure in Burp Decoder.
  • Forge an admin token by exploiting the "none" algorithm vulnerability.
  • Validate your complete attack chain and confirm all 5 challenges are solved.
Analyze the JWT structure

Every time you log in to Juice Shop, the server issues a JWT that proves your identity. Understanding how this token is built is the first step toward forging one.

  • Switch back to Burp Suite and make sure you are logged in as your regular user account (not the admin).
  • In the HTTP history tab, find any request that includes an Authorization header with a Bearer token.
  • Select the full token string (everything after Bearer ). Right-click and choose Send to Decoder.

A JWT has three parts separated by periods: header, payload, and signature. Each part is Base64url-encoded.

  • In the Decoder tab, split the token at the period characters to isolate the first section (the header).
  • Paste just the header portion into a new Decoder input field.
  • Click Decode as and select Base64.
  • Note the alg field value. You should see RS256, which means the server uses RSA asymmetric signing.
  • Now decode the second section (the payload) the same way.
  • Identify the email and role fields in the decoded payload. These are the claims that determine who you are.

What is inside a JWT?

The header tells the server which signing algorithm to use. The payload contains your identity claims (user ID, email, role). The signature is a cryptographic seal that should prove the token was not tampered with.

If you can trick the server into accepting a token without verifying the signature, you can forge any identity you want.

Can't find the Authorization header?

Browse any page on Juice Shop while logged in as your regular user. This triggers authenticated requests. Filter the HTTP history by the localhost host and look for API calls to paths starting with /rest/ or /api/.

help me find JWT tokens in Burp Suite HTTP history

Forge an admin token using the "none" algorithm

The alg field in the JWT header is supposed to tell the server how to verify the signature. A critical vulnerability exists when the server accepts "none" as a valid algorithm. This means the server skips signature verification entirely.

  • Take the full JWT token from your regular user session and decode it using an external tool like jwt.io to view the header and payload side by side.
  • Modify the header JSON so the alg field reads "none" instead of "RS256".
  • Modify the payload JSON to change the email field to the admin's email address that you discovered during the SQL injection step.
  • Base64url-encode the modified header and the modified payload separately. Remove any trailing = padding characters from both encoded strings.
  • Construct your forged token by joining the encoded header and encoded payload with a period, then adding a trailing period where the signature would normally go.

The format of your forged token is: base64url(header).base64url(payload). (note the trailing period).

Why does the trailing period matter?

A valid JWT always has three parts separated by two periods. By keeping the trailing period, your forged token structurally looks like a complete JWT with an empty signature section. Some JWT libraries will accept this format when the algorithm is set to "none" because they skip signature verification entirely.

  • Return to Burp Suite. In the HTTP history, find any authenticated request from your regular user session.
  • Right-click the request and select Send to Repeater.
  • In Repeater, locate the Cookie header. Find the token cookie value and replace it with your forged JWT.
  • Click Send to submit the request with the forged token.

Why use the cookie instead of the Authorization header?

Juice Shop validates JWT tokens from two sources: the Authorization: Bearer header and the token cookie. The "none" algorithm challenge specifically triggers when the forged token is sent via the cookie. This is because different code paths handle each source with different levels of strictness.

If the server accepts your forged token, you have just achieved admin access without knowing the password or exploiting SQL injection. Check if a challenge-solved notification appears in Juice Shop.

Token rejected or no challenge solved?

Make sure you removed all Base64 padding (= characters) from both the header and payload sections. The token must be URL-safe Base64.

Verify that the trailing period is present at the end of your token. The format must be header.payload. with nothing after the final period.

Confirm you are replacing the token cookie value, not the Authorization header. The challenge detection relies on the cookie path.

help me debug my forged JWT token in Juice Shop

Validate the complete attack chain

You have now completed five distinct exploits, each building on information gathered from the previous one. This is how real penetration testers work. Individual bugs chain together into devastating access.

  • Open the Juice Shop Score Board by navigating to the hidden path you discovered in Step 2.
  • Confirm that all 5 challenges are marked as solved: Score Board discovery, admin login via SQL injection, IDOR basket access, sensitive data exposure, and JWT token forgery.

What is your complete attack chain?

Document the progression you achieved:

  • No access: you started as an anonymous outsider with no credentials.
  • SQL injection: you bypassed authentication to gain admin access through a vulnerable login form.
  • IDOR: you accessed other users' shopping baskets by manipulating API request parameters.
  • Sensitive data exposure: you discovered confidential documents through the exposed /ftp/ directory.
  • JWT forgery: you forged authentication tokens for persistent admin access independent of any login vulnerability.

This chain demonstrates a critical security principle. Each vulnerability alone might seem low-severity, but chained together they escalate from zero access to complete, persistent administrative control.

You just completed a full penetration test. You went from zero knowledge to persistent administrative access using five different vulnerability classes. Next up, take on the Secret Mission for a bonus challenge that tests your ability to crack predictable patterns.

Secret mission

Brute-Force a Coupon Code

You've chained five vulnerabilities into a full admin compromise. Now push further into Broken Anti-Automation territory. Juice Shop's checkout accepts coupon codes, but no valid high-discount coupon is publicly listed. Your mission: reverse-engineer the coupon format using pattern analysis, then weaponize Burp Intruder to brute-force a valid code and apply it to an order.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally with no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Docker container running Juice Shop on port 3000.
  • Juice Shop Docker image (bkimminich/juice-shop).
  • Burp Suite temporary project (auto-discards on close unless explicitly saved).

Keep everything running

No action needed. Choose this if you're still actively practicing against Juice Shop or exploring additional challenges.

  • Your Juice Shop container continues running at http://localhost:3000 at no cost.
  • Docker Desktop uses minimal resources while the container is idle.
  • Burp Suite keeps your HTTP history available for review in the current session.

Pause - I'll come back to this later

Shut down running processes to free up memory. You can restart everything with the same commands later.

  • Stop the Juice Shop container by pressing Ctrl+C in the terminal where it is running.
  • Since you launched with the --rm flag, the container is automatically removed when stopped.
  • Close Burp Suite. Your temporary project is discarded automatically.
  • Restart anytime by running the same command:
docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Challenge progress resets on restart

Juice Shop stores challenge progress in an in-memory database. When the container stops, all solved challenges, registered accounts, and basket contents reset to defaults.

Delete - I don't want to use this again

Remove all project resources and free up disk space.

  • Stop the Juice Shop container by pressing Ctrl+C in the terminal where it is running. The --rm flag automatically removes the container when it stops.
  • Close Burp Suite. Your temporary project is discarded automatically.
  • Remove the Juice Shop Docker image to free disk space by running:
docker rmi bkimminich/juice-shop

This removes the image and frees approximately 150 MB of disk space.

What about Docker Desktop and Burp Suite?

Both are general-purpose security tools you can reuse for future projects. Keep them installed unless you need the disk space.

To uninstall either one, open Settings on your computer, select Apps, then find the application in the list and click Uninstall.

That's a Wrap!

That's a Wrap!

Nice work. You just conducted a professional-grade penetration test against a realistic web application, progressing from zero access to full admin compromise.

You've learned how to:

  • Set up a repeatable offensive security lab using Docker and Burp Suite, intercepting and manipulating live HTTP traffic through a proxy.
  • Exploit multiple OWASP Top 10 vulnerabilities including SQL injection for authentication bypass, IDOR for broken access control, sensitive data exposure through directory enumeration, and JWT token forgery for persistent privilege escalation.
  • Document a complete attack chain showing how individual small bugs combine into a full account takeover, following the same methodology used in real penetration tests and bug bounty programs.
  • Exploit broken anti-automation by analyzing coupon code patterns and brute-forcing valid codes with Burp Intruder.

Ready to quiz yourself?