Beyond Juice Shop: Broken Crystals and the "Diamond Labs" I've Been Collecting
A while back I wanted to take stock of the security lab machines that have come out in recent years. I figured I'd dig up plenty of new stuff I'd never seen before, but the usual recommendations just kept circling back to the same names:
- OWASP Juice Shop
- PortSwigger Web Security Academy
- crAPI
- CloudGoat
- GOAD
- pwn.college
These are all great, of course, but something always felt missing. It wasn't until I brought up Broken Crystals that I realised what the problem was:
Most recommendation lists are very good at rattling off the "big projects," but they tend to overlook the high-quality little labs made by individuals or small teams.
Some of these labs don't carry an OWASP logo, and their GitHub star counts aren't jaw-dropping, yet they're just as valuable to learn from and, most importantly, fun!
I've started calling these:
Diamond Labs
They aren't necessarily big, but the vulnerabilities are elegantly designed, the tech stack is modern, and once you're done they actually leave something behind.
Broken Crystals: My Personal Answer
Project:
NeuraLegion/brokencrystals
I've recently written a string of hands-on Broken Crystals notes, including:
- Going from a single query parameter all the way to a root reverse shell
- Getting RCE via
eval-style SSJI - XXE that can read files, but doesn't necessarily give you a clean SSRF
- Escalating from an unauthenticated MCP guest session all the way to admin RCE
The more I played with it, the more certain I became that this was exactly the kind of lab I'd been looking for.
Broken Crystals doesn't just lay out vulnerabilities one page at a time; it actually builds a full product:
- React frontend
- Node.js backend
- PostgreSQL
- REST API
- OpenAPI/Swagger
- GraphQL
- JWT
- Email functionality
- MCP JSON-RPC endpoint
And the vulnerabilities inside aren't just SQLi and XSS:
- JWT validation issues
- SQL Injection
- IDOR/broken authorization
- XPath Injection
- XXE
- SSRF
- LFI
- Prototype Pollution
- Server-side JavaScript Injection
- GraphQL attack surface
- MCP sessions and role privileges
- SSTI/RCE
- Sensitive configuration disclosure
Since MCP was added recently in particular, the guest session, a regular user, admin tools, and the render feature can be chained into a really complete attack chain.
It feels a lot like this:
The author didn't just build a bunch of vulnerability challenges; they built a real product where every layer of trust boundary is broken.
The one thing to watch out for is that the README is written in too much detail. On your first playthrough it's best not to scroll too far down, or the vulnerability names, endpoints, and even some of the payloads will get spoiled.
Damn Vulnerable RESTaurant: A Small API Attack Chain
Project:
theowni/Damn-Vulnerable-RESTaurant-API-Game
RESTaurant is a vulnerable API built with FastAPI and PostgreSQL.
It can be used in three ways:
- Developers find and patch the vulnerabilities
- Ethical hackers exploit them manually
- Security engineers test with SAST, DAST, and other tools
What I like about it is that the author didn't split every vulnerability into unrelated endpoints. The attacker starts as a low-privilege API user and gradually escalates to root along a deliberately designed path.
The environment also includes:
- Swagger
- Redoc
- Docker
- FastAPI
- PostgreSQL
- Developer Fix Mode
The overall scale isn't large, but the theme is focused.
It's a great fit for running a full black-box pass after you've played crAPI, or the other way around—reading the FastAPI source directly for a white-box audit.
OAuth Labs: It's Not Just redirect_uri
Project:
cyllective/oauth-labs
I've recently started writing a hands-on OAuth Labs series too.
This lab really lives up to the "small but refined" standard, because instead of just cramming a "Login with OAuth" button into some ordinary website, it actually builds out the entire OAuth flow:
- Authorization Server
- Client Application
- Victim Simulator
- Tokens and Claims
- Admin Resource
- Black-box Mode
- White-box Mode
As a rule, each level has just one intended vulnerability, and the goal is always to find a way to obtain the admin user's resources.
The scenarios you'll currently run into include:
- Unstable or attacker-controllable identity claims
redirect_urivalidation issues- JWT signature validation errors
- Insecure JKU handling
The truly tricky thing about OAuth vulnerabilities isn't any single payload, but the fact that the flow has so many roles:
Resource Owner
Authorization Server
Client
Redirect URI
Access Token
ID Token
Resource Server
As soon as one side trusts another just a little too much, things can go wrong.
This lab is perfect for actually walking through those OAuth attacks that you "sort of understood" after reading an article.
AspGoat: Finally a Reasonably Modern .NET Lab
Project:
Soham7-dev/AspGoat
It's not that vulnerable ASP.NET applications don't exist, but a lot of them are stuck on older frameworks and coding styles.
AspGoat uses the more modern ASP.NET Core MVC and includes:
- SQL Injection
- XSS
- CSRF
- IDOR
- XXE
- SSRF
- Insecure Deserialization
- Cache Poisoning
- SSTI
- Prototype Pollution
It also contrasts secure and insecure coding patterns, making it a good way to fill in .NET white-box auditing skills.
Recent versions have also added some AI/LLM-flavoured scenarios, such as Prompt Injection, Excessive Agency, and Insecure Output Handling.
If what you usually see most is PHP, Node.js, and Python, this box makes for a nice change of pace.
DVGA: Purpose-Built for Practising GraphQL
Project:
dolevf/Damn-Vulnerable-GraphQL-Application
DVGA's theme is very singular: GraphQL Security.
The environment covers:
- Query
- Mutation
- Subscription
- Introspection
- Resolver
- Authorization
- Injection
- Resource Exhaustion
- Information Disclosure
It also has a Beginner and an Expert Mode.
GraphQL problems often aren't in GraphQL itself, but in developers thinking:
The frontend would never send a query like this, so the backend doesn't need to block it.
Or they only check permissions at the outermost layer, and once the resolver goes deeper it all goes off the rails.
If you only ever play with regular REST APIs, it's easy to miss the way of thinking around GraphQL's nested objects, resolvers, and field-level authorization.
VAmPI: Small, Clean, and Great for Testing Tools
Project:
erev0s/VAmPI
VAmPI is a vulnerable REST API built with Flask, much smaller in scale than crAPI.
It supports:
- OpenAPI
- Swagger
- Postman Collection
- Token Authentication
- Vulnerable/Secure Mode
This box isn't necessarily the most story-driven lab, but it's ideal for:
- Testing API scanners
- Running fuzzers
- Doing OpenAPI automation
- Validating BOLA/IDOR testing workflows
- Comparing before-and-after patching differences
If you want to write your own API security tool but don't want to spin up a whole microservice stack every time, you can cut your teeth on this one first.
Otto Support: A Very Satisfying MCP Lab Right Now
Project:
BishopFox/otto-support
Otto Support is a vulnerable MCP customer support server made by Bishop Fox.
It's not ten unrelated little prompt-injection challenges, but a complete customer support system:
- A single Go binary
- 19 MCP tools
- 4 role tiers
- Payment Gateway
- Customer API
- Metadata Service
- Session Signer
- SQLite
You start out unauthenticated, then have to hunt for credentials in the tools and returned data, escalating all the way up:
Unauthenticated
→ User
→ Support
→ Admin
And it works directly with:
- Claude Code
- Codex CLI
- Cursor
This design is far more interesting than "figuring out how to trick a chatbot into revealing its system prompt."
What it really tests is:
- Whether tool permissions are too broad
- Whether different roles can reach tools they shouldn't
- Whether credentials leak through tool output
- Whether the agent carries low-trust data into high-privilege actions
- Whether several low-risk features can be chained into a full privilege-escalation chain
If you've been wanting to study MCP lately, I'd put Otto Support very near the top of the list.
Vulnerable MCP Servers Lab: Great for White-Box Auditing
Project:
appsecco/vulnerable-mcp-servers-lab
Appsecco's set is more like an MCP vulnerability collection.
Each scenario is a relatively standalone MCP server, covering:
- Indirect Prompt Injection
- Insecure
eval - Tool Poisoning
- Malicious Tool Description
- Path Traversal
- Code Execution
- Secrets/PII leakage
- Outdated packages and supply-chain issues
It's not as productised as Otto Support, but it's perfect for opening up the source one by one and directly tracing:
Tool Definition
→ Input
→ Handler
→ Sink
→ Agent behaviour
For anyone looking to move from traditional web code auditing into AI red teaming, this set makes it easier to build up the basic instincts.
DVMCP: A Ten-Level MCP Course
Project:
harishsg993010/damn-vulnerable-MCP-server
The Damn Vulnerable MCP Server, or DVMCP for short, has ten progressive challenges:
- Prompt Injection
- Tool Poisoning
- Excessive Permissions
- Rug Pull
- Tool Shadowing
- Indirect Prompt Injection
- Token Theft
- Malicious Code Execution
- Remote Access
- Multi-vector Attack
It's less like a real product and more like a clearly categorised course.
So here's how I'd divide them up:
Want to first understand the categories of MCP attacks: DVMCP
Want single-vulnerability white-box work: Vulnerable MCP Servers Lab
Want to run a complete product attack chain: Otto Support
AIGoat and LLMGoat
These two have very similar names, but their focus isn't quite the same.
AIGoat
Project:
AISecurityConsortium/AIGoat
AIGoat is a locally run AI e-commerce lab that runs its models through Ollama by default.
It currently offers:
- 17 Attack Labs
- 9 CTF Challenges
- 3 layers of Progressive Defense
- Prompt Injection
- System Prompt Leakage
- RAG Poisoning
- Supply Chain Backdoor
- Excessive Agency
- Resource Abuse
Where I think it's valuable is that you can switch between different defense levels.
Instead of just telling you "prompt injection works here," it lets you see:
No defenses at all
→ Add input validation
→ Add intent classification
→ Add output filtering
→ Add guardrails
and then test whether the original attack still works.
LLMGoat
Project:
SECFORCE/LLMGoat
LLMGoat has ten challenges, each mapping to the OWASP LLM Top 10.
It uses a local Gemma 2 model by default. Some challenges require traditional security knowledge, while others only need natural-language manipulation.
By comparison:
LLMGoat: more like a sequential course
AIGoat: more like a complete AI security playground
Both can run locally, but the models themselves eat RAM and CPU, so they're not as lightweight as your typical Flask lab.
OWASP FinBot CTF: An Agentic AI Juice Shop
Project:
OWASP FinBot CTF
FinBot CTF positions itself as:
Juice Shop for Agentic AI
It simulates a finance and vendor management platform, where the agent can genuinely use tools and MCP rather than just chat.
The attack surface includes:
- Goal Manipulation
- Memory Poisoning
- Policy Bypass
- Tool Poisoning
- Data Exfiltration
- Agent Misbehavior
- RCE
It also has a public live system, so if you want to try it you don't necessarily have to stand up a local environment first.
FinBot is larger in scale than the small labs earlier in this post, but it does represent another recent direction for labs:
No longer just testing whether the model will say the wrong thing, but testing whether the model will do the wrong thing once it holds real tool permissions.
The Big Classics Are Still Worth Playing
Emphasising small boutique labs doesn't mean the big ones are obsolete.
Juice Shop v20
Juice Shop reached v20 in 2026, with major overhauls to the shop and the coding challenge UI, along with additions like:
- Chatbot Prompt Injection
- Greedy Chatbot Manipulation
- AI Debugging
- System Prompt-related scenarios
Having played it before doesn't mean you don't need to play it again now.
PortSwigger Web Security Academy
For web bug bounty, PortSwigger is still the most reliable main line.
In recent years its content has extended to:
- API Testing
- Web Cache Deception
- NoSQL Injection
- OAuth
- JWT
- Prototype Pollution
- Web LLM Attacks
- LLM Excessive Agency
And the quality of the challenges and their explanations is usually rock-solid.
crAPI
For practising modern APIs, microservices, and business logic, crAPI is still very representative.
GOAD
For getting into enterprise internal networks, Kerberos, ADCS, delegation, and SCCM, GOAD is still a must-play at the heavy-engineering scale.
The downside is that it's heavy.
Not the kind of heavy that's over after running a single Docker command.
pwn.college
If you want to cross from web into binary exploitation, going to pwn.college first usually makes more sense than jumping straight into ExploitGym.
VulnerableApp
Good for testing SAST, DAST, scanners, and post-patch regression. It's not necessarily the most story-driven CTF, but as a tool-testing environment it's very complete.
Final Thoughts
The big platforms are easy to find and usually come with fairly complete learning materials and communities.
But these days I also love labs that are:
- Made by one person or a small team
- Playable the moment Docker comes up
- Built on a sufficiently modern tech stack
- Where the vulnerabilities aren't just crammed in
- Where you can go black-box first, then white-box
- Where a few problems chain into a complete kill chain
Broken Crystals, OAuth Labs, RESTaurant, and Otto Support are exactly this kind.
They may not have hundreds of challenges, but once you're done they leave you remembering not just a single payload, but a genuine understanding of:
- What the system wrongly trusted
- Where the permission boundary broke
- How data crosses between different components
- How a few low-risk problems chain into a high-risk outcome
- Which layer the fix actually belongs in
These labs that "look like a product, just deliberately made broken" are the diamond labs I want to collect too.
Member discussion