Damn Vulnerable RESTaurant: a FastAPI target that is broken on purpose

A restaurant where every dish is a vulnerability

Damn Vulnerable RESTaurant is an intentionally vulnerable API service built for learning and training, aimed at developers, ethical hackers and security engineers. The framing is a restaurant, and the framing is doing real work, because the project is explicitly designed to be extended with new vulnerable endpoints and new exploitation mechanisms over time, so it can be used in training that covers detecting and exploiting a class of bug rather than one fixed bug. The project describes itself as a training playground with three intended uses. Developers play a game in which they identify and fix vulnerabilities interactively. Ethical hackers treat it as a CTF challenge, starting from a low privileged API user and escalating to a root user along a single path, with API documentation provided to help. Security engineers point SAST, DAST and infrastructure as code tooling at it to test their detection mechanisms. There is a Hall of Fame file for participants who finish the challenge.

Two entry scripts decide whether you fix the code or break it

The design decision that makes this project usable in a classroom is that there are two launch paths, and the README gives you one for each audience. The developers path starts an interactive game in which the task is to find and fix the vulnerabilities in a FastAPI application. The ethical hackers path starts the same service as it is, so it can be attacked. The two are separate shell scripts in the repository root, start_game.sh and start_app.sh, and both need Docker and Docker Compose V2 installed. A third option is GitHub Codespaces, which the README recommends for people without a local environment, noting that Codespaces offers up to 60 hours a month for free, and the codespace runs the same start scripts once it exists. The README also warns that walkthroughs published before 14.11.2024 may refer to an older version of the code, which is a useful signal that the challenge set has changed under people who solved it earlier.

Starting the developers mode and fixing code without a restart

For the developers path, the whole setup is three commands:

git clone https://github.com/theowni/Damn-Vulnerable-RESTaurant-API-Game.git
cd Damn-Vulnerable-RESTaurant-API-Game
./start_game.sh

You should see the game entry screen once it starts. The useful detail for a workshop is what happens after that, because the README says you can implement fixes without restarting the Docker instance, since changes to the model layer are not required and therefore no migration restarts are needed. The compose file is what makes that work, since the application directory is mounted as a volume and uvicorn is started with the reload flag. The command the service runs is:

    command: bash -c "alembic upgrade head && uvicorn main:app --host 0.0.0.0 --port 8091 --workers 1 --reload"

So the schema is brought up to date by alembic on every start, the app is served with a single worker, and a change to a Python file is picked up without the container or the database being touched. That is what turns a vulnerable target into something a group can iterate on in a training session.

The plain API on port 8091, with Swagger and Redoc

The hackers path deploys the same service in its vulnerable state, and the setup is the same shape:

git clone https://github.com/theowni/Damn-Vulnerable-RESTaurant-API-Game.git
cd Damn-Vulnerable-RESTaurant-API-Game
./start_app.sh

The API service is exposed at http://localhost:8091 by default, and the documentation is served by the framework itself, with Swagger at http://localhost:8091/docs and Redoc at http://localhost:8091/redoc. Those two endpoints matter for the exercise, because a complete API reference is exactly what an attacker would look for, and the project intends you to have it. When the session ends, the restaurant is closed with:

./stop_app.sh

Data persists between stops and starts, so a database seeded in one session is still there in the next, which is convenient for a multi day exercise and a trap for a shared machine. The compose file is a two service setup, a web service and a db service, where the database is postgres:15.4-alpine with a health check that waits for it before the application starts.

A privileged container with a sudo rule for find, on purpose

The container configuration is where the project is most candid about itself, and reading it tells you what the challenge is really about. The web service runs privileged and adds the SYS_ADMIN capability:

    privileged: true
    cap_add:
      - SYS_ADMIN

The Dockerfile gives the app user passwordless sudo for one binary only:

RUN echo 'ALL ALL=(ALL) NOPASSWD: /usr/bin/find' | sudo tee /etc/sudoers.d/find_nopasswd > /dev/null

The comment in the file explains the reason in the project's own voice, that the Chef sometimes needs to find files on the filesystem, and the chef is able to search everywhere across the filesystem as a result. Elsewhere the same Dockerfile creates a dedicated non-root user named app and switches to it, so the default process is unprivileged even though the capability and the sudo rule are present for the challenge. The effect is that the escalation path from a low privileged API user to root is a designed one, and the container gives the attacker the surface to attempt it. That is also why the README's warning is emphatic about deploying locally with Docker and never uploading the project to a public html folder or an Internet facing server.

A FastAPI and PostgreSQL stack that is easy to extend

The application is built on Python FastAPI with a PostgreSQL database, containerised for local deployment, and the project argues that this combination is what makes the codebase easy to extend with new vulnerable features in a short amount of time. The dependency list in pyproject.toml shows the pieces a REST API with authentication needs:

[tool.poetry.dependencies]
python = "^3.10"
fastapi = "^0.103.0"
uvicorn = {extras = ["standard"], version = "^0.23.2"}
sqlalchemy = "^2.0.20"
psycopg2 = "^2.9.7"

Alongside those are python-jose and passlib with bcrypt for tokens and password hashing, alembic for schema migrations, slowapi for rate limiting, and a test stack of pytest, pytest-asyncio, pytest-mock and requests-mock, plus black, isort and pre-commit for formatting. The project also notes that the target is not restricted to REST, since endpoints may use GraphQL and other styles, with various dishes served over time. The roadmap shows the developer environment and per vulnerability learning resources as done, with more vulnerabilities and feedback driven ideas still open, and CONTRIBUTING.md is the entry point for extending the challenge set with new security issues.

When a synthetic target is the wrong answer

A training target has a clear use and a clear limit. For a workshop, a CTF style exercise or a validation of a detection pipeline, a deliberately broken application that everyone agrees is broken is a controlled environment, and that is the value here. But the same properties make it a poor substitute for real assessment work, because the vulnerabilities are the ones the author chose to build, the data is synthetic, and the escalation path is a single designed route rather than the messy sprawl of a real codebase. If your goal is to prove that your scanners find issues in your product, this project can only tell you that the scanners work on an application built to be found. There is also the operational risk that comes with it, since a privileged container with a sudo rule and a service that is meant to be exploited is a bad neighbour on a shared network, and the README is unambiguous that it will be compromised if exposed. The companion project referenced in the README, a Web API Security Champion series, covers the OWASP top 10 API security risks with exploitation steps and remedial actions, and is the more useful artefact if you need the theory rather than the target.

Editorial conclusion

Adopt Damn Vulnerable RESTaurant when you need a self contained target for a workshop, a CTF style exercise or a test of your own SAST and DAST tooling, and when everyone involved understands that the service is exploitable by design. Do not deploy it to a shared host, a demo box reachable from a network, or a cloud instance, because the project itself warns that such a deployment will be compromised, and the container runs privileged with SYS_ADMIN. Check first which mode you start, start_game.sh for fixing the code or start_app.sh for the plain API, and confirm the compose file binds only to your machine. The last push was on 2026-07-09, the repository publishes no releases, and the licence field on the repository says GPL-3.0 while pyproject.toml declares MIT, which is a discrepancy to settle before you redistribute anything.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. theowni/Damn-Vulnerable-RESTaurant-API-Game on GitHub