Step 1: Set up the project
Open a terminal, navigate to your development directory, and start Claude Code.
cd ~/dev
claude
Paste this setup prompt:
Create the folder ~/dev/cybersecurity/p5. Download the project materials from https://learnbydirectingai.dev/materials/cybersecurity/p5/materials.zip and extract them into that folder. Read CLAUDE.md -- it's the project governance file. Then start the Docker environment with docker compose up -d from the docker directory.
Claude creates the folder, downloads the materials, reads the governance file, and brings up the Docker containers. The environment includes Juice Shop (the consumer platform), DVWA (at Medium difficulty), and a monitoring stack with Grafana, Loki, and Alloy.
Step 2: Verify the environment
Once the containers are running, open your browser and navigate to http://localhost:3000. This is Juice Shop -- a modern single-page application with a product grid, search bar, and shopping cart. The products are Bulgarian wines from Todorovi Wines.
Open http://localhost:8080 in another tab. This is DVWA, set to Medium difficulty. The interface looks different from Juice Shop -- traditional server-rendered HTML forms instead of a modern JavaScript application.
These two applications represent different architectures. Juice Shop is a single-page application with API endpoints behind the interface. DVWA is a classic PHP application with server-rendered pages. The vulnerabilities you find in each, the tools you use against each, and the detection rules you write for each will differ.
Open http://localhost:3001 in another tab. This is Grafana. Navigate to the Explore view, select the Loki data source, and run a query to see log entries from the applications. Logs flowing means the monitoring stack is collecting data.
Check the container listing:
docker compose ps
You should see five services: juice-shop, dvwa, grafana, loki, and alloy. All running.
Step 3: Read Dimitar's messages
Open the living client interface. Dimitar Todorov, the owner of Todorovi Wines, sent a string of late-night Slack messages after checking his fermentation tanks.
He describes the situation in his own terms. A family winery in the Thracian Valley. Fifteen hectares of vineyards. A two-year-old online platform with two sides: a consumer ordering website and a REST API that 12 restaurant partners use for wholesale orders. The API handles 40% of revenue.
One of those partners, a restaurant in Sofia, flagged "unusual activity" from the API. Their IT person mentioned "injection attacks." Dimitar doesn't know what that means. He wants someone to check the whole platform and tell him what's going on.
Listen to what he says and what he does not say. He mentions the consumer platform and the restaurant API, but not how the API authenticates partners. He mentions customer accounts but not what data they store. He mentions restaurant partners but not whether they can see each other's information. The gap between what a client tells you and what you need to know is where your questions begin.
Step 4: Contact Dimitar
Choose one of the response options and send your initial message.
Dimitar's messages give the outline, but the assessment scope requires more detail. Think about what you need to know before you start scanning:
- How does the API authenticate restaurant partners? API keys? Tokens? Passwords?
- What data can a partner access through the API? Just their own orders, or other partners' information?
- What customer data does the platform store? Names and emails, or more?
- Who built the platform? Who maintains it now?
Send at least two follow-up questions. Dimitar responds warmly, often late at night, and sometimes compares security to winemaking. He answers what you ask. He does not volunteer technical details he hasn't thought to mention.
Step 5: Read the scope document
Open materials/scope-document.md.
Two attack surfaces are explicitly in scope: the consumer web platform and the restaurant API. The monitoring stack and Docker infrastructure are also scoped for assessment and hardening. The out-of-scope section is equally important -- Dimitar's nephew's mobile app, Stripe payment processing, and production systems are all excluded.
The rules of engagement require scanner scope configuration before any automated testing. ZAP must not crawl outside the engagement boundary. Nuclei must only scan authorised targets. This is not a convenience setting -- it is a professional and legal requirement.
Check: Juice Shop running and accessible at its URL, DVWA at Medium difficulty accessible, Grafana showing log data from both applications, at least two clarifying questions sent to Dimitar about the API.