Applications

Supported Offerings

This repository provides two distinct origins; they are not feature-equivalent:

Azure full-origin: a VM running nginx in front of 41 containers for all nine applications and the path-based URLs documented below. Set ORIGIN from terraform output -raw origin_url in terraform/.
AWS Juice Shop: private Fargate tasks behind an Application Load Balancer (ALB). It serves Juice Shop directly at the ALB root (/), not at /juice-shop/. Set ORIGIN from the consuming configuration’s module output, for example terraform output -raw origin_url. The ALB is internal by default, so that URL resolves and responds only from an authorized routed network unless public exposure was explicitly configured.

The AWS module does not deploy nginx, a container host, or the other eight applications. Every path in the quick reference below, including non-Juice-Shop APIs, requires the Azure full-origin unless stated otherwise.

Azure Full-Origin URL Reference

Path	Application	HTTP Method	Expected Response
`/`	Landing page	GET	200 HTML with links to all apps
`/health`	Health check	GET	200 JSON `{"status":"healthy","component":"origin-server",...}`
`/juice-shop/`	Juice Shop	GET	200 HTML (Angular SPA, ~75 KB)
`/juice-shop/rest/products/search?q=`	Juice Shop API	GET	200 JSON `{"status":"success","data":[...]}` (36 products)
`/dvwa/`	DVWA	GET	302 redirect to `/dvwa/login.php`
`/dvwa/login.php`	DVWA login	GET	200 HTML login form
`/dvwa/setup.php`	DVWA setup	GET	200 HTML (first-run database init)
`/vampi/`	VAmPI	GET	200 HTML (API docs)
`/vampi/users/v1`	VAmPI API	GET	200 JSON `{"users":[...]}`
`/vampi/users/v1/register`	VAmPI API	POST	200 JSON `{"status":"success",...}`
`/vampi/users/v1/login`	VAmPI API	POST	200 JSON `{"auth_token":"...","status":"success"}`
`/httpbin/get`	httpbin	GET	200 JSON with request details
`/httpbin/post`	httpbin	POST	200 JSON with posted data
`/httpbin/headers`	httpbin	GET	200 JSON `{"headers":{...}}`
`/httpbin/status/:code`	httpbin	GET	Returns the specified HTTP status code
`/whoami/`	whoami	GET	200 plain text with hostname, IP, all headers
`/csd-demo/`	CSD Demo	GET	200 HTML checkout form with attack panel
`/csd-demo/dashboard`	CSD attacker view	GET	200 HTML showing exfiltrated data
`/csd-demo/health`	CSD health	GET	200 JSON `{"status":"healthy","component":"csd-demo",...}`
`/csd-demo/exfil/log`	CSD exfil log	GET	200 JSON array of captured data
`/dvga/`	DVGA GraphiQL	GET	200 HTML (GraphiQL IDE)
`/dvga/graphql`	DVGA GraphQL API	POST	200 JSON GraphQL response
`/restaurant/`	RESTaurant	GET	200 (redirects to docs)
`/restaurant/docs`	RESTaurant Swagger	GET	200 HTML (FastAPI Swagger UI)
`/restaurant/openapi.json`	RESTaurant OpenAPI	GET	200 JSON OpenAPI spec
`http://<PUBLIC_IP>:8888`	crAPI	GET	200 HTML (SPA)
`http://<PUBLIC_IP>:8888/identity/api/auth/signup`	crAPI signup	POST	200 JSON
`http://<PUBLIC_IP>:8888/identity/api/auth/login`	crAPI login	POST	200 JSON `{"token":"..."}`

OWASP Juice Shop

OWASP Juice Shop is the most modern and actively maintained vulnerable web application. It covers the entire OWASP Top 10 with 100+ challenges in a realistic e-commerce application.

Offering	URL behavior	Runtime
Azure full-origin	`${ORIGIN}/juice-shop/`	Four Docker containers behind nginx with sticky routing and a 60-second proxy-cache TTL
AWS Juice Shop	`${ORIGIN}/`	Private Fargate task or tasks behind an ALB; no nginx or host SSH

For Azure, obtain ORIGIN from the root configuration:

ORIGIN=$(terraform -chdir=terraform output -raw origin_url)
curl -sf "${ORIGIN}/juice-shop/" -o /dev/null -w "%{http_code}\n"

For AWS, expose the module’s origin_url from the consuming root configuration and use it without a /juice-shop/ prefix:

output "origin_url" {
  value = module.juice_shop.origin_url
}

ORIGIN=$(terraform output -raw origin_url)
curl -sf "${ORIGIN}/" -o /dev/null -w "%{http_code}\n"
curl -sf "${ORIGIN}/rest/products/search?q=" | jq .

Juice Shop demo scenarios

Scenario	Category	Attack Vector
SQL Injection login bypass	WAF	`' OR 1=1--` in the login email field
Reflected XSS	WAF, CSD	Script injection via search parameter
DOM-based XSS	CSD	Payload in URL fragment
Broken authentication	WAF	Brute force login, JWT manipulation
API abuse	API Security	Unauthorized access to `/api/` endpoints
Sensitive data exposure	API Security	Accessing user data without authorization
CSRF	WAF	Cross-site request forgery on profile changes

DVWA (Damn Vulnerable Web Application)


Path	`/dvwa/`
Image	Custom `dvwa-fpm:latest` (php-fpm + nginx, built from `ghcr.io/digininja/dvwa:latest`)
Instances	4 (ports 8101-8104), sticky via `hash $cookie_PHPSESSID`
Resources	0.5 CPU / 256 MiB RAM per instance
Database	Shared MariaDB 10.11 (`dvwa-db` container, 1 CPU / 768 MiB)
Framework	PHP 8 / php-fpm / MariaDB
Credentials	`admin` / `password`

DVWA is the industry standard for WAF testing. It has adjustable security levels (Low, Medium, High, Impossible) that progressively add input validation and output encoding.

DVWA demo scenarios

Scenario	Category	Security Level
SQL Injection	WAF	Low: trivial `' OR 1=1#`, High: blind SQLi
Command Injection	WAF	Low: `; ls`, High: filtered characters
File Inclusion	WAF	Low: direct path traversal, High: sanitized
XSS (Reflected)	WAF, CSD	Low: basic `<script>`, High: encoded bypass
XSS (Stored)	WAF, CSD	Low: persistent script in guestbook
File Upload	WAF	Low: PHP shell upload, High: extension filtering
Brute Force	Bot Defense	Automated login attempts

Security Levels

Set the security level at /dvwa/security.php after logging in:

Low — No input validation. Every attack works. Good for WAF signature demonstrations.
Medium — Basic filtering. Some attacks require encoding or bypass techniques.
High — Strong filtering. Only advanced techniques succeed. Good for showing WAF limitations.
Impossible — Fully secure implementation. Demonstrates proper defensive coding.

Initial Setup

DVWA requires a one-time database setup after first deployment:

Navigate to http://<PUBLIC_IP>/dvwa/setup.php
Click Create / Reset Database
Log in with admin / password

VAmPI (Vulnerable API)


Path	`/vampi/`
Image	`erev0s/vampi:latest` with gunicorn entrypoint (4 workers)
Instances	4 (ports 5101-5104), sticky via `ip_hash` (SQLite per instance)
Resources	0.5 CPU / 512 MiB RAM per instance
Framework	Python / Flask / gunicorn
Project	github.com/erev0s/VAmPI

VAmPI is purpose-built for testing the OWASP API Security Top 10. It provides a realistic REST API with deliberate vulnerabilities. Each instance runs gunicorn with 4 workers and its own SQLite database. The ip_hash sticky session ensures registration and login from the same client IP always hit the same instance.

VAmPI demo scenarios

Scenario	OWASP API Top 10	Method
Broken Object Level Authorization (BOLA)	API1	Access other users’ data by manipulating IDs
Broken Authentication	API2	Weak token handling, no rate limiting
Excessive Data Exposure	API3	API returns more data than the client needs
Mass Assignment	API6	Modify admin fields via unexpected parameters
SQL Injection	API8	Injection through API parameters
Improper Assets Management	API9	Undocumented API endpoints

API Endpoints

# Register a new user
curl -X POST "http://<PUBLIC_IP>/vampi/users/v1/register" \
  -H "Content-Type: application/json" \
  -d '{"username":"test","password":"test123","email":"admin@example.com"}'

# Login
curl -X POST "http://<PUBLIC_IP>/vampi/users/v1/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"test","password":"test123"}'

# List users (excessive data exposure)
curl "http://<PUBLIC_IP>/vampi/users/v1"

httpbin


Path	`/httpbin/`
Image	`kennethreitz/httpbin:latest` with gunicorn CMD override (`-w 4 -k gevent --timeout 30`)
Instances	4 (ports 8201-8204), round-robin (stateless)
Resources	0.5 CPU / 256 MiB RAM per instance
Framework	Python / Flask / gunicorn + gevent
Project	httpbin.org

httpbin is a simple HTTP request/response service useful for basic API demos, testing request headers, and verifying proxy behavior.

Useful Endpoints

Endpoint	Purpose
`/httpbin/get`	Returns GET request data (headers, args, origin)
`/httpbin/post`	Returns POST request data (body, form, JSON)
`/httpbin/headers`	Returns request headers
`/httpbin/ip`	Returns origin IP
`/httpbin/user-agent`	Returns User-Agent header
`/httpbin/status/:code`	Returns specified HTTP status code
`/httpbin/delay/:seconds`	Delays response by N seconds
`/httpbin/anything`	Returns anything passed in request

httpbin example

# Check what headers the origin sees (useful for verifying F5 XC header injection)
curl -s "http://<PUBLIC_IP>/httpbin/headers" | jq .

# Test a specific HTTP status code
curl -s -o /dev/null -w "%{http_code}" "http://<PUBLIC_IP>/httpbin/status/403"

whoami (Request Diagnostics)


Path	`/whoami/`
Image	`traefik/whoami:latest`
Instances	4 (ports 8082-8085), round-robin (stateless)
Resources	0.25 CPU / 64 MiB RAM per instance
Framework	Go
Project	github.com/traefik/whoami

whoami is Traefik’s lightweight request echo server. It displays every detail of the incoming HTTP request as the origin sees it — hostname, IP addresses, all headers, method, and URL. This is the single most important diagnostic tool when verifying that F5 XC is injecting the correct headers.

Key Use Cases

Use Case	What to Look For
Verify F5 XC header injection	`X-Forwarded-For`, `True-Client-IP`, `X-Volterra-*` headers
Confirm client IP visibility	`X-Real-IP` vs `RemoteAddr`
Debug WAF false positives	Compare request headers before/after F5 XC
Validate bot defense tagging	`X-Volterra-Bot-Type`, `X-Volterra-Bot-Verified` headers
Check TLS termination	`X-Forwarded-Proto` shows `https` when TLS terminates at F5 XC

whoami example

# Basic request -- see what the origin receives
curl "http://<PUBLIC_IP>/whoami/"

# Simulate request through F5 XC (with injected headers)
curl "http://<PUBLIC_IP>/whoami/" \
  -H "X-Forwarded-For: 203.0.113.50" \
  -H "True-Client-IP: 203.0.113.50" \
  -H "X-Forwarded-Proto: https"

Example output:

Hostname: <container-hostname>
IP: <container-loopback-ip>
RemoteAddr: <immediate-peer-ip>:<ephemeral-port>
GET / HTTP/1.1
Host: <origin-hostname-or-ip>
User-Agent: curl/<version>
Accept: */*
True-Client-Ip: <simulated-client-ip>
X-Forwarded-For: <simulated-client-ip>, <trusted-proxy-ip>
X-Forwarded-Proto: https
X-Real-Ip: <observed-client-ip>

DVGA (Damn Vulnerable GraphQL Application)


Path	`/dvga/`
Image	`dolevf/dvga:latest`
Instances	4 (ports 5201-5204), sticky via `ip_hash` (SQLite per instance)
Resources	0.5 CPU / 256 MiB RAM per instance
Framework	Python / Flask / GraphQL
Project	github.com/dolevf/Damn-Vulnerable-GraphQL-Application

DVGA is purpose-built for testing GraphQL-specific vulnerabilities. It provides a GraphiQL IDE at /dvga/ for interactive query exploration and a GraphQL API endpoint at /dvga/graphql. Each instance uses its own SQLite database, so ip_hash sticky sessions ensure consistent state.

DVGA demo scenarios

Scenario	Category	Attack Vector
GraphQL Injection	API Security	Malicious queries via string interpolation
Denial of Service	API Security	Deeply nested queries, batch queries, resource exhaustion
Authorization Bypass	API Security	Accessing unauthorized data through GraphQL
Information Disclosure	API Security	Introspection queries revealing schema details
Batching Attack	API Security	Multiple operations in a single request

DVGA key endpoints

# GraphiQL UI (interactive IDE)
curl -sf "http://<PUBLIC_IP>/dvga/" -o /dev/null -w "%{http_code}"

# Introspection query -- enumerate the full schema
curl -s "http://<PUBLIC_IP>/dvga/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ __schema { types { name fields { name } } } }"}'

# List pastes (example query)
curl -s "http://<PUBLIC_IP>/dvga/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ pastes { title content } }"}'

# Create a paste (mutation)
curl -s "http://<PUBLIC_IP>/dvga/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"mutation { createPaste(title:\"test\", content:\"hello\", public:true) { paste { title } } }"}'

RESTaurant (Damn Vulnerable RESTaurant API Game)


Path	`/restaurant/`
Image	Custom build from `theowni/Damn-Vulnerable-RESTaurant-API-Game`
Instances	4 (ports 8301-8304), round-robin (shared PostgreSQL)
Resources	0.5 CPU / 256 MiB RAM per instance
Database	Shared PostgreSQL 15.4 (`restaurant-db` container, 0.5 CPU / 512 MiB)
Framework	Python / FastAPI / PostgreSQL
Credentials	`admin` / `password` (PostgreSQL)
Project	github.com/theowni/Damn-Vulnerable-RESTaurant-API-Game

RESTaurant is a gamified vulnerable REST API covering the OWASP API Security Top 10 2023. It uses FastAPI with automatic Swagger UI documentation at /restaurant/docs. All 4 instances share a single PostgreSQL database, so round-robin load balancing works without sticky sessions.

RESTaurant demo scenarios

Scenario	OWASP API Top 10 2023	Method
Broken Object Level Authorization (BOLA)	API1	Access other users’ orders by manipulating IDs
Broken Authentication	API2	Weak token handling, credential stuffing
Broken Object Property Level Authorization	API3	Mass assignment on user profile fields
Unrestricted Resource Consumption	API4	No rate limiting on endpoints
Broken Function Level Authorization (BFLA)	API5	Access admin endpoints as regular user
Server Side Request Forgery (SSRF)	API7	Manipulate server-side URL requests
Security Misconfiguration	API8	Verbose error messages, default credentials

RESTaurant key endpoints

# Swagger UI
curl -sf "http://<PUBLIC_IP>/restaurant/docs" -o /dev/null -w "%{http_code}"

# OpenAPI spec
curl -s "http://<PUBLIC_IP>/restaurant/openapi.json" | jq .info

# BOLA -- access another user's order (after authentication)
curl -s "http://<PUBLIC_IP>/restaurant/orders/1" \
  -H "Authorization: Bearer <token>"

# BFLA -- attempt admin action as regular user
curl -s -X POST "http://<PUBLIC_IP>/restaurant/admin/users" \
  -H "Authorization: Bearer <user_token>" \
  -H "Content-Type: application/json"

crAPI (OWASP Completely Ridiculous API)


Port	`8888` (dedicated — not path-prefixed)
Images	`crapi/crapi-web`, `crapi/crapi-identity`, `crapi/crapi-community`, `crapi/crapi-workshop`, PostgreSQL, MongoDB, MailHog
Instances	7 microservices (single instance each)
Resources	~3.0 CPU / ~2.0 GiB RAM total
Framework	React SPA + Java/Go/Python microservices
Project	github.com/OWASP/crAPI

crAPI is the OWASP flagship project for API security testing. It runs as 7 microservices on a dedicated port (8888) because the React SPA hardcodes its API paths and cannot be served behind a path prefix. The NSG allows inbound traffic on port 8888.

MailHog captures all emails sent by crAPI (account verification, password reset). Access MailHog via SSH tunnel on port 18025.

Challenge Categories

Category	Vulnerabilities
BOLA (Broken Object Level Authorization)	Access other users’ vehicles, orders, and reports
BFLA (Broken Function Level Authorization)	Escalate to admin, access restricted endpoints
Mass Assignment	Modify protected fields (role, balance) via API
SSRF (Server Side Request Forgery)	Manipulate server-side URL fetching
JWT Manipulation	Forge or modify JWT tokens for privilege escalation
NoSQL Injection	Inject queries into MongoDB-backed endpoints
Excessive Data Exposure	API returns sensitive user data

Getting Started

# Verify crAPI is running
curl -sf "http://<PUBLIC_IP>:8888" -o /dev/null -w "%{http_code}"

# Sign up a new user
curl -s -X POST "http://<PUBLIC_IP>:8888/identity/api/auth/signup" \
  -H "Content-Type: application/json" \
  -d '{"name":"Test User","email":"test@example.com","number":"1234567890","password":"Test1234!"}'

# Log in
curl -s -X POST "http://<PUBLIC_IP>:8888/identity/api/auth/login" \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"Test1234!"}'

# Access MailHog (via SSH tunnel for email verification)
# ssh -L 18025:localhost:18025 azureuser@<PUBLIC_IP>
# Then open http://localhost:18025 in your browser

crAPI Architecture

Port 8888 -> crapi-web (React SPA + nginx)
             -> crapi-identity (Java, user auth, JWT)
             -> crapi-community (Go, forums, posts)
             -> crapi-workshop (Python, vehicle service)
             -> crapi-postgres (PostgreSQL)
             -> crapi-mongo (MongoDB)
             -> crapi-mailhog (email capture, port 18025)

Application Coverage Matrix

Demo Use Case	Primary App	Secondary App
WAF — SQL Injection	DVWA	Juice Shop
WAF — XSS	DVWA	Juice Shop
WAF — Command Injection	DVWA	—
API Security — BOLA	VAmPI	—
API Security — Auth bypass	VAmPI	Juice Shop
API Security — Data exposure	VAmPI	httpbin
Bot Defense — Brute force	DVWA	Juice Shop
Bot Defense — Scraping	Juice Shop	—
Client-Side Defense — DOM XSS	Juice Shop	—
Client-Side Defense — Stored XSS	DVWA	Juice Shop
Client-Side Defense — Card Skimmer	CSD Demo	—
Client-Side Defense — Formjacker	CSD Demo	—
Client-Side Defense — Keylogger	CSD Demo	—
Client-Side Defense — Cryptominer	CSD Demo	—
Client-Side Defense — DOM Hijack	CSD Demo	—
API Security — GraphQL injection	DVGA	—
API Security — GraphQL DoS	DVGA	—
API Security — OWASP API Top 10 2023	RESTaurant	crAPI
API Security — BFLA	RESTaurant	crAPI
API Security — Mass assignment	crAPI	RESTaurant
API Security — SSRF	crAPI	RESTaurant
API Security — JWT manipulation	crAPI	—
API Security — NoSQL injection	crAPI	—
Basic connectivity testing	httpbin	—
Request diagnostics	whoami	httpbin
Header injection verification	whoami	—