# JavaSecLab ships the vulnerable version next to the fixed one

> JavaSecLab is a Spring Boot application that reproduces the common Java web vulnerability classes, and the unusual part is that each scenario carries the fixed implementation, the audit oriented source and sink notes, and the remediation guidance alongside the exploit. It is Apache-2.0 licensed, it runs on JDK 8 with MySQL, and it comes with a Docker Compose stack, a public demo and a warning not to expose either to the internet.

**whgojp/JavaSecLab** — JavaSecLab is a comprehensive Java vulnerability platform｜​ JavaSecLab是一款综合型Java漏洞平台，提供相关漏洞缺陷代码、修复代码、漏洞场景、审计SINK点、安全编码规范，覆盖多种漏洞场景，友好用户交互UI……

- Repository: https://github.com/whgojp/JavaSecLab
- Website: http://whgojp.top
- Stars: 884 · Forks: 76
- Language: Java
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/whgojp-javaseclab

## The question the project exists to answer

JavaSecLab is a comprehensive Java vulnerability lab for application security learning, code audit practice, secure development training, and security tool evaluation. Built on Spring Boot, it provides vulnerable code, fixed implementations, realistic attack scenarios, audit oriented source and sink notes, remediation guidance, secure coding explanations, and traffic analysis examples.

The stated goal is practical: to help users understand not only how a vulnerability is exploited, but also why it exists in code and how it should be fixed.

The Why This Project Exists section explains where that goal comes from. The author has worked in enterprise security roles and experienced the full vulnerability lifecycle, and after penetration tests or security assessments, vulnerabilities are often assigned to development teams through systems such as TAPD or Jira. In practice, two questions come up repeatedly: why is this behavior a vulnerability, and how should this vulnerability be fixed?

So the project is not a collection of proofs of concept. It is an attempt to connect vulnerability behaviour, vulnerable code, remediation approaches and audit thinking in one place, and the README compares that to a text only report or a proof of concept, saying the project emphasises understanding vulnerabilities from the code perspective.

That is a real difference in kind. A proof of concept shows that something breaks. A lab that ships the fixed version next to the broken one shows what the fix looks like, and the scenario is built on the same code path so the difference is legible.

The audience is four groups, listed in the README. Security service teams use it to explain vulnerability causes, exploitation paths, fixes, audit flows and traffic patterns. Enterprise security teams use it for SDL, DevSecOps, secure development training and security awareness programmes. Security researchers use it to test SAST, DAST, IAST, RASP, SCA, xAST, reachability analysis and other tools. And Java developers learn common application security issues from real code instead of abstract checklists.

## The catalogue covers the usual list, and then the ecosystem

The vulnerability modules section is a long list, and it is worth reading in two parts, because the second part is what makes this more than a web application security checklist.

The first part is the standard web surface. XSS, CSRF, CORS, JSONP, URL redirection, XFF spoofing, denial of service and XPath injection. Then SQL injection, arbitrary file read, upload, download and delete, SSRF, XXE and RCE. Then business logic flaws, namely IDOR, captcha security, payment security and concurrency security. Then sensitive information disclosure, login confrontation, request signing and JWT credential security. And then SpEL injection, SSTI and Java deserialization.

The second part is the Java ecosystem specifically. Fastjson, Jackson, XStream, Log4j2, Shiro, SnakeYAML and XMLDecoder, and then Spring Boot ecosystem exposure, naming Swagger, Actuator, Druid and MySQL JDBC deserialization.

That second group is the one that distinguishes this lab from a generic vulnerable application, because those are the cases where the framework or the library, not the developer, is the reason the application is vulnerable. A class of developer can write a secure application and still ship a Log4j2 or a Fastjson problem.

One design decision is worth calling out because it affects how you use the lab. The same vulnerability type often appears through multiple trigger paths in real systems, so the project provides multiple scenarios for the core vulnerability classes where possible, so users can compare how different coding patterns, framework features and business flows affect risk.

That comparison is the interesting part for an auditor, because the trigger path is usually where the vulnerability is or is not reachable in a given codebase.

## The scenarios are built around the source to sink path

The design principle behind the scenarios is stated plainly, and it is the part of the project an experienced auditor will recognise as the right shape.

In code auditing, a common workflow is to locate a sink first, such as command execution, SQL execution, file access, template rendering, deserialization or response output. The auditor then traces backward to identify the corresponding source, such as request parameters, headers, cookies, uploaded files, serialized data, or database content.

Many JavaSecLab scenarios are designed around this source to sink path, which the README says makes them useful both for learning and for tool verification. A tool that claims to find SQL injection should find it in the scenarios, and a tool that claims to trace taint should trace it, and the lab is arranged so that the answer is known.

The traffic analysis section extends the same idea into the network. The project includes vulnerability traffic analysis examples to help learners connect request and response behaviour with code execution, and the README invites contributions with clearer packets, better reproduction notes or additional analysis examples.

The example given is a time-based SQL injection, where the traffic pattern is observed through response latency, with the server responding after roughly five seconds. That is a good teaching example, because the timing difference is visible in a capture without any special tooling, and it maps directly onto a delay the code introduces.

Together the source to sink scenarios and the traffic examples give you two views of the same case, one in the code and one on the wire, and that pairing is what a security curriculum usually struggles to provide.

## Local deployment: JDK 8, MySQL 8 and a profile switch

The deployment section starts with the clone:

```shell
git clone https://github.com/whgojp/JavaSecLab.git
cd JavaSecLab
```

The local route lists three requirements: JDK 8, MySQL 8.0 or newer, and Maven. The steps that follow are short. You create the database and import the schema from sql/JavaSecLab.sql. You set the active profile to dev in the application configuration file, src/main/resources/application.yml:

```yaml
   spring:
     profiles:
       active: dev
```

And then you point the application at your database in src/main/resources/application-dev.yml:

```yaml
   username: root
   password: QWE123qwe
   url: jdbc:mysql://localhost:13306/JavaSecLab?characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=false&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=GMT%2B8&nullCatalogMeansCurrent=true&allowPublicKeyRetrieval=true&allowMultiQueries=true
```

Note the port in that URL, 13306 rather than the default 3306, and the long parameter list, which is the usual incantation for a MySQL connector that has to be told not to verify the server certificate and to treat timestamps the way the application expects.

The last step is to start the application from the IDE or with Maven, and the default account is admin with the password admin.

The stack behind it is conventional and listed in the README: Spring Boot, Spring Security, MyBatis and MyBatis-Plus, JPA with Hibernate, Thymeleaf for the views, Layui for the interface, and MySQL.

## Docker deployment brings its own MySQL, the app and Portainer

The Docker route has two documented options, and the difference is whether you pull a published image or build your own.

Option one uses the published image and the compose file that goes with it:

```shell
docker compose -f docker-compose.image.yml up -d
```

Option two builds the image locally from the repository and starts the lab:

```shell
mvn clean package -DskipTests
docker compose -p javaseclab up -d
```

The default compose file in the repository shows what the stack contains. There is a MySQL service on the 8.0.33 image, with the schema file mounted into the container's init directory so the database is populated on first start. There is the JavaSecLab service itself, built from the local directory, published on port 80, with the logs directory mounted. And there is a Portainer service, the container management interface, published on 9000 and 18001, with the Docker socket mounted into it.

The three services share a bridge network called JavaSecLabNet, which is given an explicit subnet in the 192.168.1.0 range.

The Dockerfile is a thin wrapper, which is appropriate since the interesting configuration is in the application. It is based on the openjdk 8 image, it copies the packaged jar into the work directory, and then it does something worth pointing out: it creates a set of directories under /tmp for uploads and static content, makes them world writable, and pre-populates them with test files including a JSP and a text file in the upload directory. Those files are there so that the file read, upload and download scenarios have something to work with, and they are part of what makes the lab work out of the box.

The entrypoint is the jar itself, and the container exposes port 80.

## The security notice is the first thing to read

The README is unusually direct about the risk, and that honesty is part of why the project is worth using.

There is an online demo at whgojp.top with the default account admin and admin, and immediately after it a warning: JavaSecLab is intentionally vulnerable and contains dangerous endpoints, vulnerable dependencies and insecure configurations. Run your own deployment only in an isolated environment, and do not expose it directly to the public internet.

The security notice section at the end of the README repeats the point, saying the project is a vulnerable lab project that intentionally keeps dangerous endpoints, and the Dockerfile adds its own small joke in a label, I think therefore I am.

For a security professional this is not a warning so much as a description of the product. A lab with dangerous endpoints and vulnerable dependencies is the point, because the alternative is a class that has to imagine the vulnerable dependency cases, and imagining them is how they end up in production. What the project is asking is that you run it where it cannot hurt, and it says so before it tells you anything else.

The deployment guidance follows the same logic. The demo is there to look at, and your own deployment is for practice, on an isolated segment, with the database credentials in the compose file being the throwaway ones that the local setup also uses.

The licence is Apache-2.0, the default branch is i18n-bilingual, the recent releases are V1.5 on 2026-05-27, V1.4 on 2025-03-21 and V1.3 on 2024-11-24, and the last push was on 2026-06-09.

## Conclusion

Adopt JavaSecLab if you teach application security to Java developers, onboard security engineers who need to practise source to sink tracing on real code, or evaluate a security tool such as a SAST or IAST product against known cases. Do not deploy the public demo instance for anything sensitive, and do not expose a self hosted instance to the internet, because the README states plainly that the application is intentionally vulnerable and contains dangerous endpoints. Before you run it, read the security notice, put the deployment on a segment you control, and check that the JDK and MySQL versions in the compose file match what you have, since the project targets JDK 8 and MySQL 8.0.

## FAQ

### What does JavaSecLab provide for learning Java web vulnerabilities?

It provides vulnerable code, fixed implementations, realistic attack scenarios, audit oriented source and sink notes, remediation guidance, secure coding explanations and traffic analysis examples, built on Spring Boot. The goal is to show why a vulnerability exists in the code and how it should be fixed, not just that it can be exploited.

### Who is JavaSecLab intended for?

The README lists security service teams, enterprise security teams working on SDL, DevSecOps and secure development training, security researchers who want to test SAST, DAST, IAST, RASP, SCA and related tools, and Java developers who want to learn from real code rather than checklists.

### How do I run JavaSecLab locally?

Clone the repository, create the database and import sql/JavaSecLab.sql, set the active profile to dev in src/main/resources/application.yml, put your database connection in src/main/resources/application-dev.yml, and start the application from the IDE or with Maven. You need JDK 8, MySQL 8.0 or newer and Maven, and the default account is admin with the password admin.

### Can I run JavaSecLab with Docker?

Yes. You can start the published image with docker compose -f docker-compose.image.yml up -d, or build locally with mvn clean package -DskipTests followed by docker compose -p javaseclab up -d. The stack includes MySQL, the application and Portainer on a shared bridge network.

### Is it safe to expose a JavaSecLab deployment?

No. The README states that JavaSecLab is intentionally vulnerable, contains dangerous endpoints, vulnerable dependencies and insecure configurations, and that you should run your own deployment only in an isolated environment and never expose it directly to the public internet.

## Sources

- [License: Apache-2.0](https://github.com/whgojp/JavaSecLab/blob/i18n-bilingual/LICENSE)
- [Project website](http://whgojp.top)
- [README](https://github.com/whgojp/JavaSecLab/blob/i18n-bilingual/README.md)
- [Releases](https://github.com/whgojp/JavaSecLab/releases)
- [whgojp/JavaSecLab on GitHub](https://github.com/whgojp/JavaSecLab)

---

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