OWASP Juice Shop TryHackMe Walkthrough (2026)

The OWASP Juice Shop room on TryHackMe is one of the most popular entry points for learning web application security. It gives you a private, hosted Juice Shop instance and guides you through eight task categories — from finding the admin page to exploiting SQL injection and XSS.

This walkthrough covers every task in the TryHackMe Juice Shop room with full explanations of what’s happening technically and why each vulnerability matters.

---

Getting Started: Setting Up the TryHackMe Room

Before you begin:

1. Start the TryHackMe machine — in the Juice Shop room, click “Start Machine” to provision your dedicated Juice Shop instance. You’ll receive an IP address (e.g., 10.10.x.x).

2. Connect via VPN — download the TryHackMe OpenVPN configuration from your account and connect:

   sudo openvpn your-vpn-config.ovpn

   Or use the browser-based AttackBox (no VPN required).

3. Open Juice Shop — navigate to http://MACHINE_IP in your browser. You should see the OWASP Juice Shop storefront.

4. Open your browser’s DevTools — press F12. The Network tab will be essential throughout this walkthrough.

---

Task 1: Open for Business

What Is Juice Shop?

OWASP Juice Shop is a deliberately vulnerable web application — a realistic-looking e-commerce store built with intentional security flaws. Every part of the application contains vulnerabilities corresponding to the OWASP Top 10 categories. The TryHackMe room walks you through finding and exploiting them in a guided, structured way.

The room covers:

• Open-source intelligence (OSINT) — finding hidden information in the application
• Injection attacks — SQL injection, XSS, command injection
• Authentication bypass — broken login logic, brute force
• Broken access control — accessing resources you shouldn’t
• Sensitive data exposure — finding leaked credentials and configuration data

---

Task 2: Recon and Information Gathering

The first step in any web application assessment is reconnaissance — understanding the application’s structure, endpoints, and behavior before attempting exploitation.

Finding the Admin Page

The scoreboard itself is Task 2’s first challenge. The scoreboard is not linked from the navigation — you must discover it.

Method 1: Direct navigation Navigate to http://MACHINE_IP/#/score-board. This is the intended answer and the fastest route.

Method 2: Source enumeration Open DevTools → Sources. Search in main.js for the word “score”:

# In DevTools Console:
fetch('/main.js').then(r => r.text()).then(t => {
  const matches = t.match(/'[^']*score[^']*'/gi);
  console.log(matches);
});

You’ll find references to /#/score-board in the application’s routing configuration.

Why this matters: Security through obscurity — hiding URLs without authentication — is not a security control. An API that returns all route definitions to the frontend (including “hidden” admin routes) is disclosing application structure to any attacker who inspects the JavaScript.

Finding the Admin Email

In the TryHackMe room, you’ll be asked to find the admin’s email address. It’s visible in product reviews.

Steps:

1. Go to any product (e.g., Apple Juice)
2. Scroll down to the reviews section
3. The review from [email protected] shows the admin’s email address

This demonstrates information disclosure — sensitive data (internal email address, user enumeration) exposed in publicly visible content.

---

Task 3: Inject the Juice — SQL Injection

SQL injection is the most fundamental Juice Shop challenge and one of the most impactful vulnerability classes in real-world applications.

Login Bypass with SQL Injection

Goal: Log in as the admin without knowing the password.

Steps:

1. Navigate to http://MACHINE_IP/#/login
2. In the Email field, enter:

   ' OR 1=1--

3. In the Password field, enter anything (e.g., password)
4. Click “Log In”

You are now logged in as the first user in the database — which is the admin.

What happened technically:

The application builds a SQL query like this:

SELECT * FROM Users WHERE email = '[input]' AND password = '[hash]'

After your injection, it becomes:

SELECT * FROM Users WHERE email = '' OR 1=1-- AND password = '...'

The -- comments out the rest of the query. The OR 1=1 condition is always true, so the query returns all users — and the application logs you in as the first result (admin).

In the real world: SQL injection in login forms is found in legacy PHP, ASP.NET, and Java applications that build queries by concatenating strings rather than using parameterized queries. It’s been a top-10 vulnerability since OWASP began tracking in 2003.

The fix: Use parameterized queries (prepared statements). The user-supplied value is then passed as a parameter, not embedded in the SQL string — making injection impossible.

---

Searching with SQL Injection

Goal: Use SQL injection in the search bar to list all products, including hidden ones.

Steps:

1. In the search bar, enter:

   ')--

2. Press Enter

The search returns all products, including ones not shown in the normal storefront.

What happened: The search query probably looks like:

SELECT * FROM Products WHERE name LIKE '%[input]%'

Your payload closes the LIKE pattern and comments out the rest:

SELECT * FROM Products WHERE name LIKE '%')-- %'

This becomes a query that returns all rows (without the WHERE filter).

---

Task 4: Who Broke My Lock? — Broken Authentication

Brute Forcing the Admin Password

Goal: Find the admin’s password using a wordlist attack.

In a real assessment, you’d use a tool like hydra or Burp Suite’s Intruder module. In the TryHackMe room, the key insight is recognizing that Juice Shop has no rate limiting on login attempts — an attacker can try thousands of passwords without being blocked.

Common admin password: The Juice Shop default admin password is admin123. Try it directly:

• Email: [email protected]
• Password: admin123

Using Burp Suite Intruder (full attack):

1. Log in to Burp Suite and configure your browser to proxy through 127.0.0.1:8080
2. Try to log in with any credentials
3. Intercept the login POST request in Burp Proxy
4. Send it to Intruder (Ctrl+I)
5. Mark the password field as the injection position
6. Load a wordlist (SecLists darkweb2017-top10000.txt works well)
7. Start the attack and look for a response with a different size (success vs. failure)

The fix: Rate limiting, account lockout after N failed attempts, and CAPTCHA on authentication endpoints. Without these, any login page is brute-forceable.

---

Resetting Jim’s Password

Goal: Reset another user’s password by answering their security question.

Steps:

1. Click “Forgot Password” on the login page
2. Enter [email protected] in the email field
3. The security question appears: “Your eldest sibling’s middle name?”
4. The answer is Samuel — based on Jim’s profile referencing Star Trek (Jim Kirk’s brother’s name)
5. Set any new password

The vulnerability: Security questions with publicly guessable or researchable answers provide no real security. An attacker who knows basic information about a target (public social media, OSINT) can easily bypass this authentication factor.

---

Task 5: AH! Don’t Look! — Sensitive Data Exposure

Accessing the Confidential Document

Goal: Find and access a confidential file that is publicly accessible.

Steps:

1. Navigate to http://MACHINE_IP/ftp/
2. You’ll see a directory listing of files, including acquisitions.md
3. Download acquisitions.md

What happened: The /ftp/ directory is publicly accessible with directory listing enabled — an attacker can browse and download any file in it. acquisitions.md contains confidential business information.

The fix: Disable directory listing on web servers. Restrict access to sensitive directories via authentication middleware. Never store confidential documents in web-accessible directories.

---

Finding the Admin Credentials in the Source

Goal: Find a credential embedded in the application source.

Steps:

1. Open DevTools → Sources
2. Load http://MACHINE_IP/ and examine the JavaScript files
3. Search in main.js for the word password or credentials
4. Alternatively, navigate to http://MACHINE_IP/rest/qrobot (the feedback endpoint) and check response headers

The admin hash is stored in the database and visible through the SQL injection you’ve already demonstrated. The more interesting exercise is searching the JavaScript source for any configuration that reveals credentials or internal API endpoints.

---

Task 6: Who’s Flying This Plane? — Broken Access Control

Accessing the Admin Section

Goal: Reach the administration panel at /#/administration without having admin privileges initially.

Steps:

1. First, find the admin panel URL in the JavaScript source (/#/administration)
2. Log in as any user
3. Navigate to http://MACHINE_IP/#/administration

If you’re already logged in as the admin (from the SQL injection task), this works immediately. If logged in as a regular user, you’ll be redirected — demonstrating that the route exists but requires authorization.

The full access control bypass requires being logged in as the admin, which you achieved through SQL injection. This demonstrates how chained vulnerabilities work in practice: SQL injection → authentication bypass → access control bypass → admin panel access.

---

Viewing Another User’s Shopping Basket (IDOR)

Goal: Access another user’s shopping basket.

IDOR (Insecure Direct Object Reference) is OWASP API Security’s #1 vulnerability — Broken Object Level Authorization (BOLA).

Steps:

1. Log in as any user
2. Add something to your basket
3. Click the basket icon — observe the URL or API call in DevTools Network tab
4. The request is GET /rest/basket/[ID] where ID is your user’s basket ID
5. Change the ID to 1 (or another user’s ID): GET /rest/basket/1

What happened: The API doesn’t verify that the authenticated user owns basket ID 1 — it just returns whatever basket ID is requested. Any authenticated user can access any other user’s basket.

In the real world: IDOR is one of the most commonly exploited vulnerabilities in REST APIs. Any time an API uses numeric IDs in URLs without authorization checks, the potential for IDOR exists.

The fix: On the server side, verify that the authenticated user is authorized to access the requested resource, not just that they are authenticated at all.

---

Task 7: Where Did That Come From? — Cross-Site Scripting (XSS)

Reflected XSS in the Search Bar

Goal: Execute a reflected XSS payload in the search bar.

Steps:

1. In the search bar, enter:

   <iframe src="javascript:alert('xss')">

2. Press Enter

An alert box should appear with “xss”. Alternatively, if the <script> tag is filtered:

<script>alert('XSS')</script>

Try various evasions if the basic payload is filtered:

"><img src=x onerror=alert('xss')>

What happened: The search term is reflected back in the page HTML without proper encoding. The browser interprets the injected HTML/JavaScript and executes it in the context of the Juice Shop origin — meaning it has access to cookies, localStorage, and can make authenticated API requests.

In the real world: Reflected XSS requires a victim to click a crafted link. While less impactful than stored XSS, it is used in phishing attacks and session hijacking.

---

Stored XSS via Product Reviews

Goal: Store an XSS payload in a product review that executes when the page is viewed.

Steps:

1. Navigate to any product
2. Click on the product to open its detail page
3. Scroll to the review section
4. Enter a review containing:

   <iframe width="100%" height="166" scrolling="no" frameborder="no" allow="autoplay" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/771984076&color=%23ff5500">

   Or a simpler payload:

   <<script>Redirect</script>iFrame src="javascript:alert(`xss`)">

5. Submit the review
6. When any user (including the admin) views the product page, the stored XSS executes

Why stored XSS is more dangerous: Reflected XSS requires the victim to click a link. Stored XSS executes automatically for every user who views the affected page — no social engineering required. The admin viewing the compromised product page could trigger the XSS and send their session token to an attacker.

---

Task 8: Exploration!

The final task in the TryHackMe Juice Shop room encourages continued exploration — completing more challenges from the scoreboard and developing your own techniques.

Recommended Next Challenges from the Scoreboard

Two-star challenges to try next:

• Admin Registration — register as a user with admin role
• Five Star Feedback — delete a five-star review (requires IDOR on the feedback API)
• Login Jim — log in as Jim without his password (check the review he left)

Three-star challenges:

• JWT Algorithm Confusion — forge an admin token by exploiting the “none” algorithm variant
• XXE in Profile Picture — upload an XML file to the profile picture endpoint and read server files

Approach for any Juice Shop challenge:

1. Check the scoreboard hint (lightbulb icon)
2. Open DevTools Network tab and watch API calls as you interact with the feature
3. Try the most obvious approach first (modify IDs, inject common payloads)
4. For harder challenges, examine the JavaScript source for route definitions and API calls

---

What These Vulnerabilities Mean in the Real World

Every vulnerability in the TryHackMe Juice Shop room maps directly to real enterprise application risks:

Juice Shop Vulnerability	Real-World Example
SQL injection in login	Login bypass in a PHP banking app using string-concatenated queries
IDOR in basket API	Accessing other customers’ orders in an e-commerce API
Stored XSS in reviews	Session hijacking via comment fields in a CRM or ticketing system
Security question bypass	Password reset attacks on real consumer applications
Directory listing in /ftp/	Exposed backup files, config exports, or dev artifacts on production servers

Juice Shop’s TryHackMe room teaches the mental model for finding these vulnerabilities — not just the specific payloads. In a real assessment, the application is different, but the patterns are identical.

---

Frequently Asked Questions

Do I need to install anything to do the TryHackMe Juice Shop room?

No installation is needed. TryHackMe provisions a dedicated Juice Shop instance accessible via your browser. You either connect via VPN (download from your TryHackMe account) or use TryHackMe’s browser-based AttackBox, which includes all necessary tools.

What is the Juice Shop TryHackMe room password?

There is no room password for the OWASP Juice Shop room on TryHackMe — it’s publicly accessible to any registered TryHackMe user. Search for “OWASP Juice Shop” in the TryHackMe room library.

What tools do I need for the Juice Shop TryHackMe room?

The essential tools are:

• Browser with DevTools — Chrome or Firefox (built-in, no install needed)
• Burp Suite Community Edition — for intercepting and modifying HTTP requests (free download from PortSwigger)
• VPN client — to connect to the TryHackMe network (OpenVPN, downloaded from TryHackMe)

All of these are free. For the brute force tasks, Burp Suite’s Intruder module handles the attack.

What is the admin password in OWASP Juice Shop?

The default Juice Shop admin password is admin123. In the TryHackMe room, you can discover it via brute force or bypass authentication entirely using SQL injection (' OR 1=1-- in the email field).

Is there an official Juice Shop walkthrough?

Yes — the official companion guide is Pwning OWASP Juice Shop, available free at pwning.owasp-juice.shop. It provides detailed solutions for all 100+ Juice Shop challenges, with explanations of the underlying vulnerability mechanics.

---

Summary: Key Takeaways from the TryHackMe Juice Shop Room

Task	Vulnerability	Key Technique
Admin page discovery	Security through obscurity	JavaScript source enumeration
Login bypass	SQL Injection	' OR 1=1-- in email field
Admin password	Brute force (no rate limiting)	Burp Intruder with wordlist
Password reset bypass	Insecure security question	OSINT on target’s interests
Directory listing	Sensitive data exposure	Direct URL navigation to /ftp/
Basket IDOR	Broken access control	Modify basket ID in API request
Search XSS	Reflected XSS	<iframe src="javascript:alert()">
Review XSS	Stored XSS	Payload in product review

The TryHackMe Juice Shop room is one of the best introductions to web application security — structured enough for beginners, realistic enough to build transferable skills.

---

To run your own private Juice Shop instance beyond the TryHackMe room, see our complete OWASP Juice Shop setup guide. For the full challenge walkthrough beyond the TryHackMe tasks, see Juice Shop XSS, SQL injection & IDOR solutions.