# OWASP WrongSecrets: Hands-On Secrets Management Training

> OWASP WrongSecrets is a deliberately vulnerable training application that turns common secrets handling failures into guided challenges. It suits security education and hands-on workshops, but it is not a production application or a substitute for a secrets manager.

**OWASP/wrongsecrets** — Vulnerable app with examples showing how to not use secrets

- Repository: https://github.com/OWASP/wrongsecrets
- Website: https://owasp.org/www-project-wrongsecrets/
- Stars: 1,473 · Forks: 649
- Language: HTML
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/owasp-wrongsecrets

## WrongSecrets Turns Secret Failures into Browser-Based Challenges

WrongSecrets addresses a specific training problem: many secret management policies describe what not to do, but developers learn more effectively when they can locate an exposed credential in a running system. The project packages common mistakes into challenges that participants solve with tools and techniques associated with secrets hunting. Its intended users are application security teams, security trainers, developers and participants who want to examine their own secrets management practices.

This is an intentionally vulnerable web application. Its purpose depends on the application being wrong in specific, teachable ways. A deployment containing real secrets would therefore create the risk the project is designed to illustrate. The safest use is an isolated training environment with fictional or tightly controlled credentials.

The repository also places substantial emphasis on deployment surfaces. Its entries include Dockerfiles, Kubernetes manifests, Terraform-related directories, cloud provider examples and scripts for minikube and Vault. This gives trainers several contexts in which to discuss secrets, but it also makes configuration knowledge part of the learning objective. A participant who only opens the browser may understand one class of exposure without seeing the infrastructure boundary represented by environment variables, mounted files, cloud configuration and orchestration manifests.

## Container Build Exposes the Secrets Being Taught

The repository layout shows a Java application packaged as a JAR and delivered through container definitions. The main Dockerfile builds `target/wrongsecrets-${argBasedVersion}-SNAPSHOT.jar`, extracts it, and places the application into an `eclipse-temurin:26-jre-alpine` runtime image. Other entries, including `Dockerfile.web`, desktop-oriented Dockerfiles and a llama-server Dockerfile, indicate that the project is not limited to a single packaging mode.

The build file itself functions as teaching material. It defines values such as `DOCKER_ENV_PASSWORD`, `WRONGSECRETS_MCP_SECRET`, `GOOGLE_SERVICE_ACCOUNT_KEY` and `CHALLENGE59_SLACK_WEBHOOK_URL`. It also writes values during image construction and creates `/var/run/secrets2`. A separate build step uses a secret mount identified by `id=mysecret`. These details expose several mechanisms that trainees must distinguish: image build-time values, runtime environment variables, filesystem paths and build secrets.

That distinction matters. A variable printed during `docker build` can survive in image history or metadata even if it is absent from the final process environment. A runtime environment variable can be inspected by anyone who can describe the container. A file mounted under `/run/secrets` follows a different lifecycle. WrongSecrets lets an instructor discuss those differences without requiring every learner to reproduce the same deployment mistake in a separate application.

The presence of JavaScript configuration, `src/`, `js/`, static assets and generated documentation indicates a larger web application rather than a single static secret-scanning exercise. However, the README does not specify the exact endpoint sequence or internal class responsible for each challenge. Learners should not assume that every challenge follows the same request pattern.

## Running the Stable Docker Image for a First Challenge

The quickest first use is the online demo, which requires no local setup. For a local full experience, the README directs new users to run the published Docker image and then visit the application through `localhost:8080`. Port `8090` is also mapped, although the README does not explain the purpose of that second port.

Run the documented local container command:

```bash
docker run -p 8080:8080 -p 8090:8090 jeroenwillemsen/wrongsecrets:latest-no-vault
```

Docker should print its normal startup output. Once the application is ready, open the following address in a browser:

```text
http://localhost:8080
```

The interface is described as a game with multiple challenges. Start with a challenge that uses only the local application, then inspect the running container as part of the exercise. Avoid moving directly to cloud challenges unless the lesson is specifically about those providers and the required sample credentials are already understood.

The README also offers a development image from GitHub Container Registry:

```bash
docker run -p 8080:8080 -p 8090:8090 ghcr.io/owasp/wrongsecrets/wrongsecrets-master:latest-master
```

The documentation labels this image as a development version that may be unstable. It is unsuitable when repeatable exercises matter more than access to unreleased challenges. A training group should select and record one image version before a workshop so that challenge instructions and behavior remain consistent.

## AI and Cloud Lessons Expand Beyond Container Inspection

Recent release notes show a deliberate expansion toward AI-related challenges. `v1.14.0` is described as a major AI upgrade, and `v1.14.1` introduces new AI challenges. Repository entries such as `cursor/`, `chatgpt_dump.html`, `wrongsecret-lama-resources/` and `Dockerfile_llamaserver1` support that direction. The README does not document the exact solution steps, required model services or expected outputs, so those details cannot be treated as a guaranteed first exercise.

The wider repository contains `aws/`, `azure/`, `gcp/`, `k8s/` and HashiCorp Vault-related setup. The advanced setup is therefore more than an optional production deployment guide. It represents separate instructional environments with different trust boundaries. A cloud exercise may teach how a workload receives configuration, while a Kubernetes exercise may focus on manifests or mounted secrets. Vault exercises follow another model because the application must integrate with an external secrets system rather than merely locating a literal credential.

This breadth is useful for a course that needs to connect application flaws with deployment flaws. It also increases preparation work. The README refers readers to detailed instructions below, but those instructions are not included in the repository README excerpt. Before presenting an advanced challenge, an instructor should consult the repository's relevant provider directory and confirm which credentials, services, ports and cleanup actions it requires.

## Training Value Comes with Isolation and Scope Limits

The main limitation is inherent to the design: WrongSecrets is meant to expose secrets, so it is the wrong tool for a production deployment, shared demonstration host or network with sensitive assets. Exposing the application beyond the intended training boundary may expose embedded credentials, invite scanning or create opportunities for participants to interact with infrastructure they do not understand.

It is also not a complete secrets management platform. A manager such as HashiCorp Vault is designed to store and control access to secrets. WrongSecrets instead contains insecure examples for teaching discovery and remediation. Solving challenges may help a team discuss rotation, access policy and deployment hygiene, but it does not grant those controls to an application.

Scanning tools provide another useful comparison. A secret scanner searches files, repositories or other supplied targets for patterns and known credential formats. WrongSecrets asks learners to work through a live application and reason about where secrets travel. The former fits code review and repository automation; the latter fits instructor-led practice across application and deployment layers. They are complementary rather than interchangeable.

The documentation does not claim that every challenge can be solved by one scanner. In fact, the range of Docker variables, mounted files, cloud directories and AI resources suggests that file-pattern matching alone will miss at least some intended lessons. It also does not document a formal scoring system beyond challenge completion, so facilitators should not promise a particular curriculum duration without defining their own sequence.

## Release Activity and AGPL-3.0 Usage Boundaries

The repository is not archived, and the last push was on 2026-10-16. Recent releases include `v1.14.1` on 2026-10-02, `v1.14.0` on 2026-09-22 and `1.13.5` on 2026-05-19. This indicates ongoing repository activity, but it does not remove the need to pin versions for training. The distinction between the stable Docker tag, the development tag and individual releases should be made explicit in workshop instructions.

The project uses the `AGPL-3.0` license. That matters if an organization modifies the application, combines it into a larger service or distributes a modified version. The repository also includes `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `SECURITY.md` and workflow definitions for Java checks, Terraform formatting, CodeQL, containers, Kubernetes, ZAP and documentation. Those files indicate project-specific contribution and security processes, although the README does not define an upgrade policy or compatibility promise.

The `package.json` file specifies Node.js `>=26.0.0` for JavaScript development tooling. This requirement should not be confused with the runtime requirement for the prebuilt Docker image, which already contains a Java runtime. Contributors editing the frontend or running JavaScript checks need the matching Node.js environment; participants using Docker may not need local Node.js at all.

## Preparing a Controlled WrongSecrets Workshop

A workshop should separate discovery exercises from remediation exercises. The application intentionally contains unsafe examples, so the first phase can ask participants to locate secrets using browser behavior, container inspection and repository review. The second phase can move those findings into a discussion about secret injection, build isolation, access control and rotation without changing the challenge before its solution has been taught.

The published repository includes a `compose.yaml` file, but the README excerpt does not provide a verified Compose command. For that reason, the Docker command above is the defensible starting point. Do not invent service names or environment variables for a Compose deployment. Read the current repository file before adding it to an exercise.

The online demo is convenient for orientation, but local Docker execution gives participants a container they can inspect as part of the lesson. The `latest-no-vault` image name also communicates a scope boundary: it is the documented option for the standard local experience, not a complete Vault lab. Advanced cloud and Kubernetes groups need separate preparation based on the relevant files under `aws/`, `azure/`, `gcp/` and `k8s/`.

After selecting a release, record the image reference, restrict network access, use fictional credentials and define cleanup steps for containers, cloud resources and local files. The central lesson should remain visible: finding a secret is only one part of the exercise, while controlling where it exists and who can retrieve it determines whether the application design is safe.

## Conclusion

Security trainers and engineering teams should adopt WrongSecrets for controlled training when learners need concrete examples of exposed credentials. They should not deploy it as an internal service or use it as proof that one scanner covers every secret failure. Before adoption, verify the selected release, Docker image, challenge scope, network exposure and handling of any real credentials needed for cloud exercises.

## FAQ

### How do I run OWASP WrongSecrets locally?

Run the documented `jeroenwillemsen/wrongsecrets:latest-no-vault` Docker image with ports `8080` and `8090` mapped, then open `http://localhost:8080`.

### Is OWASP WrongSecrets safe to deploy in production?

No. It is an intentionally vulnerable training application containing examples of unsafe secret handling, so the documentation presents it as a game and learning environment rather than a production service.

### What is the difference between the stable and master WrongSecrets images?

The README presents `latest-no-vault` as the full local experience and the `latest-master` image as a development version with the latest features that may be unstable.

## Sources

- [License: AGPL-3.0](https://github.com/OWASP/wrongsecrets/blob/master/LICENSE)
- [OWASP/wrongsecrets on GitHub](https://github.com/OWASP/wrongsecrets)
- [Project website](https://owasp.org/www-project-wrongsecrets/)
- [README](https://github.com/OWASP/wrongsecrets/blob/master/README.md)
- [Releases](https://github.com/OWASP/wrongsecrets/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/owasp-wrongsecrets