Bug Bounty Starter Lab: Juice Shop, Burp and Scope

Pull the official image and run it, pinned to the loopback address so it is never exposed to your network:

$ docker pull bkimminich/juice-shop
$ docker run -d --rm --name juice -p 127.0.0.1:3000:3000 bkimminich/juice-shop

The important part is -p 127.0.0.1:3000:3000. The plain form, -p 3000:3000, binds to every interface, so anyone on your Wi-Fi could reach your deliberately vulnerable app. The 127.0.0.1: prefix says “this port exists for this machine only”.

Why this matters. A practice target is a vulnerable target. The whole point of Juice Shop is that it is broken on purpose — which is exactly why it must never be reachable by anyone but you. Getting the bind address right is the first real security decision in the lab, not an afterthought.

Juice Shop takes a few seconds to boot. Check it is answering with one line:

$ curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:3000/

You should see 200. Now open http://127.0.0.1:3000 in a browser — the tab title reads OWASP Juice Shop and a shop full of fictional juices loads. Dismiss the welcome and cookie banners. That is your target, running entirely on your machine.

Why this matters. Half of “my tools do not work” is really “my target was not up yet”. Proving the plain request works first means that if Burp later shows nothing, you know the problem is Burp, not the app.

Open Burp Suite Community and accept a temporary project (the free edition cannot save projects — that is normal). Go to the Proxy tab, then Intercept, and click Open Browser to launch Burp’s own browser. In that browser, go to http://127.0.0.1:3000.

By default Intercept is on, so the first request will pause, waiting for you. Click Forward a few times to let the page load, or just toggle Intercept off and browse normally — Burp still records everything in the background.

Use Burp’s browser, not yours. I know you want to use your own with your logins and your forty tabs. Your browser quietly refuses to send loopback traffic through the proxy, Burp shows an empty history, and you conclude the software is broken. It is not broken. It is Tuesday. — Nyx

Why this matters. A proxy is the single most useful tool in web testing because it lets you see and change every request your browser makes. Everything later — editing a parameter, replaying a request, reading an API call — happens here. Getting the browser to actually route through Burp is the whole game at this stage.

Juice Shop tracks your progress on a Score Board that is hidden until you find it — and finding it is, by design, the very first challenge (difficulty 1, tagged “Tutorial”). It is the gentlest possible first result: no exploit, just a look at how the app is put together.

The page exists in the app’s front-end code even though no menu links to it. Modern single-page apps ship their routes in a JavaScript bundle the browser downloads, so the route name is sitting there to be read. Once you know the route, you visit it directly — it lives under /#/score-board. When it loads, the board lights up and your Score Board challenge flips to solved.

That is the whole technique at this level, and it is deliberately not an exploit. For how it works in detail — and dozens of progressively harder challenges — use Juice Shop’s own companion guide rather than any third-party walkthrough:

• Pwning OWASP Juice Shop — the project’s official, free guide to every challenge.
• OWASP Juice Shop project page — what the app is and why it exists.

Why this matters. “Read the code the app already sent you” is a real first instinct in web testing: the client is not a safe place to hide anything. You just used it to find a page the app did not advertise, with no attack at all.

Back in Burp, open Proxy → HTTP history. Every request the page made is listed. Click one of the /rest/ or /api/ calls and read the panes: the Request on the left (method, path, headers, any body) and the Response on the right (status, headers, the JSON that came back).

Right-click a request and choose Send to Repeater. In the Repeater tab you can change the request and press Send to see the new response, again and again, without touching the browser. Change nothing dangerous — just change a value and watch the response move. That loop, look then change then look again, is the core of manual testing.

Why this matters. The difference between a scanner and a hunter is right here. A scanner fires thousands of requests and hopes. A person reads one request, understands what the server trusts, and changes exactly one thing. The second approach is what finds the bugs the scanners miss — and it is almost always what a program’s scope allows and automated noise does not.

This is the half that matters. Every legitimate program publishes a scope: the exact assets you are allowed to test, the ones you are not, and the rules for how. Here is a fictional program — “Acme Widgets Public Bug Bounty” — written the way real ones are. Read each line and decide: in, or out?

The pattern: a name that contains the company’s brand is not the same as an asset the company owns and has put in scope. Third-party vendors, partners, and anything hosting the company’s name on someone else’s infrastructure are out unless the policy says otherwise in plain words.

Nyx wanted to test status.acme-widgets.example because it was “basically theirs”. It is not basically theirs. It is a status-page company’s box with Acme’s logo on it, and testing it is testing a company that never invited you. “Basically” is not in any scope I have ever read. — Nyx

Why this matters. Testing an out-of-scope asset is not a minor foul. Even with good intentions, it can be unauthorised access — the program’s authorisation only covers what the program listed. When in doubt, an asset is out until the policy says it is in.

Next to the asset list, every program states rules. Three show up almost everywhere, and each one means something specific:

• No automated scanning. Do not aim Burp’s active scanner, a vulnerability scanner, or a fuzzer at the live target. It generates huge traffic, trips alarms, and can break things. Manual testing and reading responses by hand — what you did in step 5 — is what they want. (Juice Shop on your own machine is the place to let scanners run, if you want to learn them.)
• No DoS / no stress testing. Do not try to take the service down, flood it, or test “how much load before it breaks”. Availability testing is off-limits because the target is a production system real customers depend on. Finding a bug is fine; proving it by knocking the site over is not.
• No social engineering. Do not phish, call, or trick staff or users into handing over access. The program authorises you to test systems, never people. This also rules out testing other users’ accounts — you use your own test accounts only.

Two more worth knowing: report, do not exploit (prove a bug exists with the least intrusion needed, then stop — do not read other people’s data, pivot deeper, or leave anything behind), and respect any rate limit or test-account rule the policy sets.

Why this matters. These rules are not red tape; they are the line between “authorised security research” and “an incident’. Break them and even a genuine finding can get your report closed, your account banned, and — for DoS or going past proof — worse. Staying inside them is also exactly the skill a blue team or pentest employer is paying for.

Before you send a single request to anything that is not your own lab, run this list. It takes two minutes and it is the difference between research and a crime:

• Is there a published program? A real policy page on a platform or the company’s own /security or security.txt. No published program means no permission — full stop.
• Is this exact asset listed as in scope? Match the hostname, the IP range, or the app ID against the scope, the way you did in step 6. Brand name in the domain is not enough.
• Is it explicitly out of scope? Re-read the out-of-scope list. Third-party, partner, and vendor assets hide here.
• What do the rules forbid? Automated scanning, DoS, social engineering, rate limits, test-account rules — know them before you act, not after.
• Am I using my own test account? Never another user’s data or session.
• Do I have the scope and date saved? Scopes change. Screenshot or save the policy as it was when you tested, so you can show what you were authorised to do.
• When I find something, do I stop at proof? Minimum demonstration, then write it up. No pivoting, no extra poking.

If you cannot tick every box, the answer is not “probably fine”. The answer is Juice Shop, which is sitting right there on your laptop asking to be attacked and legally cannot say no. — Nyx

Why this matters. Every experienced hunter runs some version of this list, even if it has become automatic. You are building the habit now, on a day when the stakes are zero, so it is already there on the day they are not.