Labs · Cyber Security

Lab: Run OWASP Juice Shop on 127.0.0.1, Review Its Headers, Cookies and Error Pages, and Write a Fix for Each Finding

By Ravindra Bagale Last updated: 8 October 2026

Intermediate45 minDocker Desktop or Docker Engine · OWASP Juice Shop (training app) · Browser DevTools · curl

Course: Cyber Security · Chapter 21: Web Application Testing Tools

Chapter 21 introduces web application testing tools; this lab practises safe, review-style testing on a training app bound to your own laptop.

Chala mitrano! A web security review is mostly careful looking: what headers does the site send, what does it store in cookies, what does it show when something breaks. Today we practise on OWASP Juice Shop, a shop that is insecure on purpose, running only on our own laptop. And for every finding we write the fix. Chala!

Suppose we are…

Suppose we are an application security trainee at Flipkart. Before any new web feature goes live, the AppSec team does a quick review: security headers, cookie flags and error handling. We practise that review on OWASP Juice Shop, a free training web shop made insecure on purpose by the OWASP community, running at http://127.0.0.1:3000 so nobody else can reach it.

Goal of this lab

By the end you will have:

Juice Shop running on 127.0.0.1 only.
Three findings written up: missing headers, a login token cookie readable by JavaScript, and an error page that leaks a stack trace.
A developer-friendly fix for each finding.

What you need (all free)

Your own laptop with Docker Desktop (Windows/Mac) or Docker Engine (Linux) installed. 4 GB free RAM.
A browser (Chrome, Edge or Firefox) and curl (built into Windows 10+, macOS and Linux; on Windows use curl.exe).
40–45 minutes.

Safety and ethics

Review only your own copy of Juice Shop on 127.0.0.1. Never try these checks against a real shop or app without written permission. This lab is about finding and fixing weaknesses, so it uses no attack payloads.

Steps

Start Juice Shop, bound to your own laptop only (127.0.0.1: in front of the port is the important part):
```
docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop
```
What you should see: after a minute, a log line like info: Server listening on port 3000.
Open http://127.0.0.1:3000 in your browser. Close the welcome banner and the cookie notice.
Finding 1, headers. In a second terminal run:
```
curl -I http://127.0.0.1:3000
```
What you should see: headers such as X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN and Access-Control-Allow-Origin: *, but no Content-Security-Policy and no Referrer-Policy.
Note in your findings sheet: which of the five headers from Lab 8 are present or missing, and why Access-Control-Allow-Origin: * (any website may read responses) is risky for an app with logins.
Finding 2, cookies. Click Account → Login → Not yet a customer? and register a practice account with a fake email such as student@juice-sh.op and a practice password. Log in.
Press F12 → Application tab (Firefox: Storage) → Cookies → http://127.0.0.1:3000. Click the cookie named token.

What you should see: a long value (a JWT login token) with HttpOnly unticked, Secure unticked and SameSite empty.
Go to the Console tab and type document.cookie. The token is printed. This means any injected script could read it.
Finding 3, error handling. Visit an address that does not exist under the API:
```
http://127.0.0.1:3000/rest/does-not-exist
```
What you should see: an error page with Error: Unexpected path: /rest/does-not-exist and a stack trace showing internal file paths. Real users should never see this.
Open http://127.0.0.1:3000/#/score-board. Juice Shop tracks training challenges here; you may see challenges such as Error Handling marked as solved by your review.
Write a fix for each finding in a simple table, Finding → Risk → Fix → How to verify:
- Headers: add Content-Security-Policy and Referrer-Policy: strict-origin-when-cross-origin; replace * with the exact allowed origin. Verify with curl -I.
- Cookie: set the session cookie server-side with HttpOnly; Secure; SameSite=Lax. Verify in DevTools that document.cookie no longer shows it.
- Errors: use a generic error page ("Something went wrong, reference 1234") and log the details on the server only. Verify by revisiting the bad URL.
Stop Juice Shop with Ctrl + C in the first terminal.

Ravindra Bagale's Tip

A finding without a fix is just a complaint. Developers love a report that says exactly what to change and how to check it. And always write "how to verify", because a fix that cannot be tested will quietly come back. Fix ani proof, donhi!

Common mistakes

Mistake	What happens	Fix
Running `-p 3000:3000` without `127.0.0.1:`	The vulnerable app may be reachable from your Wi-Fi network	Always `-p 127.0.0.1:3000:3000`
Registering with your real email and password	A real secret ends up in a training app	Use fake practice details
Checking cookies before logging in	The `token` cookie does not exist yet	Log in first, then open Application → Cookies
Writing "XSS possible" without a fix	Developers cannot act on it	Write the exact fix and how to verify it
Leaving the container running	It keeps using RAM	Ctrl + C; `docker ps` should be empty

Self-check checklist

Juice Shop ran on 127.0.0.1:3000 only.
I listed present and missing security headers.
I found the token cookie and its missing flags.
I saw the stack-trace error page.
I wrote Finding → Risk → Fix → How to verify for all three.
I stopped the container.

0 of 6 done

Try-at-home challenge

From another device on your home Wi-Fi (your phone), try to open http://<your-laptop-IP>:3000. What happens, and why is that the result you want?

Check your answer

It does not load. Because you published the port as 127.0.0.1:3000:3000, Docker listens only on your laptop's loopback address, so nothing on the network can reach the deliberately vulnerable app. That is exactly the isolation you want for a training app.

Samjla ka? Look carefully, write the finding, write the fix, write how to verify. Aata pudhe jaauya: Chapter 22 is all about passwords.