TL;DR

OWASP WebGoat is a deliberately insecure web application maintained by OWASP for learning web application security. It demonstrates common server-side application flaws and is intended for people learning application security and penetration-testing techniques in a safe, legal lab environment. (GitHub)

The best way to use WebGoat is not to memorize payloads. The goal is to understand the security invariant that was broken:

\[\text{secure behavior} = \text{untrusted input is validated, authorized, encoded, and safely processed}\]

A practical learning path is:

  1. Run WebGoat locally with Docker.
  2. Use a browser plus Burp Suite Community or OWASP ZAP.
  3. Use WebWolf for attacker-server scenarios such as password reset, CSRF, XXE, JWT tooling, and request capture.
  4. Finish WebGoat’s guided lessons.
  5. Reinforce the same ideas with OWASP Juice Shop and PortSwigger Web Security Academy.

WebGoat is especially strong for Java/Spring-style enterprise security concepts. Juice Shop is better for CTF-style modern JavaScript practice. PortSwigger Web Security Academy is the best structured web-security curriculum to pair with both. (OWASP Foundation)

What WebGoat Is

WebGoat is intentionally vulnerable. That is the point. The application gives learners a legal target where they can test SQL injection, XSS, access-control flaws, JWT weaknesses, insecure deserialization, path traversal, SSRF, XXE, CSRF, vulnerable components, and other common web vulnerabilities.

OWASP’s own README is explicit: WebGoat is a deliberately insecure application, and its default configuration binds to localhost to reduce exposure. The project warns that running it can make the machine vulnerable and that the techniques should only be used with authorization. (GitHub)

The conceptual model is simple:

\[\text{attack surface} = {\text{inputs}} \times {\text{trust boundaries}} \times {\text{server-side effects}}\]

A WebGoat lesson usually asks you to find the place where the application incorrectly trusts something: a request parameter, cookie, JWT claim, URL, XML body, serialized object, hidden field, or client-side control.

Current Status in 2026

As of the current public GitHub release list, WebGoat’s latest release stream is v2025.x, with v2025.3 marked as the latest release on GitHub. The release notes for v2025.1 mention refactoring, assignment progress, JWT kid/jku lessons, password-reset fixes, CSRF fixes, and dependency updates; v2025.3 mainly includes bug fixes and technical tasks. (GitHub)

The README also shows that running from source now lists Java 25 as a prerequisite, while older standalone examples in the same README still show webgoat-2023.8.jar. For a real install, check the exact release asset you downloaded rather than assuming an old filename. (GitHub)

OWASP has also published the OWASP Top 10:2025. The 2025 list is not identical to the 2021 list: for example, A03 is now Software Supply Chain Failures, A05 is Injection, and A10 is Mishandling of Exceptional Conditions. (OWASP Foundation)

This matters because WebGoat lessons, older writeups, and many tutorials may still use OWASP Top 10:2017 or 2021 naming. When studying WebGoat, focus on the vulnerability concept, not only the category label.

Safe Installation

The easiest local setup is Docker:

docker run -it \
  -p 127.0.0.1:8080:8080 \
  -p 127.0.0.1:9090:9090 \
  webgoat/webgoat

Then open:

http://127.0.0.1:8080/WebGoat
http://127.0.0.1:9090/WebWolf

The official OWASP WebGoat page shows the same local port mapping: WebGoat on 8080 and WebWolf on 9090. (OWASP Foundation)

The OWASP Developer Guide also notes that WebGoat is available at localhost:8080/WebGoat, that there is no page at plain localhost:8080/, and that accounts persist while the Docker container is stopped but are removed if the container is deleted. (devguide.owasp.org)

For lessons involving JWTs, the WebGoat README recommends setting the container timezone so token validity checks match your host environment:

docker run -it \
  -p 127.0.0.1:8080:8080 \
  -p 127.0.0.1:9090:9090 \
  -e TZ=Asia/Taipei \
  webgoat/webgoat

The Docker and README examples both emphasize mapping the service to 127.0.0.1, not exposing it broadly to the network. (GitHub)

WebWolf: Why It Exists

WebWolf is WebGoat’s companion attacker server. OWASP describes it as a separate web application that simulates an attacker’s machine, making it clear which actions belong to the victim site and which belong to the attacker. (OWASP Foundation)

The OWASP Developer Guide says WebWolf is available on port 9090 and provides:

  • a file upload area,
  • an email test mailbox,
  • JWT tools,
  • a display of incoming HTTP requests. (devguide.owasp.org)

This is useful because many real web attacks are not single-request attacks. They involve an external server that receives callbacks, reset links, leaked data, or browser-triggered requests.

A useful mental model is:

\[\text{WebGoat} = \text{victim application}, \qquad \text{WebWolf} = \text{attacker-controlled endpoint}\]

How WebGoat Lessons Work

Most lessons follow a similar pattern:

  1. Read the explanation.
  2. Interact with a form or endpoint.
  3. Inspect the HTTP request.
  4. Modify input, headers, cookies, JSON, XML, JWTs, or hidden fields.
  5. Submit the exploit.
  6. WebGoat returns a success or failure result.

The point is not only to “solve” the stage. The useful learning loop is:

\[\text{observe} \rightarrow \text{hypothesize} \rightarrow \text{modify request} \rightarrow \text{verify} \rightarrow \text{generalize defense}\]

The official README recommends having a browser plus OWASP ZAP or Burp installed before running WebGoat with Docker. (GitHub)

Mapping WebGoat to OWASP Top 10

OWASP Top 10:2021 lists categories such as Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, and SSRF. (OWASP Foundation)

OWASP Top 10:2025 reorganizes the list. The 2025 categories are:

  1. Broken Access Control
  2. Security Misconfiguration
  3. Software Supply Chain Failures
  4. Cryptographic Failures
  5. Injection
  6. Insecure Design
  7. Authentication Failures
  8. Software or Data Integrity Failures
  9. Security Logging and Alerting Failures
  10. Mishandling of Exceptional Conditions (OWASP Foundation)

One important change is that the 2025 Broken Access Control page explicitly maps SSRF and CSRF-related CWEs into Broken Access Control, while OWASP Top 10:2021 had SSRF as its own A10 category. (OWASP Foundation)

So in WebGoat, the same lesson may be discussed under different OWASP Top 10 names depending on the version of WebGoat, the tutorial, or the article you are reading.

Core Lesson Families

1. Injection

Injection happens when user-controlled input is interpreted as code, query syntax, command syntax, or another executable language.

The dangerous pattern is string concatenation:

\[q = \text{"SELECT * FROM users WHERE name = '"} + x + \text{"'"}\]

If x is attacker-controlled, then x can become part of the query language instead of data.

Typical WebGoat injection lessons include:

  • SQL Injection Intro
  • SQL Injection Advanced
  • SQL Injection Mitigation
  • XSS
  • Path Traversal
  • XXE in some versions
  • command-like or parser-based injection scenarios

For SQL injection, the difference between string and numeric injection is mostly about where the input lands:

-- string context
SELECT * FROM users WHERE last_name = 'Smith';

-- numeric context
SELECT * FROM accounts WHERE user_id = 101;

A string-context payload tries to break out of quotes. A numeric-context payload often does not need quotes.

The core defense is not “block bad words.” It is to separate code from data:

\[\text{query} = \text{template} + \text{bound parameters}\]

Prepared statements, parameterized queries, safe ORM usage, and server-side validation are the real fixes.

2. Cross-Site Scripting

XSS occurs when untrusted input becomes executable browser content.

The core failure is:

\[\text{untrusted input} \rightarrow \text{HTML/JS execution context}\]

WebGoat commonly teaches:

  • reflected XSS,
  • stored XSS,
  • DOM-based XSS,
  • mitigation by output encoding and safe sinks.

The defensive rule is context-sensitive encoding:

\[\text{safe output} = E_{\text{context}}(\text{untrusted input})\]

where context could mean HTML body, HTML attribute, JavaScript string, URL, or CSS. Encoding for the wrong context is still unsafe.

3. Broken Access Control

Broken access control is when a user can access data or actions outside their intended permissions. OWASP Top 10:2025 keeps Broken Access Control as A01 and describes failures such as parameter tampering, IDOR, force browsing, missing authorization on APIs, elevation of privilege, JWT/cookie/hidden-field manipulation, and CORS misconfiguration. (OWASP Foundation)

A clean invariant is:

\[\forall u,r,a:\ \text{allow}(u,a,r) \Rightarrow \text{authorized}(u,a,r)\]

WebGoat examples include:

  • IDOR: changing an object ID to access another user’s record.
  • Missing Function-Level Access Control: calling hidden admin endpoints directly.
  • Client-side filtering: finding data hidden in the browser but not protected server-side.
  • HTML tampering: modifying hidden fields, disabled fields, prices, quantities, or roles.

The key lesson is that the server must enforce authorization. The browser is not a trusted security boundary.

4. Authentication and Session Failures

Authentication failures happen when the application cannot reliably prove who the user is or whether a session/token is valid.

WebGoat lessons often cover:

  • authentication bypasses,
  • weak password-reset flows,
  • JWT manipulation,
  • session hijacking,
  • insecure cookies,
  • predictable or forgeable tokens.

A JWT is structurally:

\[\text{JWT} = \text{base64url(header)} . \text{base64url(payload)} . \text{signature}\]

A common beginner mistake is to think that base64 means secrecy. It does not. Base64 is encoding, not encryption:

\[\text{base64} \neq \text{confidentiality}\]

The defensive rules are:

  • verify signatures server-side,
  • never trust decoded JWT claims without verification,
  • use strong keys,
  • reject unsafe algorithms,
  • keep tokens short-lived,
  • invalidate or rotate tokens when needed.

OWASP Top 10:2025 explicitly mentions JWT and cookie metadata manipulation as a Broken Access Control issue when it allows privilege elevation. (OWASP Foundation)

5. Cryptographic Failures

Cryptographic failures happen when sensitive data is exposed because the application uses no crypto, weak crypto, broken key management, or confusing encoding with encryption.

Useful distinctions:

\[\text{encoding} \neq \text{encryption}\] \[\text{hashing} \neq \text{encryption}\] \[\text{fast hash} \neq \text{password hash}\]

For password storage, the goal is not merely:

\[h = H(p)\]

A safer password-storage pattern is:

\[h = KDF(p, s, c)\]

where:

  • p is the password,
  • s is a unique salt,
  • c is a work factor,
  • KDF is a password hashing function such as Argon2, bcrypt, scrypt, or PBKDF2.

WebGoat’s crypto-related lessons are useful because they show how easy it is to misuse primitives even when “crypto” appears to be present.

6. SSRF

SSRF happens when the server fetches a URL or resource based on user input without sufficient validation.

OWASP Top 10:2021 defined SSRF as a flaw where an application fetches a remote resource without validating the user-supplied URL, allowing attackers to coerce the app into sending requests to unexpected destinations. (OWASP Foundation)

The core shape is:

\[\text{attacker input URL} \rightarrow \text{server-side HTTP request}\]

This is dangerous because the server may have network access that the attacker does not have.

Defenses include:

  • allowlists instead of blocklists,
  • rejecting internal IP ranges,
  • resolving and validating DNS carefully,
  • disabling redirects or revalidating redirect targets,
  • separating fetcher services from sensitive internal networks.

7. CSRF

CSRF makes a victim’s authenticated browser send an unwanted request.

The risk is:

\[\text{victim session} + \text{attacker-triggered request} \rightarrow \text{state change}\]

WebGoat and WebWolf are useful together here because WebWolf can host the attacker-controlled page while WebGoat represents the authenticated target application.

Defenses include:

  • SameSite cookies,
  • CSRF tokens,
  • checking request origin where appropriate,
  • avoiding state-changing GET requests,
  • requiring re-authentication for sensitive actions.

In OWASP Top 10:2025, CSRF-related CWE mappings appear under Broken Access Control. (OWASP Foundation)

8. XXE

XXE occurs when an XML parser processes attacker-controlled XML with external entity resolution enabled.

The simplified model is:

\[\text{XML parser} + \text{external entity} \rightarrow \text{file read or outbound request}\]

In WebGoat, blind or out-of-band XXE lessons may require WebWolf because WebWolf can receive the outbound request or host a malicious DTD.

Defenses include:

  • disabling external entity resolution,
  • disabling DTDs when not needed,
  • using safe parser defaults,
  • avoiding XML for untrusted input when possible.

9. Insecure Deserialization

Insecure deserialization happens when an application accepts serialized data from an untrusted source and reconstructs objects without sufficient validation.

The danger is:

\[\text{bytes} \rightarrow \text{object graph} \rightarrow \text{unexpected behavior}\]

In Java ecosystems, this can be especially dangerous because deserialization may trigger constructors, callbacks, gadget chains, or library behavior. WebGoat’s lesson is useful because it shows that the vulnerability is not just “bad data,” but the act of trusting an object graph supplied by the attacker.

Defenses include:

  • avoiding native deserialization for untrusted data,
  • using simple data formats,
  • signing serialized data when unavoidable,
  • allowlisting types,
  • isolating deserialization code,
  • keeping dependencies patched.

10. Vulnerable and Outdated Components

Modern applications are dependency graphs. A vulnerable library can become your vulnerability.

A simplified dependency-risk model is:

\[R_{\text{app}} = \sum_{i=1}^{n} P(\text{exploit}_i) \times I_i\]

where each dependency i contributes some probability of exploitation and impact.

WebGoat has historically used component-level vulnerabilities to show why patching and dependency management matter. The 2025 OWASP Top 10 now elevates this broader theme as Software Supply Chain Failures at A03. (OWASP Foundation)

Defenses include:

  • software composition analysis,
  • SBOMs,
  • dependency pinning,
  • patch SLAs,
  • removing unused dependencies,
  • checking transitive dependencies,
  • secure build pipelines.

Browser Developer Tools

Use DevTools to inspect:

  • HTML forms,
  • hidden fields,
  • JavaScript,
  • cookies,
  • local storage,
  • network requests,
  • response bodies.

Burp Suite or OWASP ZAP

Use an intercepting proxy to inspect and modify:

  • methods,
  • paths,
  • query strings,
  • headers,
  • cookies,
  • JSON bodies,
  • XML bodies,
  • form bodies,
  • redirects.

The WebGoat README explicitly mentions ZAP and Burp in the Docker setup context. (GitHub)

WebWolf

Use WebWolf when a lesson needs:

  • attacker-hosted files,
  • captured requests,
  • reset emails,
  • JWT tooling,
  • out-of-band callbacks.

OWASP’s Developer Guide lists these WebWolf capabilities directly. (devguide.owasp.org)

WebGoat vs Other Training Platforms

Tool Stack Style Hosting Cost Best for
WebGoat Java / Spring Boot Guided lessons Local Docker/JAR Free Understanding fundamentals in a Java/enterprise context
OWASP Juice Shop Node.js / Express / Angular CTF-style challenges Local or online demo Free Modern web-app hacking practice
DVWA PHP / MySQL Simple modules with difficulty levels Local Free Beginner practice with classic vulns
Mutillidae II PHP / MySQL Hints, tutorials, vulnerable app Local Free OWASP Top 10 classroom/lab practice
PortSwigger Web Security Academy Browser labs Structured curriculum Online Free Deep web-security mastery
TryHackMe Browser labs / rooms Guided paths Online Freemium Beginner-friendly cybersecurity ramp
Hack The Box Academy Interactive modules Guided technical courses Online Freemium/paid Career-oriented hands-on cybersecurity training

OWASP Juice Shop is written in Node.js, Express, and Angular and contains many hacking challenges whose progress is tracked on a scoreboard. (OWASP Foundation)

DVWA’s goal is to help users practice common web vulnerabilities at different difficulty levels through a simple interface. (GitHub)

Mutillidae II provides dozens of vulnerabilities and hints, and OWASP describes it as suitable for labs, classrooms, CTFs, and tool testing. (GitHub)

PortSwigger Web Security Academy is free online web-security training from the creators of Burp Suite, with interactive labs, progress tracking, and continuously updated material. (PortSwigger)

TryHackMe describes itself as a free online platform for learning cybersecurity through hands-on browser-based exercises and labs. (TryHackMe)

Hack The Box Academy positions itself as guided, interactive cybersecurity training with modules from beginner to advanced levels. (HTB Academy)

Suggested Learning Path

Week 1: Setup and HTTP Basics

Install WebGoat locally and complete:

  • Introduction
  • HTTP Basics
  • HTTP Proxies
  • Developer Tools
  • CIA Triad

Goal:

\[\text{HTTP request} = \text{method} + \text{path} + \text{headers} + \text{body}\]

You should be comfortable modifying each part of the request.

Week 2: Injection

Complete:

  • SQL Injection Intro
  • SQL Injection Advanced
  • SQL Injection Mitigation
  • XSS basics

Goal:

\[\text{input should remain data, never become syntax}\]

You should understand string injection, numeric injection, blind injection, reflected XSS, stored XSS, and basic mitigations.

Week 3: Access Control and Authentication

Complete:

  • IDOR
  • Missing Function-Level Access Control
  • Authentication Bypasses
  • JWT Tokens
  • Password Reset
  • Hijack a Session

Goal:

\[\text{authentication answers “who are you?”}\] \[\text{authorization answers “are you allowed to do this?”}\]

Most real-world bugs come from confusing the two.

Week 4: Server-Side and Parser Bugs

Complete:

  • SSRF
  • XXE
  • Insecure Deserialization
  • Path Traversal
  • Vulnerable Components

Goal:

\[\text{parsers and fetchers are trust boundaries}\]

You should understand why URLs, XML, serialized objects, file paths, and dependencies are dangerous when handled naively.

Week 5: Reinforcement

After WebGoat, move to:

  1. OWASP Juice Shop for less-guided CTF-style practice.
  2. PortSwigger Web Security Academy for deeper topic-by-topic mastery.
  3. TryHackMe or Hack The Box when you want broader pentesting environments.

Practical Notes

Do Not Expose WebGoat Publicly

WebGoat is intentionally vulnerable. Keep it bound to localhost unless you know exactly what you are doing. The official README warns that the machine can become vulnerable while running WebGoat and says the default localhost binding is meant to reduce exposure. (GitHub)

Use a Throwaway Account

Create a test account inside WebGoat. Do not reuse real passwords. The OWASP Developer Guide notes that insecure username/password combinations are allowed because this is a training environment. (devguide.owasp.org)

Reset Often

Because many lessons modify state, reset the lesson or recreate the container if results become confusing.

Read the Source

One of WebGoat’s best features is that it is open source. After solving a lesson, read the relevant endpoint and mitigation code. That turns the experience from “I found a payload” into “I understand the bug class.”

Final Takeaway

WebGoat is best understood as a guided vulnerability laboratory. Its value is not the payload list; its value is the feedback loop:

\[\text{exploit} \rightarrow \text{understand root cause} \rightarrow \text{map to OWASP risk} \rightarrow \text{write the fix}\]

Use WebGoat first when you want explanations and safe practice. Use Juice Shop next when you want discovery and challenge. Use PortSwigger Web Security Academy continuously when you want depth and precision.

The result is a strong foundation in web application security: not just how attacks work, but why secure design, server-side authorization, safe parsing, dependency hygiene, and correct cryptography matter.